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

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

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

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

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

一 、为什么做需求评估

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

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

设计师为什么做需求评估

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