这本书从设计师的角度写的，涉及交互设计师、用户体验设计师、产品经理等角色。产品经理重大方向、商业目标、功能业务等；设计师重逻辑、细节、情感、创意、界面等。这两个工种工作内容重合度较大、协作频率高，虽然各有侧重，但仍然有相互侵占工作内容的情况，互相的可替代性大。
书中站在设计师角度教设计师多为PM思考、分担工作。从PM角度来说，了解和掌握交互设计师、用户研究员职能也是必要的，毕竟不是每个企业都会配齐人员。
交互设计师
交互设计就是通过分析用户心理模型、设计任务流程、运用交互知识，把业务逻辑（功能规格或内容需求）以用户能理解的方式表达给用户，最终实现产品战略（公司需求和用户需求的最佳平衡点）的过程。这其实对交互设计师提出了更高的要求，即从公司战略角度去考虑问题，在满足公司需求的基础上让用户觉得易用、好用。
实际上设计并不是搞艺术，艺术是感性的，而设计是相对理性、精密的。艺术所表达的是创作者的个人意识，而设计是为了解决用户具体的问题。设计师既需要一定的灵感和天分，也需要后天努力的学习，掌握一定的技巧和方法，更重要的是严谨细致的心思。
所以作为一个菜鸟，不光要看书，还应该尽量多看一些设计网站上的文章。因为书籍可能比较偏理论，而网站上的文章更偏实际一些。平时多注重培养自己的思维和理念，而不是急于画图。多研究一些好的产品，思考人家这么做的原因，这是设计师必做的日常功课。
留心好的设计，在此基础上优化 一个人如果读过大量优秀的文学著作，那么对他的写作就会有较大的帮助。同理，如果一个设计师常年累月，潜心研究了大量优秀的设计作品，那么他的设计质量自然也不会差。
读书和实战项目不断地穿插进行，及时总结会让你的水平迅速得到提升。反之，如果光读书不思考，或光做项目不总结，你就会发现自己长期以来一直在原地踏步，没有什么实质提升。“学而不思则罔，思而不学则殆”，道理其实大家都明白，但做起来并不容易。学习本没有捷径，正确的学习方法就是最大的捷径。
用户体验设计师
广义的用户体验指人在使用某个产品时的主观感受。在互联网公司或软件公司里，用户体验主要来自用户和人机界面的交互过程。用户体验设计的目标可以归纳为：解决用户需求，减少用户理解和操作的成本，给用户留下美好而深刻的印象。
用户体验设计的一些特征：
● 严谨、理性、创意。用户体验设计充满了理性和严谨，因为它首先关注于解决用户的问题，同时也需要优质的创意，帮助用户获得更好的体验。
● 提供特定问题的解决方案 为了避免把设计当做自己无限发挥创意的舞台，以至于出现糟糕的体验。设计师在设计前，请先问问自己，这次设计的目标是什么？要为什么样的人解决什么样的问题？如何解决？
● 不让用户思考。
● 趣味横生 趣味性可以为你的设计加分，让用户产生难以忘怀的奇妙体验。
● 了解人，观察人。做设计是为了解决“人”的问题，是为了让“人”从中获得良好的体验。所以说到底，我们是在做以“人”为中心的设计。那么这就需要了解“人”的想法、行为、习惯等，学会换位思考。
一个好的用户体验设计师，一定是一个热爱生活、有激情、有梦想、喜欢解决问题的人。他的头脑中总是充满了各种各样新奇、有趣、靠谱的想法。他既具备理性的头脑、又具有一颗体察入微的心，更具有强大的执行力，可以把美好的想法转化成实际的产品。
用户体验设计师和产品经理的工作有不少重合的地方，但两者也有很多区别：设计师更注重创意及逻辑、细节，设计目标更纯粹，能够更多地考虑用户，工作上更专注，设计方法更专业；而产品经理作为产品的主要负责人，需要考虑更宏观的问题，聚焦的范围比较广，更重视商业目标，此外，还需要考虑项目中的很多琐事。两者需要相互配合、取长补短。
产品经理
本书认为产品经理最重要的产出物应该是需求文档。产品定位、需求分析等工作则应当设计师与产品经理共同完成，在产品经理产出需求文档后，设计师完成原型设计。
一条需求可看作是“目标用户”在“合理场景”下的“用户目标”，其实就是解决“谁”在“什么环境下”想要“解决什么问题”。用户需求其实就是一个个生动的故事，告诉我们用户的真实境况。我们需要了解这些故事，帮助用户解决问题，并在这个过程中让他们感到愉快。识别这些需求的有效性和真实性后，根据产品定位和项目资源情况筛选、提炼出产品需求，定义出需求优先级。接下来就可以重点描述每个需求的逻辑、内容等，开始撰写详细的需求文档了。产品经理不应该跨过前面的过程，直接罗列一堆功能说明，形成一份没有价值的需求文档。
如何考虑用户需求
根据目标用户考虑：提出要求的用户是你的目标用户吗？
根据使用场景考虑：用户提出的这个问题一般发生在什么场景？合乎实际的使用情况吗？
根据用户目标（真实需求）考虑：用户表达出自己的真实需求了吗？
根据产品定位考虑：用户提出的要求符合产品的定位吗？
根据项目资源考虑：用户提出的这个要求需要多少开发资源？价值有多大？需要立即开发吗？
如何确定优先级
确定优先级不是凭感觉的事，我们要有可以量化的标准来衡量哪些功能优先级高，哪些功能优先级低。大多数用户需要用到的功能和使用频率很高的功能，需要重点突出。对用户目标和商业目标的影响大小，可以表示为此项功能的重要程度。所以，我们可以通过使用人数、使用频率和重要程度这3个维度来排布优先级。
有没有必要写需求文档
当产品规模小、项目人员少时，没有文档不会出现太大的问题，项目依然可以灵活、顺利地进行。但当产品规模不断扩大、项目人员不断增多时，缺乏文档的弊端就会渐渐显现出来。比如，当人员流动时，工作难以交接清楚，因为历史的功能信息均没有记录。当系统越来越庞大时，谁也无法描述清楚底层的完整业务逻辑，更新维护的成本极高，工作流程十分混乱，团队内部沟通不畅、效率低下…… 假如在一个大型项目团队中，产品经理没有写需求文档的习惯，而是直接深入细节，绘制线框图，那对整个项目团队可能都是一场巨大的灾难。因为即使是一个非常专业的设计师，也不能保证在处理一个复杂的问题时，能够立刻描绘出正确的设计方案来，他必须经过一系列思考的过程。 小型团队中虽然不需要详尽的需求文档，但产品定位、需求优先级等总是要有的，只是不限制文档格式，普通列表也可以，只要方便团队成员理解、沟通即可。
所以说，作为产品经理，应该养成写需求文档的好习惯。第一，需求文档可以有效地帮助产品经理理清产品功能、内容、业务逻辑等整体信息。如果跳过这一步，过早地陷入界面细节，很容易得到盲人摸象的结果，给后续环节造成灾难性的后果。第二，需求文档大大地方便了团队的沟通，让团队成员在项目前期迅速准确、全面地了解你的想法，而仅靠简单的沟通则很难遍历到所有的需求点，且面对多人团队时效率很低。需求文档也规范了项目的具体内容，不会出现越跑越偏的情况，增强了对项目的把控力。第三，需求文档可以帮助其他项目成员有针对性地提出问题，而不是感到困惑和无所适从，这样也提升了工作效率。第四，需求文档不仅有利于项目的持续发展，还能促进产品经理自身能力、专业性的提升。就像交互设计师要产出原型、视觉设计师要产出视觉稿、开发人员要产出代码一样，需求文档就是产品经理的重要产出物。
在具备一定规模的团队中，产品经理不仅需要提供需求文档，还应该不断地与团队成员沟通。前期沟通主要传递想法。中期沟通解决不断发现的问题、迭代需求。后期沟通确认问题是否得到解决。如果是面对一个较大的项目或是比较复杂的需求，且团队人数较多，则需求文档应该保证一定的规范性。很多公司都有通用的需求文档模板，以保障形式和内容上的统一。这样既不容易遗漏重要的内容，也让需求文档看起来更专业，同时统一的形式也降低了项目成员的理解成本。
让思维破茧成蝶
保持低调、谦逊，善于站在别人的角度想问题，考虑问题时注重本质、推理而不是表象。不论是对设计师还是产品经理来说最重要的是解决问题的能力，工具的使用、文档、设计的呈现反而次之。比如，通过竞品分析发现某网站的提示功能很贴心，我们要做的不是把这个功能的设计立刻照搬到自己的产品上，而是要分析这个功能解决了用户什么问题，满足了用户的什么需求，实现了用户的什么目标，基于这个目标我们应该如何做得更好。这样才能做到“人有我优”，学习到竞品的精髓，而不是皮毛。
