2、需求分析：如何收集用户需求、需求优先级排序、从需求到Topic的映射方法

很多设计师拿到需求就开始画图，结果改到怀疑人生。为什么？因为需求没吃透。

我见过太多团队，产品经理扔过来一句话「做个登录页」，设计师就吭哧吭哧开始画。画完了才发现，要支持登录、要区分管理员和普通用户、还要做忘记密码流程……全得重来。

说白了，需求分析是Topic设计的根基。根没扎稳，后面全是白费功夫。

2.1 用户需求收集：别等需求「砸」到你头上

我个人的习惯是，主动出击。不要坐在工位上等PRD，那玩意儿往往写得不全。

2.1.1 需求来源有哪些？

我把需求来源分成三类，你想想看，你平时是不是只关注了第一类？

需求来源	具体渠道	我踩过的坑
显性需求	PRD、产品会议、用户访谈记录	PRD里写「支持搜索」，但没说是模糊搜索还是精确搜索
隐性需求	用户行为数据、客服反馈、竞品分析	用户嘴上说「想要更多功能」，实际行为却是「越简单越好」
边界需求	异常流程、极端场景、技术限制	没考虑网络差的情况，结果用户断网时页面白屏了

我记得有一次做B端后台，产品说「加个导出功能」。我多问了一句：「导出什么格式？数据量多大？要不要带筛选条件？」结果发现，他们要导出10万条数据，而且要求Excel格式。如果我不问，直接做个CSV导出，上线那天就是我被骂的那天。

2.1.2 收集需求的「三板斧」

1. 问对的人——别只问产品经理，去问真实用户、问客服、问开发。每个人视角不同。
2. 看对的数据——用户说的不一定是他真正做的。用数据说话，比如点击热力图、漏斗转化率。
3. 模拟真实场景——把自己当成用户，走一遍完整流程。你会发现很多「想当然」的漏洞。

2.2 需求优先级排序：什么都想做，就什么都做不好

需求收集了一大堆，然后呢？全做？别闹了。资源有限，时间有限，必须排优先级。

我见过最惨的项目，就是团队把50个需求全排进一个版本，结果每个都做成了半成品。上线后用户反馈：「你们这玩意儿到底想解决什么问题？」

2.2.1 我的排序方法：RICE模型

市面上有很多排序模型，Kano、MoSCoW、RICE……我个人最常用的是RICE。为什么？因为它把「做这件事的代价」也考虑进去了。

维度	含义	打分方式（1-5分）
Reach（覆盖）	这个功能会影响多少用户？	5分=所有用户，1分=极少数用户
Impact（影响）	对用户核心体验的提升有多大？	5分=解决核心痛点，1分=可有可无
Confidence（信心）	我们对这个需求的判断有多确定？	5分=有数据支撑，1分=纯猜测
Effort（投入）	开发+设计需要多少工作量？	5分=很小，1分=非常大（注意：Effort越高分越好）

最终得分 = (Reach × Impact × Confidence) / Effort。得分越高，越优先做。

2.2.2 避坑指南：别被「老板需求」带偏

我曾经遇到过一个情况：老板说「加个AI助手，显得我们很科技」。我拿RICE一算，Reach=1（只有老板自己用），Impact=1（对核心业务没帮助），Confidence=1（老板自己都不知道要什么），Effort=5（开发量巨大）。得分0.2。

但我当时没敢说。结果呢？做了三个月，上线后没人用，最后砍掉了。浪费了三个月的资源。

所以我的建议是：用数据说话，用模型说话。老板也是讲道理的，只要你把「为什么不做」的逻辑讲清楚。

2.3 从需求到Topic的映射方法：把「要什么」变成「怎么做」

需求排好序了，接下来就是关键一步：把需求翻译成Topic。

什么是Topic？就是一个可独立设计、可独立开发、可独立测试的功能单元。比如「用户登录」是一个Topic，「忘记密码」是另一个Topic。

2.3.1 映射的核心原则：一个需求 ≠ 一个Topic

很多新手会犯这个错：产品说「做个个人中心」，他就把「个人中心」当做一个Topic来设计。结果发现里面包含了头像修改、昵称修改、密码修改、收货地址管理……十几个功能全揉在一起，设计稿乱成一锅粥。

正确的做法是：把需求拆解成最小可交付单元。

2.3.2 映射三步法

1. 拆解需求——把一个大需求拆成多个原子功能。比如「个人中心」拆成：头像管理、基本信息编辑、密码修改、收货地址管理。
2. 识别依赖——哪些Topic之间有先后关系？比如「登录」必须在「注册」之后做？不一定，但「忘记密码」必须依赖「登录」页面存在。
3. 定义边界——每个Topic的输入是什么？输出是什么？交互流程是什么？异常状态怎么处理？

举个例子，我之前做过一个「商品详情页」的Topic。拆解后是这样的：

• Topic A：商品基本信息展示（图片、标题、价格）—— 无依赖，先做
• Topic B：规格选择（颜色、尺寸）—— 依赖Topic A，因为要先展示商品
• Topic C：加入购物车 —— 依赖Topic B，因为要先选规格
• Topic D：收藏功能 —— 无依赖，但优先级低，可以后做

这样排下来，开发可以并行做Topic A和D，然后做B，最后做C。效率高得多。

2.3.3 映射结果的可视化

光说理论不够，我画了一张图，帮你把整个流程串起来。

2.4 本章小结：需求分析做得好，后面设计没烦恼

说了这么多，其实核心就三件事：

• 收集要全——别漏掉隐性需求和边界需求
• 排序要狠——用RICE模型，砍掉低价值需求
• 映射要准——一个Topic就是一个可独立交付的单元