这是一本以用户体验要素为切点的产品设计的书，其中每个章节的要点其实是不仅仅适用于当前章节的，甚至很多道理是跨行业、专业普遍适用，比如：
- 拆分：对复杂问题的模块或层次划分，并不意味着我们可以完全忽略他们的互相影响，明确地分离出边界，只是一种简化思考的手段。
- 行动准则：任务执行时可以分层，同时没必要在考虑低层设计时过多顾虑高层实现，高层实现时会遇到问题，是正常的，会对低层设计造成正负反馈的影响产生变化也是正常的。但对低层过多的改动说明并没有考虑清楚而过早的开始了下一阶段。
- 莫忘“初心”：关注目的，不论是在繁杂的调研，频繁的沟通，繁多的文档撰写，还是冗长的标准制定中，长时间的准备工作会让我们对目的麻木，不要被数据迷惑，不要被不善言辞的对话者迷惑，不要被写出厚重的文档的成就感迷惑、不要被标准的制定流程迷惑，关注调研的用户主体，关注沟通的根源问题，文档、标准要清晰反馈的要点。
- 控制欲望：明确目标，遏制完成冒出的新鲜想法的欲望（完成新的产品特性？学习中新的困惑的求知欲？），不在当前阶段增加新的工作量，才能避免目标膨胀（增加新的实现需求，导致产品一直开发不完；有了新的困惑就无穷尽的查下去，导致第一本书永远看不完，没有终点），更好的达到当下的终点。管理那些新鲜欲望成为下个目标，良性发展。
- 撰写正确级别的文档，不以厚重为标准，文档内容应明确，消除理解误差，标明注意点，记录决策的根本原因。
- 明确，明确，明确。
用户体验为何重要
- 何为用户体验
- 用户体验不是产品本身是如何工作的，而是人机交互，细微而重要。
- 感官（视听嗅味）反馈、功能都只是设计用户体验良好产品的一部分而不是全部。
- 产品设计与用户体验设计
- 正确的产品设计并非“外形服从于功能”，而应顺从用户心理和行为。
- 用户体验设计兼顾视觉和功能的同时时，还要注意设计间互动关系，是否相互干扰，如这个很重要，所以突出，同时是否会导致其他功能不够突出。
- 产品越复杂，确认如何向用户提供良好的使用体验就越困难，毕竟每个新功能都会至少增加一个新的结果未知的“用户体验”。
- 有关网站
- 网站是一个没有（或缺少）说明的复杂自助产品，在用户自助过程中产生的每个不符合心理预期都会给用户造成负向心理反馈，从而赶走用户。
- 盲目添加的特性会在无法命中用户需求的情况下，增加这种复杂性
- 与商机
- 用户体验关系“客户忠诚度”，而用户一旦离开则很难给你纠正的机会。
- 对外，用户体验关乎转化率，关乎投资回报，关乎商业目的。对内，减少资源消耗，提高企业生产力，提升工作幸福感，节省支出。
- 在乎用户
- 将“以用户为中心”的设计流程分解成各个组成要素，从不同角度来了解它。
- 规划有粘性、只管、一个每件事都按照正确的方式工作的体验。
要素
- 五个层面
- 表现层：用户感官。
- 框架层：视觉骨架。
- 结构层：引导呈现。
- 范围层：功能边界。
- 战略层：为何？
- 层面关系
- 5 个层面自下而上的组成了 5 层模型。
- 底层决定高层边界，高层决定又能促成对底层的重新评估。
- 最佳做法是，底层工作大体确定后进行高层工作，高层工作思考下沉，对底层进行反馈，并在高层工作结束前完全确定。
- 评：层面关系部分的要点不仅仅适用于产品，更适用于所有的方案设计与设施。底层的思考不应该纠结高层的实施细节，只需要专注于当前层面的可行性与合理性，问题会在高层面的实施过程中出现，这是正常的，最终会在正负反馈中相互促进形成最终的整体方案。
- 网页的双重性
- 信息发布与检索的信息性与倾向的客户端软件的功能性。
- 网页的用户体验设计也因此分为面向功能型产品和面向信息型产品两个方向。
- 功能侧关注任务，即用户的完成一个任务的过程；信息侧关注信息，即可寻找、可理解且有意义的信息组合。
- 评：5 层树，两开花，但一个产品不可能纯粹的归属到某个单一的方向。
- 层面要素
- 战略层：了解用户需求，明确产品目标。
- 范围层：功能侧的功能规格，信息侧的内容需求。
- 结构层：功能侧的交互设计，信息侧的信息架构。
- 框架层：共有的信息设计，功能侧的界面设计，信息侧的导航设计。
- 表现层：感知体验
- 应用要素：
- 将用户体验按照层面和要素划分利于思考可能遇到的麻烦。
- 但某单一的用户体验问题又很难确定能否仅仅依靠某个要素去解决。同时层面中某要素的效果也不能脱离层面中的其他要素单独评估，这就是用户体验设计的复杂性。
- 影响用户体验的除了设计，还有网站提供的具体内容、应用的技术，这两个都是无法通过设计解决的。
战略层
- 定义：
- 由问题“我们要通过这个产品得到什么？”明确产品目标
- 由问题“用户要通过这个产品得到什么？”明确用户需求
- 产品目标与用户需求共同组成站撸层。
产品目标
产品目标不能存在于“只可意会不可言传”的混沌中，当无法被口头表达出来时，对于如何完成产品，不同的人就会有不同的想法。
评：这是一条不仅仅适用于产品目标的通用的规则，事务无法被口头表达时，就是不明确的甚至冲动的，事务无法被精简的表达时，就是不纯粹的，而通过沟通避免多方理解偏差时，也需要事务能被精准表达。
- 商业目标：
- 在太具体与太宽泛之间取一个平衡。
- 每一个做出的决定都应该建立在我们确切的了解它的影响力的基础之上。
- 明确地定义成功的条件而不是通向成功的路径。
- 品牌识别：
- 品牌是需要明确描述的基础目标之一。
- 在视觉表现智商，可以是概念系统，可以是情绪反馈。
- 品牌形象可以精心安排，施加控制，将品牌形象明确地写进目标将会提高呈现出积极的品牌形象的机会。
- 成功标准：
- 如何衡量达到了目标？需要一些可追踪的指标。
- 标准并不是通用的，应该根据目标制定。
- 对驱动用户体验决策而言有意义的成功标准，一定能明确地和用户行为关联。但用户行为数据的变化发生在较长时间内时，则无法确定其改变是否与某次用户体验的变化相关。
- 当数据变化时，要后退一步注意是否有场外因素影响，被“断章取义”的数据变化，可能会造成误导。
- 评：所以 A/B 测试下的数据，保持单一变量，屏蔽了纵向对比下的场外因素影响，才能更准确的反应效果。
用户需求
“你”并不能代表全部的用户，“你”的立场也不是全部用户的立场，搞清楚用户，才能搞清楚用户需求。
- 用户细分：
- 我们可以将用户分为更小的群组，各个群组中的用户都有某些共同关键特征。
- 常用分类方式有人口统计学标准（性别、年龄等）划分，有消费心态档案（节俭型、冲动型）等，对产品的使用能力（如小白用户和专业用户）。
- 创建细分用户群是用于揭示用户最终需求的手段。你应该得到的是和你发现的用户需求数量一样多的细分用户群。
- 细分出的用户群甚至会产生冲突的用户需求，如小白用户和专业用户可能就有傻瓜式和定制性的不同偏好，这时就需要我们决策是抛弃部分用户还是提供多种方式。这会影响到我们的决策。这种决策会影响用户体验相关的每一步。
- 用户调研：
- 评：此部分感觉书中写的比较没有条理，并没有完全按照书中的结构来，就是讲为了得到哪些东西可以使用哪些方式，当然用户调研的手段也不仅仅适用于用户，它是通用的建议收集方式。
- 为了收集普遍观点和感知，使用问卷调查、用户访谈、焦点小组（座谈会）等市场调研方法，需要你能明确地表达出你试图从用户身上得到什么信息，这些信息被描述的越清楚，就越能有效公式化你的问题，保证获取到正确的答案。
- 为了理解具体用户行为和使用表现，使用用户测试和现场调查。
- 为了了解用户的日常生活环境中的用户行为，可以使用现场调查方法，这种方法可以获得其他方法无法获取的极其细微的用户行为，当然也是（时间、资源）成本很高的方法。
- 为了获取用户完成任务的精确步骤，降低使用成本，可以使用任务分析方法。任务分析法认为用户与产品的交互都是为了完成某项任务，可以对这项任务进行步骤分解。这种分解可以通过市场调研方法，让用户自己描述，讲述经验，也可以使用现场调查完成，直接研究用户执行任务的行为。
- 为了得到直接的用户反馈，可以使用用户测试法，这是一种邀请用户帮忙测试“产品”的方法，用户测试并不一定要面对真实的产品。可测试真实产品获取可用性反馈、获取品牌气质反馈；可测试原型、草图，搜集用户意见，及时调整；可让用户参与各种模拟活动，间接获取对产品看法，如让用户对模拟信息分类，从而洞察当前产品的分类方式是否契合用户所想。
- 可用性是用户体验的一部分，也是最普遍的用户需求。高可用性即是低使用成本。是我们进行用户调研的一个关注点，往往更易由用户测试法得出结论。
- 创建人物角色：即用户模型
- 莫沉迷在统计数据而忽视实际存在的人物。
- 将用户研究中提取出的特征，归纳为代表不同用户群的实在的“虚拟角色”，给 ta 真实的姓名、身份、经历，甚至给 ta 照片，可以帮助我们忽略实际的用户。
团队角色和流程
谁来明确目标：战略专家？决策层？普通员工？听取百家之言评：啰嗦的废话，但不可忽视的应该是事务流程的各个部门与用户的反馈。- 战略文档
- 内容包括目标、目标间联系的分析、目标与企业环境的关系，包括制定过程中来自各个参与者（决策者、员工、用户）的意见，这些意见支撑了整个战略。
- 文档应是直接了当切中要点的，不以厚度重量为标准。
- 文档应该是公开的，为帮助参与者理解。
- 战略是起点，但如前文（注：要素-层面关系-最佳做法）所说，不意味着战略要在项目开始前完全确定，可以系统的跟随后续工作的正负反馈进行调节。
范围层
定义
定义产品范围有两层意义：思考过程的意义，产品边界的意义。
-
思考过程：在思考范围的过程中，我们能考虑潜在的冲突和粗略的功能点。从而确定，哪些可以直接开始，哪些需要协调，哪些需要延后。
- 产品边界：
- 明确全部工作，为多方提供共同语言，避免模棱两可。
- 明确终点，明确上线的功能节点，避免不知何时结束而永不上线，避免无穷尽的开发，当然这个终点可以是里程碑的分阶段的形式。
- 产品需求文档：
- 范围内：知道项目目标很重要，知道自己在做什么很重要，知道其他人在做什么也很重要，知道各个相对独立并不显著的要求之间的内在联系同样重要，产品需求文档可以帮助做到这些。
- 范围外：知道不该做什么，克制实现不断涌出的新鲜想法的诱惑的冲动才能更好的完成产品。要有意识的管理这些新鲜想法，可以从中辨别符合长期规划的杰出部分，成为下一里程碑的基石。避免不断加入“小需求”使当前阶段的产品开发滚雪球般膨胀，失去控制，引发雪崩。
评：懂得克制也是很重要的，主动管理新鲜“欲望”，控制范围会有助完成当下目标，只有看的见的终点才有达成的可能。
功能和内容
- 功能侧：功能规格，哪些应当被当做软件产品的功能以及相应组合。
- 信息侧：内容。
我们把这两种统称为特性。
- 评：正如前文（注：网页的双重性）所说，产品无法单一的归属到功能侧或信息侧，此节剩余篇幅也是在举例描述观点，如提供内容时需要有内容管理系统，提供功能时又要有功能说明。
定义需求
需求源泉有用户、项目相关同事、其他产品。
- 来自用户的想法：收集直接需求。
- 清晰的好想法：最终会以某种形式体现在产品上。
- 带有答案的问题描述：有时人们所期望的特性只是自己对自己所遇问题的解决办法，针对此类意见，更应该搞清楚的是问题，而不是他们自己的答案。
- 天马行空：这类意见提出的特性看起来可能很伟大，但未必是真正需要的，也未必是符合现实的。
评：对带有答案的问题描述的处理，是一个很普适的处理方式，不仅仅存在产品设计中，在正常的人际沟通中也适用。他们的答案往往是从自身出发的一个较“便捷”的处理方式，而一旦他们选择与你进行沟通，就说明在相关方面你是有更为深入或特别的了解的（或者你就是这个带给他们问题的产品的创造者），你要做的是挖掘他们遇到的真正的问题（很可能会被他们的不善言辞埋藏的很深），提供一个治本、符合产品规划的改进方式。
- 来自同事的想法：收集解决问题相关的需求。
- 让产品参与各方坐下谈一谈，通常能得到开发过程中所要解决的问题和解决办法，这些也会影响产品的功能。
- 在这个过程中，我们可以代入前文（注：创建人物角色）的用户模型，切身体验他们的产品使用过程，发现过程中的问题，发现帮助完成过程的潜在需求。
- 来自其他产品：得到启示。
- 竞品：尝试满足相同的用户需求才能成为竞争对手，那么从他们的处理方式上一定能得到一些启发。
- 非竞品：我们把格局放小一些，同样会在非竞品的单一模块中发现想要满足相似需求的实现，同样可以带来启发。
功能规格说明
你都不看文档的吗？？？
但凡是文档，就有两个问题：
- 总有人觉得看文档是浪费时间而不看。
- 维护差，不能有效的跟随产品变化。
所以，应该让撰写功能规格说明的过程快速简便，应该同样（注：战略文档）是切中要点，清晰而准确的，书写功能规格说明的时候有三个要点：
- 乐观：不讲不能，而讲可能。如，不讲“不允许如何如何”，而是“发生什么时，应如何”
- 具体：详细的解释状况：如，不讲“最受欢迎的应如何如何”，而是“收藏最多的应如何”或“三连最多的应如何”，把“最受欢迎”落为详细指标。
- 避免主观：主观是比不具体更差的、更不具体的一种行为。如，不讲“应该时尚”，不讲“应该符合某某的时尚”，而讲“应符合产品的品牌指南文档”，或者加入数字化的指标。
内容需求
- 格式和目的：格式和目的不要混为一谈，如 FAQ 的格式是简短的问题和答案，但其目的却是提供常用的问答答案。
- 确认负责人：只要不是我负责的就是好的，想法是愉悦的，执行是痛苦的。
- 确定更新频率：保证提供内容的时效性，真的可用。
- 内容分类：搞清楚对哪类用户提供哪类内容。
- 内容清单：对已有项目，整理出现有内容清单也很重要，这是用户体验设计要切入的点。
确定需求优先级
- 需求与战略：
- 梳理出符合战略目标的需求
- 梳理出战略目标外的需求，看是否有对战略目标进行反馈调节的意义。
- 梳理出符合战略目标优先级的需求，确定需求优先级。
- 确定需求在资源上的实现可能（技术、成本）。
- 确定需求间关系，是否冲突，从而得到连贯统一的产品。
结构层
定义
- 功能侧：交互设计，影响用户执行和完成任务的元素。
- 内容侧：信息架构，关注如何将信息表达给用户的元素。
两者都是要确定将要呈现给用户的元素的模式和顺序。
交互设计
- 关注描述可能的用户行为，同时定义，系统如何配合和相应这些用户行为。
-
与其针对机器的最佳工作方式来设计系统，不如设计一个对用户而言最好的系统。
- 概念模型
- 即交互组件该怎么工作。
- 软件是否将某个特性处理成用户所熟知的概念，如购物车功能的操作符合实际的购物车模型的功能。
- 规划好概念模型能帮助做出一致的设计决定，帮助网站将这些元素从头到尾一致地表现出来。
- 使用用户熟悉的概念模型，会帮助用户很快的适应一个网站。
- 不必明确地将概念模型告诉用户，更重要的是在交互设计的开发过程中保持使用方式的一致性。
- 完全照搬现实世界的概念模型也是不适用的，比如用户无法在网站像真正的杂志一样翻过一页，就算你的交互动效做的再好。
- 了解用户对网站模式的想法，挑选符合用户隐含期望、直觉的概念模型。
- 错误处理：不可避免的交互设计的一部分
- 预防：如格式校验，避免后续操作。
- 改正：自动修复，但判断错误的自动修复或修复提醒是令人反感的。
- 恢复：撤销、上一步等后悔药，合理的“你确定吗”。
信息架构
- 要点：
- 关注人们如何认知信息的过程。
- 关注呈现给用户的信息是否合理并具有意义。
- 信息架构要创建符合网站目标和满足用户需求的分类体系，并被体现在网站的内容中。
- 结构化内容：
- 分类体系：
- 从上到下：从产品目标和用户需求进行设计。先从广泛有可能满足决策目标的内容和功能进行分类，再依逻辑细化次级分类。最后将内容和功能插入分好的空槽。不好的是可能会忽略内容细节。
- 从下到上：将已有的内容或猪呢备好的内容统统放入最低级别，再将他们分别归入到较高级别。不好的是过于反映现有内容，不能灵活的容纳未来的变动。
- 寻找平衡。
- 标准：用户到达某内容的步骤并不是最重要的万盏结构衡量标准，而是当前的步骤是否合理的延续了上个步骤。清晰的多步优于令人困惑的“捷径”。
- 演进：高效结构的有点事具备容纳成长和适应变动，但是在内容增量之后也有需要重新换个维度考虑分类方式的时候。
- 分类体系：
- 结构方法：
- 信息架构的基本单位是节点，节点可以小到具体的信息点，可以大到整个产品。安排这些节点有几种常见的结构类型。
- 层级结构：树状，最常见的，软件倾向于的工作方式。
- 矩阵结构：立方体叠加起来的结构，允许用户在节点间验证更多维度移动。如用户进入产品节点后，可以向颜色、尺寸等节点移动。
- 自然结构：到达的途径很多，弱化分类的概念，没有清晰的指示，鼓励探索，如视频的更多推送。
- 线性结构：如一根主线走到底。
- 组织原则：
- 组织原则就是我们决定哪些节点要编程一组，哪些要保持独立的标准。在不同的区域和网站不同的层面是要使用不同的组织原则的。
- 一般而言。在产品结构最高层级使用的组织原则，应该紧密的与“组织目标”和“用户需求”相关，而结构低层级与内容和功能需求相关。
- 以信息的属性类型分类几乎能为任何内容提供一套简单、灵活的组织原则，为避免使用错误的组织原则的常见操作就是把所有属性都列出来当做组织原则给用户使用，但仅仅适用于你的信息非常简单。
- 过多的供选择的属性类型会将信息架构变得笨重而混乱，造成用户的使用负担（选择过多），创建结构时我们要具体的识别出用户心中至关重要的信息。
- 语言和元数据：
- “使用用户的语言”并保持一致性作为网站信息命名原则是非常重要的，有助于用户理解。
- 我们应该有一个强调一致性的工具作为网站使用的一套标准语言，称为受控词典，这应该是一个共享的明确资源。
- 还有一种方式可以控制词汇，创造类词词典（同义词、分类词典），收纳常用的为拿住网站标准用语的词汇。
- 使用受控词典、类词词典对帮助建立包括元数据的系统特别有用。我们可以使用词典，对数据的元数据进行一致化定义，对于数据检索和内容扩展有很好的帮助。
- 评：元数据即 metadata，即 data for data，元数据也是属性，但它关注的是数据这个层面，而非数据真实代表的东西，如“1620kg，1490cc，SUV”，我们能获得的属性为重量属性1620kg、排量属性1490cc、车型属性 SUV，而这个数据的元数据，则是这个数据的行业类型属性为车相关、发布时间属性是什么。同时元数据与大数据息息相关。
团队角色和流程
-
信息架构和交互设计的主要文档是示意图，视觉化得呈现结构。我们一般以架构图（某些概念中又叫网站地图，但网站地图在框架层导航设计中又代指别的东西）来描述这种网站结构工具。
-
架构图最重要的是记录概念关系，哪些类别需要放在一起，那些需要保持独立，交互过程中的步骤又要如何配合。
框架层
定义
- 功能侧：界面设计，界面控件，提供给用户做某事的能力，通过它用户能真正的接触到在结构层交互设计中的确定的功能。
- 信息侧：导航设计。提供给用户到某个地方去的能力。
两侧都要关注的信息设计，用于呈现有效的信息沟通，传达想法给用户。
习惯和比喻
- 习惯：与前文（注：交互设计-概念模型）结构层相似，界面问题的解决办法在没有充足理由时应该与用户养成的习惯保持一致，违背用户习惯的解决办法会给用户带来挫败感。但更重要的是要与自身保持一致，使用相同概念模型的模块其操作习惯也应该是一致地。
- 比喻：我们可以真实世界的事物比喻某个功能，但是不应该增加用户的理解成本。比如，以电话图标来表示功能时，它真的有文字来的直观吗，每个人对电话图标的理解是相同的吗，我们在上下文中提供的信息有助于降低用户的联想成本吗？
界面设计
成功的界面设计是能让用户一眼就看到最重要的东西的界面设计。组织好用户最常采用的行为，同时让这些界面元素用最容易的方式获取和使用。
- 技巧：
- 考虑选项的默认值。
- 记住用户最后一次选择状态。
- 元素选择：又是一个权衡问题。
导航设计
- 目标：
- 提供给用户在网站间跳转的方法。
- 必须传达出这些元素和他们所包含内容间的关系。
- 必须传达出它的内容和用户当前浏览页面间的关系。
用户有在物理空间中定位的能力（路痴除外），或许也有在信息空间中定位的能力，但是我们在做导航设计时应该忘掉用户的这种能力，清晰地告诉他们此刻在哪，又能去往哪。
- 常用导航系统：
- 全局导航：你可以通过这个导航最终到达万站的任何地方，一般是导航中放的是网站所有的主要栏目。
- 局部导航：提供到相邻（父、兄弟、子）结构的通路，当架构设计使用用户对完站的内容结构思路设计时，局部导航通常更有用。
- 辅助导航：允许用户快速切换浏览方向的导航。
- 上下文导航：如文章中的关键词链接。
- 友好导航：与辅助导航类似，但是使用频率更低，但确实需要。
- 网站地图：按照层级对网站一级导航和其二级导航的罗列，往往不超过两级，往往作为独立的内容部分出现。
- 索引表：按照字母排序的列表，往往不必要，但试图相对独立的服务于不同信息需求的用户时会很有用，也场作为独立的内容部分出现。
信息设计
信息设计决定如何呈现这些信息，是人们能很容易的使用或理解它们。
- 范畴：
- 视觉呈现：用何种方式，饼图？柱状图？
- 排列分类：用反应用户思路和支持他们任务目标的方式排列和分类信息元素。
- 对用户行为的信息反馈，提供正确使用系统的信息，如操作提示、错误提示。
- 指示标识：以心理暗示的方式向用户提供定位信息，可使用图标、标签系统、排版、颜色形成这种心理暗示。
线框图
- 页面布局是将信息设计、界面设计、导航设计放置在一起形成统一、有内在凝聚力的架构。需要平衡很多东西，需要被纳入一个详细的文档，称之为页面示意图或线框图。
- 线框图是对页面中所有组成部分以及他们结合方式最直观的描述，将作为产品的骨干。
-
线框图文档中往往还标明了或写明了交互设计文档、内容需求文档和功能规格说明或其他类型的详细文档。
- 三个目标：
- 呈现主体信息群。
- 勾勒出结构和布局。
- 用户交互界面的主视觉和描述。
表现层
定义
- 解决并弥补产品框架层的逻辑排布的感知呈现问题。
- 网站的感知体验往往只有视觉体验。
具体的视觉设计准则，关联《写给大家看的设计书》的读书笔记，不再额外记录，在那本书中没提到的只有基于栅格线的布局模式。
要素的应用
- 如何抵达成功：
- 了解你正在试着结局的问题。
- 了解这些解决办法所造成的后果。
- 提出正确的问题：
- 莫敷衍了事：不充分甚至编造的结论只会得到错误的方向。
- 要有焦点：无焦点的提问或调查会提供给被测试者过多的要素，不能从得到的反馈中得知到底是哪个特性引起的。
- 比用户更了解用户。
- 打好基础：要懂得什么是要花时间深思熟虑的，什么是需要快速决断的，当伴随着低层决策错误开始高层工作时，往往修补和调整就来不及了。