• 04 功能和流程入门
  • 针对已有功能的优化
  • 完整小功能设计
  • 业务流程设计基础
• 05 原型设计与PRD入门

  • 页面流程与页面结构图

    • 页面流程图（必需）和信息架构图（每个页面包含的内容）的区别
    • 过程

  • 原型设计的基本原则

    • 什么是产品原型？
    • 如何开始产品原型设计？
      1. 从原型到上线的过程
      2. 做低保真原型之前，动手之前的忠告
      3. 开始原型设计
    • 原型设计的好习惯

  • 如何写需求文档

    • 什么是需求文档？
    • 有什么用？
    • 高颜值的需求文档有什么特点？
    • 需求文档怎么写
      1.项目背景与需求分析
      2. 本次需求的目的及功能列表
      3. 流程与所处的产品模块关系
      4. 功能详细描述
      5. 简要的测试用例（可选，需要专业的测试并配合很好）
      6.考核指标
• 06 项目管理入门-需求评审
  • 需求评审
    1. 什么是需求评审？
    2. 需求评审都有什么人参加？
    3. 为什么非得做需求评审？
    4. 如何组织一场成功的需求评审会？

04 功能和流程入门

【一句话概括】这部分开始真正进入业务层面，在用户需求调研完成之后开始进入实际的工作中，在P1阶段可能有两种任务，针对已有功能的优化或者开始着手一个完整的功能设计。同时把上一节课讲的业务逻辑进一步细化为业务流程，为接下来的页面流程图做准备。

针对已有功能的优化

1. 功能点的优化是最基础的工作

• 对功能点的不断优化就是迭代，功能点是最小化产品设计。
• 不要期望用新功能来解决老的功能问题；新接入功能并不能改变用户已有功能的使用问题
• 功能优化相对于新功能设计的好处？
  - 反应速度不同：邮件、甚至口头搞定
  - 开发难度不同：一般都是1-3天/人的工作量
  - 评判标准不同：更强调效果对比

2. 分析产品功能的现状与逻辑

   要做功能点优化，首先对产品功能的现状和逻辑进行分析，使用上一章的功能点分析方法分析即可，这是对自己的产品进行分析；

   • 用户：都有哪些用户会用到这个页面/功能
   • 流程：用户的使用流程是如何的？
   • 逻辑：产品底层逻辑（业务流程）是如何的？

3. 现在的功能有什么问题?

• 现象：哪些用户出了什么问题？
• 原因：为什么会出问题？路径太长，用户不习惯；
• 影响面：出现问题的频率和受影响的用户量是如何的？拿这些数据提需求，会更有理有据。

4. 解决方案是什么?

   • 关键点：在业务流程中，找到最关键的因素
   • 多种方案：有没有更多的方案？还是只有一种方案？
   • 难度评估：开发难度与效果的选择。用四象限分析，优先实现难度小、见效快的方案。

5. 结果如何评定？

   • 考核指标：用什么指标来评估产品的表现？
   • 数据对比：前后的数据对比是如何的？

完整小功能设计

1. 明确功能的目的

• 对用户：对哪类用户具体有什么好处？有没有受影响的用户？受到影响的用户的容忍度？影响面？会不会出现新问题？
  - 增加内容，提升准确度（如选择标签）
  - 减少操作，提升便利性（如推荐入口）
  - 功能补充，提升体验（如发票功能）

• 对平台（对内部）：对内部数据、操作人员是否提升了效率？
  - 增加渠道，引入新用户（如：分享功能、支持微信登录）
  - 减少重复的操作（如：增加教师库-》不用每次都粘贴一遍）
  - 数据分层，提升精准度（如：手机号码验证-》按城市群发短信）

• 对商业：是提高收入？还是提升了转化率？
  - 拉动付费转化率（如：两人付费，一人免单）
  - 增加新产品，创造新的收入点（如：在线订座）
  - 对原有数据做重新组合，提高数据转化率（如：地图找房）

• 对内讲效率,对外讲体验,对商业谈转化率

2. 明确功能基本逻辑

• 要达到目的，大概的逻辑是什么？
  • 用户的操作过程，如邮箱登录
  • 数据的流向，如输入邮箱后，需要给用户发信息或邮件，这个邮件怎么发送？发送什么内容？生成规则时什么？这些就是数据流向。数据流向是否清晰？
• 难点可能是什么？

3. 调研相关的其他产品功能

• 明确调研目的
• 观察体验“用户、场景、需求”是否被满足了？
• 猜测底层的逻辑
• 分析产品的流程
• 产品亮点和结论

4. 制定功能方案

• 可能的解决方案有哪些
• 梳理每个方案的简要业务流程
• 针对性的分析，选择合适的方案
• 开发难度/见效/用户场景/…

5. 方案细化

• 流程细化：梳理业务流程，增加异常情况
• 考核指标：上线后如何评定功能点的效果？

6. 原型设计与文档

• 通过业务流程获得页面流程
• 原型设计（真实场景、真实文案、黑白灰）
• 完成需求文档（或直接用原型标注解决）
• 需求评审

