产品设计与需求分析

产品与需求
目 录
1 2 3 4 5 6
由一个产品UI说开去 由产品到需求 沟通
业务分析与表达 需求收集与管理
业务规划
UI演进举例——产品需求确定后的 表现差异
任务的目的是展示美国的几个城市在不同月份的平 均降水量。
体验设计要点
贴心功能
辅助指引
功能呈现
交互感受
信息展现
用户体验
场景下行为分析
Stakeholder列表 Stakeholder关注点
操作层要求
效率 质量
Stakeholder分析
高
影响度
尽力满足
关键玩家
低 低
最小努力
保持沟通
兴趣度
高
目 录
需求
产品设计中与需求相关的部分 产品设计是端到端的过程，端即用户，也就是从用户中来
到用户中去，最最开始的源头就是“为用户解决问题，满 足其需求”。产品需求过程三步骤：
在各个环节中会 出现例外吗？针 对这些例外如何 处理？
梳理主流程
梳理分支
分析异常情况
没有最好的图， 只有最合适的的 图，应根据流程 逻辑特点选择
一切正常的处理 流程是什么样的？ 需要相关的审核 点吗？
有没有完全不能 够按流程处理的 情况？有没有出 错的情况？
业务流程 vs. 业务功能
最终用户
管理者
需求发布流程
目 录
1 2 3 4 5 6
由一个产品UI说开去 由产品到需求 沟通
业务分析与表达 需求收集与管理
业务规划
业务规划--Why？What？How？
业务规划
Why
可做的事 想做的事 能做的事
What
一句话的业务定位 一个商业模型 几个个业务关键点
How
资源保障 计划安排 效果预估
靠谱的会议
行为
数据
质量
目 录
1 2 3 4 5 6
由一个产品UI说开去 由产品到需求 沟通
业务分析与表达 需求收集与管理
业务规划
业务流程八要素
规模 风险 专业
分工
异 常
分支
审核
协 作
并行 串行 异步
产物 关系
规 则
活动
业务流程分析
从服务请求到服 务满足，整个过 程涉及哪些角色 参与其中
选择合适的流 程图描述方式 标识流程中各 参与角色
UML建模标准 强调行为流 强调协作 技术类系统更常用
现场出图：流程分析加速器
客户代表陈述 一听 不要中途打断 绘出基本脉络
忽略 细节
草图 演化
具体的岗位 为指引 二问
分支与异常 其他细节
绘图者复述 三读 客户代表验证 达成共识
阅读用例图
目 录
1 2 3 4 5 6
由一个产品UI说开去 由产品到需求 沟通
质量属性的常见误区
顾此失彼 未能有效实现
需求简单复制 开发直接翻过
需求写不出 开发看不懂
定性描述
全局描述
盲目定量
模块：一般来说，每个模块下分3~10个子模 块是合理的，否则要考虑重新划分。 子模块：稍大一点的产品至少要给功能模块 做二级分类了。 功能：要给用户提供什么功能，功能名字。 功能描述：这里可以说具体一点。
，
产品团队
UE PM UI PD
产品定位—规划练习
最基本的句式：解决了什么用户的什么需求？
练习的时候，切忌求多，说一点即可，找到你感觉最贴切的 那一种用户，和他最迫切的那一个需求。
主要扩展有如下几种： 产生需求的场合是什么？
需求的应用场景，时间地点等，要有“故事感”，尽量找一 个能让人会心一笑的。
首先，明确目的，最最重要，其实做一个会议和做一个产品也是一样的。 不要试图在一个会议中解决所有的问题，就算你要连着召集两个参与人大 部分相同的会议，我也建议你把它们分开，甚至，更好的做法，合理安排 一个会议中的议题，可以让部分人早点走，或者晚点到。依据目的，类似 的日常会议一般在15min～2、3个小时不等。 会议前，做好资源的确认：会议室、投影仪等；更要做好人员的确认：确 认好“必选”的和“可选”的，不要漏人，也不要叫闲人，把握“大会决 定小事，小会决定大事”的原则。识别出会议的KP（Key Person，关键人 物），通常是最大的一个或几个老板，提前当面或者电话知会一下，然后 发出会议邀请。对于KP，争取提前与他讨论关键议题，达成一致，叫做 “串供”，这会让会上省很多时间和精力。正所谓，要想让会议不流于形 式，就要把会议本身变成走走形式。 所有事情，尽量在会上取得共识，给出“会议决议”，实在不行的可以作 为“遗留问题”。最后，牢记很实用的“所有人提供意见，少数人讨论， 一个人拍板”的民主集中原则。
持续的战略规划会

