・第 2 章：搭业务的工具 ——UML 2.2 UML 的概念 1. 建模的概念 建模是对事物的一种抽象表述，其目的是简化现实。比如，流程图、状态图等就是对 事物的抽象表述，并且简化了现实。・第 3 章：产品战略・第 5 章：功能框架 5.2.1 什么是用例 用例 (Use Case) 也被称为用况，其定义如下。 用例是对参与者发 起的一组动作的描述，系统响应该组动作，并产生可观察到的显著结果。 关于用例的概念，我们需要注意以下几点。 1. 是用户在系统上做的事 1) 事情是任务或动作 2) 表述为 “动词 + 宾语”2. 用例的两种表达方式用例图和用户故事的表达内容：高内聚、低耦合：每个步骤都是相对独立的，但步骤之间也有联系。用专业的说法 就是高内聚和低耦合。意思是说，用例内的多个功能是紧密结合的，这就是高内聚。 同时，用例之间也有联系，但并不紧密，这就是低耦合。 可通过以下步骤来梳理功能框架。 步骤一：找到所有参与者 步骤二：定义出内外系 统 步骤三：找到目标层用例 步骤四：思考实现层用例 步骤五：找到步骤层用例・第 6 章：非功能框架 6.2 产品需求概述 1. 需求的类型 可以把功能性需求和非功能性需求做汇总，汇总后的模型为 “PURPS + 模型”。 “PURPS + 模型” 是指主要需求 (Primary)、可用性需求 (Usability)、可靠性需求 (Reliability)、性能需求 (Performance)、可支持性需求 (Supportability) 的集合， 其中 “+” 是其他次要需求，这六个大项下的子项分别如下。 主要需求 (Primary): 包 括功能、内容、安全性。 可用性需求 (Usability): 包括用户体验、帮助和培训文档 等。 可靠性需求 (Reliability): 包括故障率、维修时间等。 性能需求 (Performance): 包括响应时间、并发数、吞吐量等。 可支持性需求 (Supportability): 包括可维护性需求、可移植性需求等。 其他次要需求 (+): 包 括数据分析需求、许可需求、接口需求、包装需求等。 ・第 7 章：业务流程 7.4 用流程图梳理业务步骤一：画主流程，先粗后细，加入分支。 步骤二：完善细节，加入异常，拆出流 程。 步骤三：加入泳道。・第 9 章：信息结构 9.1 类的作用和表达 9.1.1 类的作用类表达的是信息结构和信息之间的关系。9.1.2 类和对象的概念 ** 象 (Object)** 是对现实事务的抽象，是一个具有边界并包括属性、状态和行为的 实体。 类 (Class) 是对一组具有相同属性、操作和关系的对象的描述。结构良好的类 具有清晰的边界和关系。 类是对具有共性的一组对象的描述，对象是类的一个实际例子。 类之间数量关系的表达方法: 9.2.1 信息的常⻅类型用户⻆度：用户信息、内容信息、业务信息 企业⻆度：组织信息、资产信息 1) 从用户⻆度看 从用户⻆度看，信息如下。1 用户信息：如用户、会员、积分等信 息，这些信息都是围绕着用户展开的。2 内容信息：用户到平台是要看内容的，这 些内容包括商家信息、菜品信息、套餐信息、优惠信息等，都是用户做决策的参考， 是静态的显示信息。3 业务信息：用户在看完信息后，就要有所操作，对外卖平台 来说，就是下单、退单、评价等操作。这些都是用户要做的业务，是动态的操作信 息。 2) 从企业⻆度看 企业有两类，分别是餐厅和外卖平台 餐厅⻆度看，信息如下。1 组织信息：一个餐饮集团包括集团、分公司和⻔店，我 们需要明确餐厅的组织结构，进而再明确员工的权限，如不同层级的员工对菜品的配 置权等。2 资产信息：餐厅包括租用的房子、购买的桌椅和餐具等资产，这些资产 也要管理起来。・第 10 章：交互设计 10.1 交互设计的概念与原则 10.1.1 常⻅的事件 常⻅的事件类型: 1) 鼠标事件 2) 手势事件 3) 键盘事件 4) 焦点事件 10.1.2 字段规则和业务规则 1. 字段规则 1) 字段规则的定义一个字段的规则项通常包含类型、⻓度、默认值和规则，具体如表 10-5 所示。该表定 义的字段规则可统一维护，也可标注在原型图旁。2. 业务规则一项业务应考虑主要流程、分支流程、异常流程和业务规则。 主要流程：正常执行操作的流程，没有任何异常发生。比如，用户登录的主要流程就 是输入手机号和密码，之后登录成功，没有异常。或者下订单的主要流程就是用户下 单和支付，也没有异常。 分支流程：和主要流程并列的流程，是用户的选择，而不是异常的事件。比如，用户 用邮箱登录、用第三方账号登录等，这些就是分支流程。或者在进行支付的时候，用 户选择收货后支付现金，也是分支流程。 异常流程：异常流程对应的是用户的错误或业务异常判断。比如，用户输错密码，就 是用户的错误；如果用户账号被禁用，用户就不允许登录，这就是业务异常判断。 业务规则：业务规则和异常流程有时是一回事，比如，用户输错几次密码账户就要被 暂时禁用，这既可以归为异常流程，也可以归为业务规则 10.1.3 交互设计的四大原则 1. 反馈原则：对于用户每步的操作，系统都要及时反馈 用户在界面上的任何操作，不论是单击、滚动还是双击，系统都应及时地给予反馈， 该反馈包括显示变化和结果反馈。显示变化：显示变化是对用户的鼠标事件、手势事件或焦点事件的反馈。在用户触 发这些事件后，系统要有显示上的变化。比如，焦点位于输入框内，则输入框颜色要 变化；焦点移出输入框，则输入框颜色也要变化。再如，鼠标悬停在确认按钮上，则 按钮颜色要变化。系统通过显示上的变化，可让用户知道该操作是有效的。在用户操 作后显示有变化，这自然是好的，因此显示变化可多多使用。 ** 结果反馈:** 在用户输完信息或提交信息后，系统就要给予用户结果上的反馈，这 个结果可以是错误、失败或成功等。结果反馈要考虑两点，分别是输入完和提交 完。 1 输入完的案例：用户输完手机号并将焦点移开，系统提示用户手机号错误；用户输入登录名并将焦点移开，系统提示登录名字数不够。2 提交完的案例：用户单击登录按钮，系统提示登录成功，并跳转到下一⻚面。 和 显示变化不同，结果反馈只是偶尔使用，使用太多反而不好。一方面，研发人员实现 起来困难，另一方面，在用户没操作完之前，系统不应该有太多的结果反馈。 2. 防错原则：在错误发生之前，就防止用户出错 好的设计在错误发生之前就会避免它 出现，而不是在错误发生后告诉用户错了，还要用户重做。防错的方法有友好提示和 禁止错误。 友好提示：给用户清晰的提示，从而避免用户产生错误。比如，在用户 填写手机号时，系统可将手机号码按 “3-4-4” 格式进行分段显示，禁止错误：友好提示只能对错误做提示，更好的办法是禁止用户产生错误，不给错 误的产生创造机会。禁止错误的方法是不让用户填错，或者填错后系统自动忽略。 1 不让用户填错的案例：在用户填写手机号时，系统要禁止用户填写非数字字符， 并且超过 11 位就不允许输入；禁止验证码中出现数字 1 或字母 I。2 填错后系统自动忽略案例：用户在下载网盘文件时，要输入验证码，用户在粘贴 验证码时，有时会将空格也粘贴进来，此时系统应忽略空格。 3. 撤回原则：在操作错 误发生后，提供撤回的功能 用户会输错信息，或误触功能。在这些错误发生后，界 面应支持撤销和重做。该原则很容易理解，具体实现就是在输入框旁边加删除按钮或 在发送消息后加撤回操作。4. 容错原则：指出错误并给出建议，降低用户损失 撤回原则强调的是撤销用户的操 作，而容错原则强调的是当用户已做完任务且错误已经产生时，系统应如何应对。方 法有两种：指出错误和降低损失。指出错误：用户要注册新邮箱，但该邮箱已被注册，此时系统就要提示 “邮箱已被注 册”，并给出建议，即提供可注册的邮箱名列表。 ** 降低损失:** 用户要批量删除照 片，这属于危险操作，此时系统就要尽到提示义务 —— 提示照片会被删除。如果用户 仍然坚持删除，这就有可能导致错误产生，此时系统应提供回收站，给予用户反悔的 机会。10.1.4 交互设计的外围需求 1. 前置条件 前置条件是用例能执行的前提，常⻅的前置条件有是否登录和网络情况。 2. 后置结果 后置结果描述了系统在用例完成后要做的事，包括完成后要跳转的⻚面、 创建的数据和进行的操作。3. 最小保证 最小保证定义了即使用例未完成或发生意外，系统也要做的事。最小保证 是一种特殊的后置结果，强调了在非正常情况下出现的结果。常⻅的最小保证是保留 信息和记录日志。10.2 规则驱动的交互实战 DAR 模型：系统显示 — 用户动作 — 系统响应 该模型的思路是，系统先要有显示，之后对于用户的每个动作，系统都要有响应。同 时，DAR 模型也是符合四大交互原则的。用例文档:・第 11 章：信息设计 11.1 信息设计范畴概述 11.1.1 信息设计的范畴 ⻚面包括列表⻚、表单⻚、详情⻚，以及组织这些⻚面的导航。 11.1.2 列表⻚的类型列表⻚主要有以下几种类型：内容类：典型的是电商平台的商品列表⻚。 审核类：典型的是商品审核、优惠券审核、退货审核等。 服务类：典型的是电商平台的订单列表⻚。11.2 列表⻚的字段设计列表⻚分为筛选区域、查看区域、操作区域 11.2.2 查看区域 查看区域分为列表区域、排序功能和分⻚区域 1. 排序功能 排序是简单的设计，产品经理只要明确有哪些字段需要排序，并且指明在 默认情况下按哪个字段排序即可。比如，默认按创建时间排序，且创建时间与现在时 间越接近，就越排在前面。2. 分⻚区域 后台的分⻚常有现成的组件支持，产品经理直接拿来用就可以了。此外， 产品经理需要定义清楚一⻚要显示多少条信息，以及需要考虑信息的安全。从安全⻆ 度考虑，产品经理应注意以下两点。首先，分⻚区域不应显示有多少条和多少⻚。其 次，不允许用户翻到最后一⻚。这样能够避免后台员工知道公司有多少种商品。 11.2.3 操作区域 11.3 列表⻚的信息布局 1. 一列一字段，便于阅读 2. 承载更多信息的方法 如果列表⻚要展现的信息较多，则可支持列表区左右滑动，并固定商品图片和标题等 内容，或者支持左侧导航栏折叠等，这样就可容纳更多的列表信息。11.4 列表⻚的扩展功能两个扩展功能：信息的通知和列表⻚信息的导出。信息的通知方式: ** 站内消息:** 通过发送站内消息，来通知用户商品的变化，但前提是用户必须登 录。如果用户始终在电脑前，这种通知是没问题的。站内消息的表现形式众多，如小 红点、未读数、消息列表等。 ** 发送短信:** 如果用户不在电脑前，那么商家通过 发送短信也能通知用户。这种方式会产生一定的费用。 ** 发送邮件:** 如果该信息 并不重要，并且用户用系统不频繁，那么发送邮件也是可以的。用户只需登录邮箱， 既看了工作邮件，也看了消息通知。11.5 业务驱动的列表⻚设计步骤：步骤一：梳理业务 步骤二：梳理场景 步骤三：设计方案 步骤四：设计⻚面 这四个步 骤可概括为 BSSP 设计方法，B、S、S、P 分别是 Business (业务)、Scene (场景)、 Solution (解决方案)、Page (⻚面) 的首个字母。11.5.1 步骤一：梳理业务 产品经理要设计商品列表⻚，就要先明确用户画像和业务目标，即明确给谁做，以及 要帮对方达成什么目标。11.5.2 步骤二：梳理场景梳理场景可分为两部分，分别是用户故事、用户场景 1. 用户故事 用户故事是以商家画像、员工画像为基础，在明确业务目标的前提下，研究用户要做 的活动是什么，并由此挖掘该过程中的问题，再思考我们可做什么来创造价值。概括 地说，用户故事就是明确活动、问题和价值 2. 用户场景 11.5.3 步骤三：设计方案 11.5.4 步骤四：设计⻚面 1. 闭环设计 闭环设计是指，不仅仅考虑用户在界面上的操作，还应考虑用户为完成该 业务所进行的线下操作。2. 信息设计

很有用，我要多读几次

产品经理的书大多是概念和理论，这是真正可以拿着自己的项目对照进行实操演练的一本书，整体来说还是比较成体系的，但是部分细节和方法还是需要根据自己的理解进行落地和优化。