7. 运营推广方案

• 找位置：用户的关键路径在哪里？
• 定内容：匹配用户和场景，制定文案和推广形式
• 要效果：运营的转化效果如何？后续计划是什么？

业务流程设计基础

• 凡是有需求必有流程图
• 做产品就是做流程

1. 业务流程的作用

   • 功能优化：看之前业务流程，找改进点
   • 独立功能设计：单通道流程图，看用户、信息的流向
   • 独立产品设计：泳道图，复杂的用户、信息交互处理；如平台型产品：发起方、需求方、审核方；状态如：发起前、中、后；
   • 原型交互设计：页面流程图，规定页面的交互方向

2. 基本业务流程图包含什么

   • 事项：要完成的事情是什么？
   • 用户：分别有哪些人会参与到流程中
   • 信息：数据是怎么流转的？
   • 异常：出问题了，怎么处理？

3. 功能的业务流程图怎么画

    ![](http://oczbwvoof.bkt.clouddn.com/17-7-23/58194040.jpg)
   

4. 单通道的业务流程图技巧

• 主线清晰：关键路径、关键任务一目了然；

• 先主后次：先搞定关键路径，再补充细节路径；

• 优化调整：原型设计过程，优化异常流程；

• 先繁后简：先把最长路径想到，再合并操作流程；

• 矩形与用户操作有关，ui、ue关注；

• 菱形是后端研发、测试最关注的；

• 数据漏斗也是在页面流程这里产生的。

5. 业务流程图能力提升秘籍

   • 多看：多调研、体验各种同类功能点

   • 多想：用产品的视角想想为什么是这样的设计，产品视角就是流程视角。

   • 多画：基本功，没捷径，画100遍，自然就知道了

   • 多交流：多跟功底好的同事一起交流提升

   • 调研产品主要调研流程，做一个单独产品的流程调研，然后再分析其他的，多做对比。

05 原型设计与PRD入门

【一句话概括】上一步是通过流程图完成业务流程图的绘制，业务逻辑——业务流程——页面流程图。因此进一步再细化到页面流程，从而为原型设计做准备。所以这部分首先将

页面流程与页面结构图

• 业务流程》页面流程》原型设计
• 代表用户的操作过程，先做页面流程能快速发现体验问题
• 突出页面重点元素与逻辑关系，提升原型设计的效率

页面流程图（必需）和信息架构图（每个页面包含的内容）的区别

• 页面流程图，以用户视角，主要看流程的合理性；用户类产品必备
• 信息架构图，以产品视角，主要看包含多少功能点；可以列，也可以不列
• 页面流程图适合于跳转比较复杂的产品功能，如电商、社交产品
• 信息架构图适合于层级分明，跳转不复杂，如音乐产品、新闻客户端、阅读类产品等

过程

1. 回归业务流程，明确主线
2. 明确页面中重点元素

• 功能在页面中，有哪些是需要表现元素。
• 增加异常流程的处理逻辑。弹层、提示
• 增加辅助的帮助页面
• 考虑下游触发点

3. 沟通和优化

• 尽可能穷举涉及的页面，然后做减法
• 通过原型草图，优化调整页面关键元素
• 与UI、UE、前端研发等多沟通有更好的效果

原型设计的基本原则

什么是产品原型？

• PRD与原型都属于产品经理的重要产出。PRD更侧重于书面说明，类似于说明书，而不是展示；原型是功能页面结构的直接视觉呈现，造成的理解偏差会小一些。
• 好的原型
  | 整体感受 | 独立页面 | 交互设计 |
  | ------------------------------ | ------------------------ | ------------------- |
  | 页面结构清晰 跳转关系明确 与业务流程一致 完整表达用户需求 | 功能元素明确有序 位置关系清晰 不同状态变化清晰 | 清晰的交互逻辑 一致交互方式 界面统一 |

如何开始产品原型设计？

1. 从原型到上线的过程

重要	手绘	低保真	高保真	UI设计	上线
做什么	确定干不干	确定元素	交互设计	视觉设计
和谁做	自己思考	其他产品运营	UE/UX	UI

2. 做低保真原型之前，动手之前的忠告

• 产品需求没想明白之前，不要摸Axure
• 产品流程没理清楚之前，不要摸Axure
• 在你没有手绘草图之前，不要摸Axure
• 在你没把草图和boss过了基本确定之前，不要摸Axure
• 这几件事没做之前，先出低保真的话，那么你将面临大量改原型的工作。

3.开始原型设计

• 明确本次需求的用户与场景
• 认真研究需求的业务流程图
• 完成页面流程与目录：确定页面主要元素和主要功能点在哪里
• 确定页面框架：由前三步产出决定；
• 确定交互细节、串联；
• 讨论迭代细节修正；
• 画原型改原型的时间尽量控制在20%以内，原型修改通常是因为需求没封闭；

原型设计的好习惯

1. 先手绘，再上软件
2. 用真实比例，真实的文案
3. 不要上颜色、不要上颜色、不要上颜色
4. 目录树清晰 阅读流畅
5. 有修改记录 关键修改要重新保存文件
6. 紧扣需求主题 不横生枝节
   • 如果原型需要增加新功能，先考虑后端数据来源
   • 不要为了“长得好看”而增加新模块
   • 如果你觉得：一个功能在未来有可能出现扩展，那这个功能有必要出现在这个文档当中吗？

如何写需求文档

什么是需求文档？

• 俗称：MRD、PRD、BRD等，概念不重要，不同名称而已

• 效果：说明为什么要干，怎么干，干了后有什么效果

• 内容：明确产品背景、需求、流程、原型、交互等内容

• 谁看：需求文档的阅读对象：设计、研发、测试

有什么用？

• 内部沟通：
• 明确产品需求
• 明确产品要求和细节
• 让参与者明确实现的结果
• 存档：
• 有据可查，这很关键，防止遗忘
• 交接更容易，更职业
• 跟进者了解之前的做法和过程

高颜值的需求文档有什么特点？

• 结构：逻辑清晰，层次分明，团队内部有标准化的写作语言和结构，可以快速沟通
• 背景：需求背景描述清楚 VS 一上来就讲功能和原型
• 流程图：业务流程、页面流程均有 VS 一上来讲原型
• 目标：有考核指标、算法清楚 VS 没指标 凭感觉
• 习惯：变更过程清楚 VS 改来改去改回第一版

需求文档怎么写

1.项目背景与需求分析

• 谁提的需求？什么场景？遇到什么问题？（在需求分析中已经解决了，不需要再次思考，抄过来即可）
• 简要描述分析过程：决策过程和依据是什么？解决方案是什么？（这个就是需求的优先级排序和理由，简要的解决方案）
• 有没有相关的背景资料（有多少人用，有多少人出了问题，这就是数据指标，通过用户调研和数据分析得到的）
• 明确本次需求：用户、场景、需求、解决方案是什么？
• 不要搞得太复杂，这些背景和数据需求最好来自于你系统的、产品本身已有统计的，用第三方数据来做需求，是一点用都没有的。所以大家还是认认真真的分析自己产品本身产生的数据，向数据要迭代，向迭代要数据。

2. 本次需求的目的及功能列表

• 这个需求整体是什么样子的？是否要分阶段？
• 本次需求做哪些？前后关系是什么？
• 本次需求的功能清单有什么？具体细分到每一个功能点是什么？
• 涉及的功能或页面有什么？这个功能相关的页面、相关的功能有什么；本次需求功能关联的功能、关联页面、- 关联的系统。用于做对接。

3. 流程与所处的产品模块关系

• 业务逻辑图
• 业务流程图
• 页面流程图

4. 功能详细描述

• 交互设计图
• 原型图

5. 简要的测试用例（可选，需要专业的测试并配合很好）

• 关键的用例是什么？
• 重点关注点
• 错误提示表。excel表格做即可

6.考核指标

• 本次需求要统计哪些指标？
• 怎么计算？指标的计算方法。
• 怎么埋点？

06 项目管理入门-需求评审

【一句话概括】需求文档都完成之后就是开需求评审会议，从需求评审参加的人来准备需求评审的会前会中和会后。

需求评审

1. 什么是需求评审？

• 统一思想，明确需求，确定实现过程的会议
• 俗称挑刺大会，撕逼大会，逼死产品经理大会
• 通常评审会要经过几次，一次完成要拼“专业度”和“产品人品值”，正常要经过2到3次；
• 需求评审过程通常很激烈，通常会有很多类似问题逼问产品经理
• 这样做很麻烦，开发难度很大
• 你考虑清楚了吗？真的要这样做吗？
• 这个流程太复杂了，能不能简单一些
• 你这根本没考虑到实际情况
• 还有一种情况你没考虑到

2. 需求评审都有什么人参加？

3. 为什么非得做需求评审？

• 让所有人都明确需求的背景和目的。
• 提前确认和统一产品需求实现的过程和方法。
• 让参与者明确知道工作内容和交付时间。
• 让研发、测试评估产品开发周期，让产品经理做决定；

4. 如何组织一场成功的需求评审会？

【开场前的准备工作】

• 确认你的需求、文档、原型都完成了吗？
• 提前找核心人员小范围沟通，提前消灭掉大问题
• 和核心与会者确认可出席时间
• 至少提前2天发出会议邀请，定好会议室
• 会议邀请时主动带上需求文档和原型交互设计稿等相关资料
• 提前到会议室！提前演练一遍！

【评审会现场】

【评审会后】

• 追排期！追排期！追排期！当你的需求讲的不好的时候，要改的话，要把自己修改的时间和下一个会议时间定好；
• 整理遗留问题，并拿出解决方案
• 发出会议记录，每个问题都有行动计划
• 发出修改后的需求文档，并更新到内部系统中
• 约下一次的评审的时间（如需要）

本文由碎碎念创作

该文章采用知识共享署名-非商业性使用 4.0 国际许可协议进行许可。转载请注明出处！

发布时间为：2017-07-24