在设计师工作的做好总结过程中，所承接的需求需求大多来源于产品 。产品作为需求的评估主要提出者
，自然承担了大部分的厂高需求分析工作 。但这不仅仅是设计师何手产品的事儿 ，设计师对于需求分析也有很大的做好总结必要性。

那么产品和设计做需求分析有什么区别呢 ？需求

结合产品五要素来看，产品更多思考战略层和范围层的评估内容 ，更偏向于从商业维度制定产品目标，厂高以及考虑手里有哪些资源可以满足用户诉求 。设计师何手

设计师主要在结构层
 、做好总结框架层和表现层发挥价值 。需求要在充分理解产品目标的评估基础上，从用户角度出发，厂高深入了解用户的需求和期望，辨别需求是否解决了用户本质诉求
。同时
，设计师也要结合产品目标
，权衡商业和用户体验，采用合适的形式把需求表达出来
。

设计师&产品经理需求评估的差异

一、为什么做需求评估

理想的需求来源，是将产品的目标
、用户群体
、业务流程 、涉及的关联模块都捋明白之后，再进入设计流程 。但在实际工作过程中
，往往受限于版本排期、需求来源多样等因素，加之不同岗位业务视角的局限性
，需求本身并不一定思考得非常全面，这个时候就体现出了需求评估的必要性。

同时，设计师做好需求评估也有以下三方面的益处
：

设计师为什么做需求评估

1. 增强业务理解

在互联网公司 ，一般会设置产品 、设计
、开发、测试、运营等不同岗位，虽然大家工作的内容千差万别，但是都是为了打磨好同一个产品 ，有着共同目标。设计师站在用户体验的角度 ，从不同岗位的视角充分审视需求，也可以将问题提前暴露出来 ，保证方向的正确性
。

对于设计师本人而言 ，当需求没有理解透彻时，会让我们的思考方式非常受限。进行需求评估，在自己有疑问时不断追问"为什么"，直到找到问题最本质的原因，有利于不断加深对业务的理解 ，从而发挥出更大的价值
。

2. 提高做事效率&效果

如果在接到需求后，感觉有了一些想法
，就马上开始进入设计流程，从而遗漏了对需求 、场景及用户等的深入了解和分析过程，可能导致在方案推进过程中不断暴露出各种问题，甚至出现方向性错误导致整体被推翻重来 ，影响项目进程。

同时，如果只是简单转译产品的需求单
，缺少站在用户角度思考的独到见解  ，产出的设计一定是平平无奇缺少亮点的 。在满足产品功能的前提下，思考用户在当前场景还会有什么痛点、是不是可以给用户带来额外的惊喜，才能产出更加优秀和具有灵魂的设计 。

在接到需求时先对需求充分评估，而不是一味地"埋头苦干"，才可以达到又快又好的结果。

3. 增强影响力

如果我们只是做被交代的工作、做产品的"工具人" ，是很难在项目中获得影响力和话语权的，需求评估就是我们展现能力的"关键环节"。

作为设计师，要增强主动性并培养责任心 ，运用自己的专业能力
，推动产品项目更快更好地发展，逐渐具备发现问题和机会的洞察力与敏感度 。需求评估的过程也是不断提升在团队中的领导力和影响力的过程 ，有利于树立专业靠谱的设计师形象，形成工作中的良性循环。

总而言之 ，做事的宽度决定了你的优秀程度 ，责任越大能力项的成长就越快，从线框仔/美工成长为优秀的体验设计师，需求评估是我们需要不断提升的重要能力项。

二
、如何做需求评估

需求评估可以细分为三个阶段 ：了解识别、分析评估和结论确认。在了解识别阶段 ，主要目标是明确需求是不是要做。在分析评估阶段，需要对需求进行深入分析，以便对需求实施方案有清晰的认识 ，对如何做心中有数。最后，在结论确认阶段，需要对有疑问的问题与各业务方进行确认并达成共识 ，以确保在进入设计阶段之前对需求的基本内容没有疑虑。

需求评估的流程阶段

1. 了解识别阶段

进行需求评估的前提是要清楚自己在何时应该介入评估，只有清楚自己岗位的项目流程，才能做事及时准确
。

在进入设计流程前，会经历一系列的需求调整阶段 ，通常会在"需求形成-需求发出-需求评审"这三个阶段进行需求评估
。在这三个阶段中，如果有任何疑问或不同意见 ，都应该及时主动提出，尽量避免将问题遗留到策划评审之后才提出 ，将风险转嫁到设计环节 。

项目流程中的需求评估阶段

