Stakeholder列表 Stakeholder关注点
操作层要求
效率 质量
Stakeholder分析
高
影响度
尽力满足
关键玩家
低 低
最小努力
保持沟通
兴趣度
高
目 录
需求
产品设计中与需求相关的部分 产品设计是端到端的过程，端即用户，也就是从用户中来
到用户中去，最最开始的源头就是“为用户解决问题，满 足其需求”。产品需求过程三步骤：
行为
数据
质量
目 录
1 2 3 4 5 6
由一个产品UI说开去 由产品到需求 沟通
业务分析与表达 需求收集与管理
业务规划
业务流程八要素
规模 风险 专业
分工
异 常
分支
审核
协 作
并行 串行 异步
产物 关系
规 则
活动
业务流程分析
从服务请求到服 务满足，整个过 程涉及哪些角色 参与其中
选择合适的流 程图描述方式 标识流程中各 参与角色
由一个产品UI说开去 由产品到需求 沟通
业务分析与表达 需求收集与管理
业务规划
用户为什么说不清需求
易于放大需求
问Why
不讲需求背后 的原因
需求零散，思 考不足
结构化提问
马斯洛需求层级
需求问题就是沟通问题
沟通哲学
从功能到卖点
产品做出来，还要卖出去。前者是“需求到功能”， 可以对应到“产品设计”的职能，后者是“功能到卖 点”，对应产品运营。
UML建模标准 强调行为流 强调协作 技术类系统更常用
现场出图：流程分析加速器
客户代表陈述 一听 不要中途打断 绘出基本脉络
忽略 细节
草图 演化
具体的岗位 为指引 二问
分支与异常 其他细节
绘图者复述 三读 客户代表验证 达成共识
阅读用例图
目 录
1 2 3 4 5 6
由一个产品UI说开去 由产品到需求 沟通
成败案例分析(1)
帐户管理 基本交易 网上支付 ……
借记卡
网上银行
信用卡 基 金
……
孰优孰劣？
产品卖点需求全景
关 键 需 求
右脑需求：感觉、情感、外观、设计…… 吸引
左脑需求：实用、痛点、逻辑、功能…… （高层：解决问题/创造机会；中层：管理/控制）
购买
详 细 需 求
业务子系统/ 功能域
再次 购买
持续的战略规划会

