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

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

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

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

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

一
、为什么做需求评估

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

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

设计师为什么做需求评估

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