有没有遇到这种情况，产品需求写的明明白白，你兢兢业业输出完交互，方案评审没有通过，你略带委屈感觉锅从天上来：『产品经理就是这么要求的』。
只能说，没有经过拆解分析的需求背后，或多或少都有一个坑在等着你，接触到的设计师大都有自己的方法理解需求，但为什么总还会被『找茬』呢，我们不妨一起拆解分析下。以下分析建立在迭代需求里，从零到一的产品另说另说...
〇、产品形态分析
手机 ROM 的产品需求，大概分为两类『工具型』和『服务型』。
工具型产品 —— 产品目的明确，功能路径相对单一，比如：全局搜索、天气、相机、指南针、密码解锁等；
服务型产品 —— 产品服务多样，业务路径多线并联，比如：负一屏、U 健康、日历、锁屏等；
花两分钟想清楚产品形态，因为两者在业务分析和需求分析各有侧重，需求时的思路和侧重点不同，在接下来的环节分别描述。
一、业务分析
一切需求的起点是了解业务目标，不然就像低头走路，无论多顺利都无法到达终点。基于业务目标我们会得到『北极星指标』，作为产品 or 设计的唯一关键指标。
服务型产品对比工具型产品，受多条业务相互影响， 暂排除产品整体改版，服务型产品在迭代中，每个需求解决的问题也是唯一的，所以无论是服务型还是工具型，需求的业务目标是唯一的。
北极星指标的明确可验证对业务目标的理解，feature team 内，业务目标的同步，一定程度会减少说服成本，甚至提高解决问题的效率。
二、需求分析
业务目标 = 目标用户 + 场景 + 用户行为 + 用户体验目标
这样，我们的分析由『业务目标』转移到『用户需求』，理解解决 When / Where / What 的问题，翻译概述为『目标用户，在哪 / 什么时候，通过做什么，解决什么问题』。
服务型产品因为服务多样，侧重在『场景+用户行为』，而『用户体验目标』则需要具体到每个服务中展开；工具型产品因为服务相对清晰，侧重在『用户行为+用户体验目标』。
我们以一个服务型产品 —— 锁屏画廊举例：
三、基于用户拆解
为产品策略和设计方案做准备，开始进入解决 3W 的问题。在业务视角强化用户意愿，『增强动机』和『降低犹豫』；在用户视角，为用户扫清『障碍』。
强化用户意愿，是洞悉人性的过程，解决在用户情感负担，降低决策成本，所以才有『不要让用户思考』的说法。
为用户扫清障碍，具体到用户决策后执行阶段，更小的流程颗粒度解决障碍，用户更顺话通过业务路径。
四、汇集与总结方案
当我们穷举出对应动机、犹豫和障碍的设计策略，基于目标用户和场景优先级，筛选并融合给出产品策略和设计方案的最优解。
在日常设计工作中，也许会习惯性代入对某个环节的理解，导致无意识『入坑』。规范地拆解需求大概有以下好处：
- 反向规范产品经理与项目经理的需求文档，检验需求信息的完整；
- 设计层面进行评估，促进 feature team 达成共识；
- 在没有明确需求时，找到优化与迭代的方向；
五、数据验证
设计方案永远是在验证后才进入完成阶段，在开始明确的北极星指标，以及其他关键数据要在上线前埋点。通过对比数据得到『方案的验证』『问题挖掘的验证』『用户定义的验证』；进而下一次产品迭代的需求和评估，提供必须的支撑。
写在最后
回顾设计需求的拆解分析，还是以拆解驱动分析，以目标验证方案的过程，最终实现工作流的闭环。
在手机 ROM 的产品设计中，目标用户相对模糊，场景更是有硬件、通信、现实环境的多样性特点。交互设计在产品需求工作流中，不仅要提供『用户界面与流程细节』的设计，更是要尽可能明确与验证『目标用户』的目标，以及延展体验链路的『场景颗粒度』。
以上，是面对设计需求时的拆解分析，也可用于产品体验分析。
网友评论