回顾截至到上次会议结束时的信息 1．上次会议讨论的重点问题是什么？ 2．关于这些问题我们达成了哪些一致意见？ 3．上次会议中哪些问题由于缺乏信息考证，不确定 性因素等原因而未能解决？ 4．上次会议哪些执行计划被通过了？对于这些执行 计划我们有哪些主要想法和设想？
质量属性的常见误区
顾此失彼 未能有效实现
需求简单复制 开发直接翻过
需求写不出 开发看不懂
定性描述
全局描述
盲目定量
模块：一般来说，每个模块下分3~10个子模 块是合理的，否则要考虑重新划分。 子模块：稍大一点的产品至少要给功能模块 做二级分类了。 功能：要给用户提供什么功能，功能名字。 功能描述：这里可以说具体一点。
产品与需求
目 录
1 2 3 4 5 6
由一个Байду номын сангаас品UI说开去 由产品到需求 沟通
业务分析与表达 需求收集与管理
业务规划
UI演进举例——产品需求确定后的 表现差异
任务的目的是展示美国的几个城市在不同月份的平 均降水量。
体验设计要点
贴心功能
辅助指引
功能呈现
交互感受
信息展现
用户体验
场景下行为分析
产品的主要功能有哪些？
需求和功能的区别在于，前者是从用户角度说的，是一种希 望，利益点，这时候还没有产品，后者是从产品属性上说的。
方便面产品 解决了什么用户的什么需求？
产生需求的场合是什么？ 产品的主要功能有哪些？ 技术基础是什么？ 没有这个产品的时候，用户是怎 么解决问题的？ 竞争对手是什么？ 顺应了什么趋势？
3+1思考法：测量产品/项目“靠谱程 解决之后在软 度” 需求是从哪
里来的？目 标客户是谁？ 件数据上会有 二次挖掘价值 吗？
有多少人有 这样的需求？ 这个需求紧 迫吗？
他们的痛是什 么？场景是什 么？（用产品 之前/之后）
目 录
用户
找到种子用户
受要解决的问题困扰最深的人！
愿意配合 可以提供很多有价值的信息 可以忍受缺陷 乐意成为义务推销员
业务分析与表达 需求收集与管理
业务规划
需求编号： 包含“采集时刻 + 采集者”信息
功能需求、非功能需求…… 来源（Who）：（方便追根溯源） 公司提供者：需求提供者的部门、联系方式 产生需求的客户：用户需求的公司、部门、联系方式 客户背景资料：受教育程度、岗位经验、其他与本单项需求相关经 验
场景（Where、When）： 产生该需求的用户活动特定的时间、地理、环境 描述（What）： 用（主语+谓语+宾语）的语法结构，禁止使用修饰语句
跨职能流程图——视频侦缉
描述流程：选择正确的工具
UML建模标准 语义最丰富 强调行为流 强调活动内容 IDEF建模标准 强调数据流 未表示出谁执行 计费类系统最适用
跨职能 流程图
活动图
时序图
数据 流图
商业建模标准 复用性强 用户最容易接受 并行、异步支持差
产品设计期需求 需求类型：（在进行评审时填写）
原因（Why）：（保持怀疑的心，很多时候理由是假想出来的）
验收标准（How）： 1. 用量化的语言 2. 无法量化寻找标竿 需求重要性权重（How much）： 满足后（1一般~5非常高兴） 未实现（1略感遗憾~5非常懊恼）
售后/运营该如何提需求
目标用户：这件事，是为谁而做的，一旦售后填写这个就可以自己排除掉很多 需求了； 问题描述：目标用户碰到的痛点，只说“何时/何地，怎么难受”即可； 严重程度：对问题严重程度的判断，“高/中/低”即可，具体的判断方法，可 以根据用户重要程度，问题出现的次数、频率等因素考虑； 现有方案：现在是如何解决此问题的。一般来说，一个值得解决的问题，通常 已经有人着手想方案了，也一定已经有一些解决方案，而没有现有方案的问题， 通常不严重； 建议方案：建议的产品改进 ，催促售后换位思考，产品不一定采纳； 价值描述：改进方案带来的额外价值，比如：省时间；能更精准的找到某 某…… 改进成本：建议方案的成本评估，“高/中/低”，同样，仅供参考。 产品拿到一堆需求以后，主要根据性价比决定接下来做什么。 性价比 = 严重程度/改进成本，问题（用户需求）决定严重程度，解决方案 （产品功能）决定改进成本。
，
产品团队
UE PM UI PD
产品定位—规划练习
最基本的句式：解决了什么用户的什么需求？
练习的时候，切忌求多，说一点即可，找到你感觉最贴切的 那一种用户，和他最迫切的那一个需求。
主要扩展有如下几种： 产生需求的场合是什么？
需求的应用场景，时间地点等，要有“故事感”，尽量找一 个能让人会心一笑的。
在各个环节中会 出现例外吗？针 对这些例外如何 处理？
梳理主流程
梳理分支
分析异常情况
没有最好的图， 只有最合适的的 图，应根据流程 逻辑特点选择
一切正常的处理 流程是什么样的？ 需要相关的审核 点吗？
有没有完全不能 够按流程处理的 情况？有没有出 错的情况？
业务流程 vs. 业务功能
最终用户
管理者
需求发布流程
目 录
1 2 3 4 5 6
由一个产品UI说开去 由产品到需求 沟通
业务分析与表达 需求收集与管理
业务规划
业务规划--Why？What？How？
业务规划
Why
可做的事 想做的事 能做的事
What
一句话的业务定位 一个商业模型 几个个业务关键点
How
资源保障 计划安排 效果预估
靠谱的会议
需求列表到功能列表
商业价值描述：卖点是什么，可以给用户提供什么价值。 商业属性：简单分为基本，扩展，增值。 商业优先级：这块是整个Feature List工作中核心的部分，判断的准确直接影 响着将来产品的方向。先基于自己对商业目标的理解，主观定级别，然后再 PD团队pk，如有必要，再去客户处确认。 开发量：一般由技术部门的项目经理或者系统分析师/架构师来确定。 性价比：综合商业属性、优先级与开发量来确定一个合适产品的计算方法。 备注：
需求确认 •
动态功能列表是对每个需 求加上跟踪状态属性，能 实时看到“何时做，谁来 做，状态如何”。 • 负责人：细分为需求提出 者（备注原始需求）、需 求负责人、开发负责人、 测试负责人，属于哪个项 目…… • 需求状态：通常有“待讨 论”、“拒绝”、“暂 缓”、“需求中”、“开 发中”、“已完成”几个 状态，可按实际情况增减。 • 时间信息：提出时间、录 入时间、发布时间……
首先，明确目的，最最重要，其实做一个会议和做一个产品也是一样的。 不要试图在一个会议中解决所有的问题，就算你要连着召集两个参与人大 部分相同的会议，我也建议你把它们分开，甚至，更好的做法，合理安排 一个会议中的议题，可以让部分人早点走，或者晚点到。依据目的，类似 的日常会议一般在15min～2、3个小时不等。 会议前，做好资源的确认：会议室、投影仪等；更要做好人员的确认：确 认好“必选”的和“可选”的，不要漏人，也不要叫闲人，把握“大会决 定小事，小会决定大事”的原则。识别出会议的KP（Key Person，关键人 物），通常是最大的一个或几个老板，提前当面或者电话知会一下，然后 发出会议邀请。对于KP，争取提前与他讨论关键议题，达成一致，叫做 “串供”，这会让会上省很多时间和精力。正所谓，要想让会议不流于形 式，就要把会议本身变成走走形式。 所有事情，尽量在会上取得共识，给出“会议决议”，实在不行的可以作 为“遗留问题”。最后，牢记很实用的“所有人提供意见，少数人讨论， 一个人拍板”的民主集中原则。