回顾截至到上次会议结束时的信息 1．上次会议讨论的重点问题是什么？ 2．关于这些问题我们达成了哪些一致意见？ 3．上次会议中哪些问题由于缺乏信息考证，不确定 性因素等原因而未能解决？ 4．上次会议哪些执行计划被通过了？对于这些执行 计划我们有哪些主要想法和设想？
业务价值抽象
场景是核心 重视情感需求
目 录
1 2 3 4 5 6
由一个产品UI说开去 由产品到需求 沟通
业务分析与表达 需求收集与管理
业务规划
目 录
产品
产品与项目的区别
项目是定制的，个性化的，为了满足一个或一批特定的客户 需求；而产品是服务一个用户群的，通用的。这就意味着， 项目要服务好那个特定的客户；而产品不能为了个别用户的 需求去定制，必须考虑用有限的资源去满足更多的、能有更 多回报的用户。
除了最终用户外，还有……
购买者
评价者
运营者
Stakeholder分析
1 Stakeholder列表： 筹码量分析—优先级
2 Stakeholder档案： 筹码付出—关注点
3 需求平衡与跟踪： 冲突识别、实现跟踪
不同层次的用户，其需求的价值 不同
项目目标 业绩差距(问题)
机会差距(机会)
业务价值
Stakeholder
由一个产品UI说开去 由产品到需求 沟通
业务分析与表达 需求收集与管理
业务规划
用户为什么说不清需求
易于放大需求
问Why
不讲需求背后 的原因
需求零散，思 考不足
结构化提问
马斯洛需求层级
需求问题就是沟通问题
沟通哲学
从功能到卖点
产品做出来，还要卖出去。前者是“需求到功能”， 可以对应到“产品设计”的职能，后者是“功能到卖 点”，对应产品运营。
解决方案：木制 的小板凳
意识：需求三要素
问题 Why 业务背景 Context 解决方案 What
1、澄清问题（问题表象+原因+范围与限定）
2、了解业务背景（业务场景[谁、什么时候、怎么做]+ 业务术语+变化/约束/扩展……） 3、建议并确认解决方案（问题有效解决+成本合适）
目 录
1 2 3 4 5 6
源自文库
跨职能流程图——视频侦缉
描述流程：选择正确的工具
UML建模标准 语义最丰富 强调行为流 强调活动内容 IDEF建模标准 强调数据流 未表示出谁执行 计费类系统最适用
跨职能 流程图
活动图
时序图
数据 流图
商业建模标准 复用性强 用户最容易接受 并行、异步支持差
需求管理
采集产品干系人（广义用 户）提出的各种需求，整 理转化为产品需求，即 “需求转化”。 “确定属性”即这个需求 是属于产品的哪个模块？ 是基本/扩展/增值功能？ 是功能/性能/用户体验方 面？等。属性的维度可按 照产品的不同自由定义， 原则是为了便于需求管理。
• feature list，每隔一段时间、或新需求积累到一定数量、或是由特别事件触 发，进行“确定商业价值（产品内PK）”。会议上讨论所有状态为“待讨 论”的功能点，需求状态一定要变化，进入“需求中”/“拒绝”/“暂缓”。 拒绝的需求是被认为对产品的商业目的没有价值的，而暂缓的需求是“有价 值，但是现在不做”的，通常要表明重启的条件。
需求列表到功能列表
商业价值描述：卖点是什么，可以给用户提供什么价值。 商业属性：简单分为基本，扩展，增值。 商业优先级：这块是整个Feature List工作中核心的部分，判断的准确直接影 响着将来产品的方向。先基于自己对商业目标的理解，主观定级别，然后再 PD团队pk，如有必要，再去客户处确认。 开发量：一般由技术部门的项目经理或者系统分析师/架构师来确定。 性价比：综合商业属性、优先级与开发量来确定一个合适产品的计算方法。 备注：
需求采集
需求分析
需求管理
产品创意源于三新
人群特点变化 带来的机会
技术创新 带来的机会
新业务模式 带来的机会
新技术
新人群
新业务
手段
特点
模式
产品灵感源于需求洞察
现状 预期
产品
现状 预期
预期 问题 现状
现状
预期
预期 现状 机会
需求的三层次
Want
Need
店主问：你想用冲 店主问：您为什么 击钻来解决什么问 想在墙上打个孔呢？ 店主答：对不起， 题呢？ 我们这没有冲击钻 卖，你到别处看看。 小张答：我想在墙 小张答：想在墙上 上挂幅画。 打个孔
产品设计期需求 需求类型：（在进行评审时填写）
原因（Why）：（保持怀疑的心，很多时候理由是假想出来的）
验收标准（How）： 1. 用量化的语言 2. 无法量化寻找标竿 需求重要性权重（How much）： 满足后（1一般~5非常高兴） 未实现（1略感遗憾~5非常懊恼）
售后/运营该如何提需求
目标用户：这件事，是为谁而做的，一旦售后填写这个就可以自己排除掉很多 需求了； 问题描述：目标用户碰到的痛点，只说“何时/何地，怎么难受”即可； 严重程度：对问题严重程度的判断，“高/中/低”即可，具体的判断方法，可 以根据用户重要程度，问题出现的次数、频率等因素考虑； 现有方案：现在是如何解决此问题的。一般来说，一个值得解决的问题，通常 已经有人着手想方案了，也一定已经有一些解决方案，而没有现有方案的问题， 通常不严重； 建议方案：建议的产品改进 ，催促售后换位思考，产品不一定采纳； 价值描述：改进方案带来的额外价值，比如：省时间；能更精准的找到某 某…… 改进成本：建议方案的成本评估，“高/中/低”，同样，仅供参考。 产品拿到一堆需求以后，主要根据性价比决定接下来做什么。 性价比 = 严重程度/改进成本，问题（用户需求）决定严重程度，解决方案 （产品功能）决定改进成本。
需求确认 •
动态功能列表是对每个需 求加上跟踪状态属性，能 实时看到“何时做，谁来 做，状态如何”。 • 负责人：细分为需求提出 者（备注原始需求）、需 求负责人、开发负责人、 测试负责人，属于哪个项 目…… • 需求状态：通常有“待讨 论”、“拒绝”、“暂 缓”、“需求中”、“开 发中”、“已完成”几个 状态，可按实际情况增减。 • 时间信息：提出时间、录 入时间、发布时间……
3+1思考法：测量产品/项目“靠谱程 解决之后在软 度” 需求是从哪
里来的？目 标客户是谁？ 件数据上会有 二次挖掘价值 吗？
有多少人有 这样的需求？ 这个需求紧 迫吗？
他们的痛是什 么？场景是什 么？（用产品 之前/之后）
目 录
用户
找到种子用户
受要解决的问题困扰最深的人！
愿意配合 可以提供很多有价值的信息 可以忍受缺陷 乐意成为义务推销员
产品的主要功能有哪些？
需求和功能的区别在于，前者是从用户角度说的，是一种希 望，利益点，这时候还没有产品，后者是从产品属性上说的。
方便面产品 解决了什么用户的什么需求？
产生需求的场合是什么？ 产品的主要功能有哪些？ 技术基础是什么？ 没有这个产品的时候，用户是怎 么解决问题的？ 竞争对手是什么？ 顺应了什么趋势？
业务分析与表达 需求收集与管理
业务规划
需求编号： 包含“采集时刻 + 采集者”信息
功能需求、非功能需求…… 来源（Who）：（方便追根溯源） 公司提供者：需求提供者的部门、联系方式 产生需求的客户：用户需求的公司、部门、联系方式 客户背景资料：受教育程度、岗位经验、其他与本单项需求相关经 验
场景（Where、When）： 产生该需求的用户活动特定的时间、地理、环境 描述（What）： 用（主语+谓语+宾语）的语法结构，禁止使用修饰语句
成败案例分析(1)
帐户管理 基本交易 网上支付 ……
借记卡
网上银行
信用卡 基 金
……
孰优孰劣？
产品卖点需求全景
关 键 需 求
右脑需求：感觉、情感、外观、设计…… 吸引
左脑需求：实用、痛点、逻辑、功能…… （高层：解决问题/创造机会；中层：管理/控制）
购买
详 细 需 求
业务子系统/ 功能域
再次 购买
Win
店主问：您为什么 想在墙上挂幅画呢？ 小张答：我下班回 家，单身一人太冷 清，挂幅画热闹点。
小张问店老板：你 这里有卖冲击钻吗？
暴食、贪婪、懒惰、嫉妒、骄傲、淫欲、愤怒
意识：需求三要素
板多大、多宽、 多厚？
问题：放花盆
木桩什么形状， 钉在什么位置？
业务背景：花盆 种类、摆放位置
要几枚铁钉，多 长多大？