产品来找设计师沟通需求时，往往会带上自己输出的原型图或者视觉风格建议 。这时要避免过早陷入到对于细节的纠结当中 ，从而忽略对需求本质的判断 。

在了解识别阶段要做好信息输入 ，设计师要对需求进行不断的提问，了解为什么要做这个需求 ，目标用户是谁 ，要达成什么产品目标 ，需求的衡量标准是什么等等。这个阶段的主要目标是对需求有宏观认识
，帮助我们后续理清设计思路。

2. 分析评估阶段

在了解识别阶段只是大致辨别需求真伪，初步评估需求合理后要更深入地审视需求 ，做进一步的需求评估，主要从需求必要性、需求可行性、衡量标准和项目节奏几个方面展开
。

需求评估的五个维度

①需求必要性

评估需求必要性的目的是明确需求做不做的问题。在工作过程中，由于产品经理和设计的职能不同，因此立场有差别是很正常的 。我们不能一味地接受需求，但也不能盲目地拒绝需求 。要立足于用户体验并充分理解产品目标再进行需求必要性的评估。

需求一般可以分为常规需求和战略/政策需求 ，不同需求评估维度也有所差异，比如政策/战略需求可以不用花太多时间精力考虑其必要性，直接分析可行性等内容。

常见需求类别

常规需求又可以进一步细分为优化迭代需求和新产品/改版需求 。迭代需求一般是和现有功能做比较，明确为什么要做这个需求
，和现有功能相比解决了用户什么问题，有什么数据/用研等结论做支撑等等。和迭代需求相比，新产品/改版需求要进一步挖掘产品定位是什么 ，用户是谁有什么特征，对标的竞品是什么等问题。

②需求可行性

需求可行性主要是指对需求本身进行深入挖掘 ，思考依据产品目标可以有哪些解决方案 ，每个方案的可行性怎么样 。这里并不要求输出最终全部的方案内容，仅评估方向正确即可。

需求可行性评估流程

以下面这样一个需求为例
：

搜索联想 CPD 增加负反馈能力

设计需求单详情

为帮助大家更好地解读需求，首先解释几个概念。

搜索联想：在候选词下方实时展示其他联想词的功能，点击联想词就可以直接跳转到对应的搜索结果内容 ，以帮助用户缩短搜索路径 ，快速获取信息。

CPD：在产品中引入的一些广告内容
，通过用户下载量来获取收益。

负反馈 ：用户表达对产品或功能的不满意程度，并提供改进建议的能力。

因此，这个需求是说，在用户使用浏览器搜索内容时，浏览器在搜索联想词中引入了一些应用广告内容 。如果用户对这些 CPD 应用不感兴趣或不符合需求，可以通过负反馈机制告诉浏览器的搜索引擎 ，搜索引擎会根据用户的反馈进行调整和优化，提高推荐 CPD 应用的准确性，从而提升用户体验 。

在需求单中，产品已经给了详尽的解决方案 ，似乎只需要将它转化为原型图即可
。但是否真是如此呢？此时不要忘记多问几个"为什么"。这里我们也可以运用抽象阶梯的思维方式不断向上抽象层级 。

抽象阶梯是一种巧妙构建问题的工具，它可以帮助我们更清楚地解决问题。以我们提出的最初始的问题为起点，在阶梯中上上下下地去移动 。向上移动以扩大范围
，逐步寻找问题的本质原因；向下移动不断探究细节，发散问题 。

抽象阶梯思维原型

例如 ：

1. 为什么"要做负反馈"
2. "用户反馈投诉多"
3. 为什么"反馈投诉多"
4. "相关性差 ，又占据可视空间，影响浏览操作"

抽象阶梯应用示例

通过抽象阶梯不断向上，我们推导出问题的本质是搜索联想 CPD 的存在干扰了用户对联想词的浏览筛选。

那基于这个问题我们是否还可有其他的方案呢
？我们可以使用 HMW 的思考方法快速发散出策略方案。

HMW，全称"How Might We" ，即"我们可以怎样" ，其中：

How：表示假设问题是可以解决的，只是还没找到解决的方法

Might ：表示不要用具体的实现细节来限制发散方向，暗示可能性的重要性。在思考时只给出大致的思路方向即可，注重发散的广度 。

We
：强调团队的重要性，一个人的思维是局限且单调的 ，要让更多的人都参与到发散当中来，才有机会产生更有创造力的想法并发挥团队的作用解决问题 。

