• 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天发出会议邀请，定好会议室
• 会议邀请时主动带上需求文档和原型交互设计稿等相关资料
• 提前到会议室！提前演练一遍！

【评审会现场】

【评审会后】

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