运用这个方法可以改变我们固有的思维逻辑方式，防止自己圈定在一个圈层或者方向中 ，开拓自己的思维层面 ，不受单种方式的拘束，创建多个维度思考方向进行发散。例如 ，可以发挥问题的积极影响、移除消极影响、逆向思维、质疑假设等等 。

以该需求为例，结合可发散的思维方向 ，我们得到了如下的一些可能的解决方案 ：

方案发散示例

罗列出解决方案后下一步要对方案进行收敛，主要考虑方案的有效性和可落地性评估方案：

有效性是指通过了解竞品、数据和可拓展性等维度
，评估方案是否符合用户习惯、是否和产品整体保持了一致性 ，是否符合未来规划方向等 。以方案 4 为例，若我们直接去掉广告势必会影响收入水平，和我们的整体规划是不相符的。

可落地性是通过重要性&困难矩阵、投产比来评估的
，具体的获取途径可以请开发评估或找运营帮忙测算
。例如我们希望对投诉的用户不展示广告，就要请开发评估技术上是否可以实现，对收益的影响程度如何等问题 。

常见的落地性评估标准

③衡量标准

衡量标准也可以理解为该需求所要达到的指标是什么。根据所希望提升的不同用户体验，需求目标可以分为提升用户愉悦度
、参与度
、接受度、留存率和完成度几个方面。

例如 ，其需求目标是提升用户的愉悦度，衡量标准一般为满意度 、NPS 指数或者是推荐功能使用占比等；若目标是提升用户的参与度 ，其衡量指标一般为用户固定周期内的访问次数
、页面浏览时长等。

常见的一些指标如下所示 
：

常见的衡量标准

不同业务不同需求衡量标准之间有所差异，明确标准能够方便后期制定方案策略、上线后评估方案有效性 ，为后期迭代保留相关依据。

④项目节奏

对上述内容有了清晰的认识之后，不要忘记和产品明确项目节奏 ，主要确定以下三个内容 ：

时间节奏：包括上线/策划评审/开发/测试等关键节点

方案时间 ：交互/视觉方案何时输出

对接人：开发/测试/产品/运营等相关对接人是谁

接下来就可以针对工期合理安排自己的时间，正常的工作节奏应该是大部分需求是有合理排期的。当然，有时会有需求并行的情况 ，这时就可以根据优先级四象限判断需求的优先级 ，但一定要和上下游做好沟通后再制定优先级
，避免信息不同步的情况发生 。

3. 结论确认阶段

在分析评估阶段对需求整体评估后，要梳理评估结论准备会前沟通或需求评审会时提出。

①会前沟通

针对需求方案、衡量标准、时间节奏与需求方提前沟通，同时也要沟通未达成一致内容准备在会议上提出 ，和各业务方共同讨论，让需求方也有心理预期。

沟通内容主要包括以下几个方面：

1. 需求是否有必要做  ？没必要因为什么 ？
2. 需求方案是否可行？不可行因为什么 ？可行有什么疑问？
3. 是否有更好的方案？为什么这个方案更好 ？
4. 评估标准够不够清晰？完善？准确 ？
5. 时间安排够不够方案设计？有没有风险？

输出评估结论后，要将结论与各业务方沟通 ，并逐步消除不确定项 。确认结论的时间主要围绕需求评审的会议时间展开 。

②会上评审

要及时主动参与需求评审，在评审过程中勇于发表建议、提出疑问。对于存在争议的内容最好可以在会议上达成共识 ，而非等到会后再私下沟通。如果认为方案存在体验问题
，要针对体验坚守底线
，及时准确地表明自己的态度。最后，要根据需求评估结论再次检查是否明确了全部信息，防止遗漏  。

会上评审主要作用

③会后确认

跟进确认自己关注的信息 ，沟通确认会上遗留问题 、梳理方案设计前的信息是否完备 ，未完备进行沟通获取。

确定以上信息无误后
，就可以准备进入后续项目流程。

最后 ，我们再回顾一下完整的需求评估过程：

需求评估流程回顾

除了上述提到的方法 
，设计师在实际沟通需求时，可以帮助我们解决问题的手段还有很多。使用何种方法只是表象，更重要的是要培养自己透过现象看本质的能力，形成自己的工作方法 。

作为设计师，学会需求分析
，辨别需求真伪是很关键的，这在需求沟通 、需求分析中会形成较大差异。当然这并非是一朝一夕可以提升的
，需要通过不断增强对用户行为及体验的理解 、对商业的理解 ，在实践中锻炼自己，不断积累经验才可以提升。

感谢你的阅读
，希望对你的设计工作有所帮助～

作者 ：VMIC UED