在设计师工作的做好总结过程中 ，所承接的需求需求大多来源于产品 。产品作为需求的评估主要提出者 ，自然承担了大部分的厂高需求分析工作。但这不仅仅是设计师何手产品的事儿 ，设计师对于需求分析也有很大的做好总结必要性 。
那么产品和设计做需求分析有什么区别呢 ？需求
结合产品五要素来看，产品更多思考战略层和范围层的评估内容 ，更偏向于从商业维度制定产品目标 ，厂高以及考虑手里有哪些资源可以满足用户诉求。设计师何手
设计师主要在结构层 、做好总结框架层和表现层发挥价值 。需求要在充分理解产品目标的评估基础上 ，从用户角度出发，厂高深入了解用户的需求和期望 ，辨别需求是否解决了用户本质诉求 。同时 ，设计师也要结合产品目标，权衡商业和用户体验 ，采用合适的形式把需求表达出来 。
设计师&产品经理需求评估的差异
一 、为什么做需求评估
理想的需求来源，是将产品的目标 、用户群体 、业务流程 、涉及的关联模块都捋明白之后 ，再进入设计流程 。但在实际工作过程中，往往受限于版本排期 、需求来源多样等因素 ，加之不同岗位业务视角的局限性 ，需求本身并不一定思考得非常全面 ，这个时候就体现出了需求评估的必要性 。
同时，设计师做好需求评估也有以下三方面的益处 ：
设计师为什么做需求评估
1. 增强业务理解
在互联网公司 ，一般会设置产品 、设计 、开发 、测试 、运营等不同岗位，虽然大家工作的内容千差万别 ，但是都是为了打磨好同一个产品，有着共同目标。设计师站在用户体验的角度 ，从不同岗位的视角充分审视需求 ，也可以将问题提前暴露出来，保证方向的正确性 。
对于设计师本人而言 ，当需求没有理解透彻时 ，会让我们的思考方式非常受限 。进行需求评估 ，在自己有疑问时不断追问"为什么" ，直到找到问题最本质的原因，有利于不断加深对业务的理解 ，从而发挥出更大的价值 。
2. 提高做事效率&效果
如果在接到需求后 ，感觉有了一些想法 ，就马上开始进入设计流程 ，从而遗漏了对需求 、场景及用户等的深入了解和分析过程 ，可能导致在方案推进过程中不断暴露出各种问题，甚至出现方向性错误导致整体被推翻重来 ，影响项目进程。
同时 ，如果只是简单转译产品的需求单 ，缺少站在用户角度思考的独到见解，产出的设计一定是平平无奇缺少亮点的。在满足产品功能的前提下 ，思考用户在当前场景还会有什么痛点、是不是可以给用户带来额外的惊喜 ，才能产出更加优秀和具有灵魂的设计 。
在接到需求时先对需求充分评估，而不是一味地"埋头苦干" ，才可以达到又快又好的结果 。
3. 增强影响力
如果我们只是做被交代的工作 、做产品的"工具人" ，是很难在项目中获得影响力和话语权的 ，需求评估就是我们展现能力的"关键环节" 。
作为设计师 ，要增强主动性并培养责任心 ，运用自己的专业能力，推动产品项目更快更好地发展 ，逐渐具备发现问题和机会的洞察力与敏感度 。需求评估的过程也是不断提升在团队中的领导力和影响力的过程 ，有利于树立专业靠谱的设计师形象 ，形成工作中的良性循环。
总而言之 ，做事的宽度决定了你的优秀程度 ，责任越大能力项的成长就越快 ，从线框仔/美工成长为优秀的体验设计师 ，需求评估是我们需要不断提升的重要能力项 。
二 、如何做需求评估
需求评估可以细分为三个阶段：了解识别 、分析评估和结论确认 。在了解识别阶段 ，主要目标是明确需求是不是要做。在分析评估阶段 ，需要对需求进行深入分析 ，以便对需求实施方案有清晰的认识，对如何做心中有数 。最后 ，在结论确认阶段 ，需要对有疑问的问题与各业务方进行确认并达成共识 ，以确保在进入设计阶段之前对需求的基本内容没有疑虑 。
需求评估的流程阶段
1. 了解识别阶段
进行需求评估的前提是要清楚自己在何时应该介入评估 ，只有清楚自己岗位的项目流程 ，才能做事及时准确 。
在进入设计流程前 ，会经历一系列的需求调整阶段 ，通常会在"需求形成-需求发出-需求评审"这三个阶段进行需求评估。在这三个阶段中 ，如果有任何疑问或不同意见 ，都应该及时主动提出 ，尽量避免将问题遗留到策划评审之后才提出 ，将风险转嫁到设计环节 。
项目流程中的需求评估阶段
产品来找设计师沟通需求时 ，往往会带上自己输出的原型图或者视觉风格建议 。这时要避免过早陷入到对于细节的纠结当中 ，从而忽略对需求本质的判断 。
在了解识别阶段要做好信息输入 ，设计师要对需求进行不断的提问，了解为什么要做这个需求 ，目标用户是谁 ，要达成什么产品目标 ，需求的衡量标准是什么等等 。这个阶段的主要目标是对需求有宏观认识 ，帮助我们后续理清设计思路 。
2. 分析评估阶段
在了解识别阶段只是大致辨别需求真伪 ，初步评估需求合理后要更深入地审视需求，做进一步的需求评估 ，主要从需求必要性 、需求可行性 、衡量标准和项目节奏几个方面展开。
需求评估的五个维度
①需求必要性
评估需求必要性的目的是明确需求做不做的问题 。在工作过程中，由于产品经理和设计的职能不同 ，因此立场有差别是很正常的 。我们不能一味地接受需求 ，但也不能盲目地拒绝需求。要立足于用户体验并充分理解产品目标再进行需求必要性的评估 。
需求一般可以分为常规需求和战略/政策需求 ，不同需求评估维度也有所差异 ，比如政策/战略需求可以不用花太多时间精力考虑其必要性 ，直接分析可行性等内容 。
常见需求类别
常规需求又可以进一步细分为优化迭代需求和新产品/改版需求 。迭代需求一般是和现有功能做比较 ，明确为什么要做这个需求 ，和现有功能相比解决了用户什么问题 ，有什么数据/用研等结论做支撑等等。和迭代需求相比 ，新产品/改版需求要进一步挖掘产品定位是什么 ，用户是谁有什么特征 ，对标的竞品是什么等问题。
②需求可行性
需求可行性主要是指对需求本身进行深入挖掘 ，思考依据产品目标可以有哪些解决方案，每个方案的可行性怎么样 。这里并不要求输出最终全部的方案内容 ，仅评估方向正确即可。
需求可行性评估流程
以下面这样一个需求为例 ：
搜索联想 CPD 增加负反馈能力
设计需求单详情
为帮助大家更好地解读需求 ，首先解释几个概念 。
搜索联想 ：在候选词下方实时展示其他联想词的功能 ，点击联想词就可以直接跳转到对应的搜索结果内容 ，以帮助用户缩短搜索路径 ，快速获取信息 。
CPD ：在产品中引入的一些广告内容 ，通过用户下载量来获取收益 。
负反馈 ：用户表达对产品或功能的不满意程度 ，并提供改进建议的能力 。
因此，这个需求是说 ，在用户使用浏览器搜索内容时，浏览器在搜索联想词中引入了一些应用广告内容。如果用户对这些 CPD 应用不感兴趣或不符合需求 ，可以通过负反馈机制告诉浏览器的搜索引擎 ，搜索引擎会根据用户的反馈进行调整和优化 ，提高推荐 CPD 应用的准确性 ，从而提升用户体验 。
在需求单中 ，产品已经给了详尽的解决方案，似乎只需要将它转化为原型图即可。但是否真是如此呢 ？此时不要忘记多问几个"为什么" 。这里我们也可以运用抽象阶梯的思维方式不断向上抽象层级 。
抽象阶梯是一种巧妙构建问题的工具 ，它可以帮助我们更清楚地解决问题 。以我们提出的最初始的问题为起点，在阶梯中上上下下地去移动 。向上移动以扩大范围 ，逐步寻找问题的本质原因；向下移动不断探究细节 ，发散问题 。
抽象阶梯思维原型
例如 ：
- 为什么"要做负反馈"
- "用户反馈投诉多"
- 为什么"反馈投诉多"
- "相关性差 ，又占据可视空间 ，影响浏览操作"
抽象阶梯应用示例
通过抽象阶梯不断向上，我们推导出问题的本质是搜索联想 CPD 的存在干扰了用户对联想词的浏览筛选 。
那基于这个问题我们是否还可有其他的方案呢 ？我们可以使用 HMW 的思考方法快速发散出策略方案。
HMW ，全称"How Might We"，即"我们可以怎样" ，其中 ：
How ：表示假设问题是可以解决的 ，只是还没找到解决的方法
Might：表示不要用具体的实现细节来限制发散方向 ，暗示可能性的重要性 。在思考时只给出大致的思路方向即可 ，注重发散的广度。
We ：强调团队的重要性 ，一个人的思维是局限且单调的 ，要让更多的人都参与到发散当中来 ，才有机会产生更有创造力的想法并发挥团队的作用解决问题 。
运用这个方法可以改变我们固有的思维逻辑方式，防止自己圈定在一个圈层或者方向中 ，开拓自己的思维层面 ，不受单种方式的拘束 ，创建多个维度思考方向进行发散 。例如 ，可以发挥问题的积极影响 、移除消极影响 、逆向思维、质疑假设等等 。
以该需求为例 ，结合可发散的思维方向 ，我们得到了如下的一些可能的解决方案：
方案发散示例
罗列出解决方案后下一步要对方案进行收敛 ，主要考虑方案的有效性和可落地性评估方案 ：
有效性是指通过了解竞品 、数据和可拓展性等维度 ，评估方案是否符合用户习惯 、是否和产品整体保持了一致性 ，是否符合未来规划方向等。以方案 4 为例 ，若我们直接去掉广告势必会影响收入水平 ，和我们的整体规划是不相符的 。
可落地性是通过重要性&困难矩阵 、投产比来评估的 ，具体的获取途径可以请开发评估或找运营帮忙测算。例如我们希望对投诉的用户不展示广告 ，就要请开发评估技术上是否可以实现，对收益的影响程度如何等问题。
常见的落地性评估标准
③衡量标准
衡量标准也可以理解为该需求所要达到的指标是什么。根据所希望提升的不同用户体验 ，需求目标可以分为提升用户愉悦度 、参与度 、接受度 、留存率和完成度几个方面 。
例如 ，其需求目标是提升用户的愉悦度 ，衡量标准一般为满意度、NPS 指数或者是推荐功能使用占比等；若目标是提升用户的参与度，其衡量指标一般为用户固定周期内的访问次数、页面浏览时长等 。
常见的一些指标如下所示 ：
常见的衡量标准
不同业务不同需求衡量标准之间有所差异 ，明确标准能够方便后期制定方案策略 、上线后评估方案有效性 ，为后期迭代保留相关依据 。
④项目节奏
对上述内容有了清晰的认识之后 ，不要忘记和产品明确项目节奏 ，主要确定以下三个内容 ：
时间节奏 ：包括上线/策划评审/开发/测试等关键节点
方案时间 ：交互/视觉方案何时输出
对接人 ：开发/测试/产品/运营等相关对接人是谁
接下来就可以针对工期合理安排自己的时间 ，正常的工作节奏应该是大部分需求是有合理排期的 。当然 ，有时会有需求并行的情况 ，这时就可以根据优先级四象限判断需求的优先级 ，但一定要和上下游做好沟通后再制定优先级，避免信息不同步的情况发生 。
3. 结论确认阶段
在分析评估阶段对需求整体评估后，要梳理评估结论准备会前沟通或需求评审会时提出 。
①会前沟通
针对需求方案、衡量标准、时间节奏与需求方提前沟通，同时也要沟通未达成一致内容准备在会议上提出 ，和各业务方共同讨论，让需求方也有心理预期 。
沟通内容主要包括以下几个方面 ：
- 需求是否有必要做 ？没必要因为什么 ？
- 需求方案是否可行 ？不可行因为什么 ？可行有什么疑问 ？
- 是否有更好的方案 ？为什么这个方案更好 ？
- 评估标准够不够清晰 ？完善 ？准确 ？
- 时间安排够不够方案设计 ？有没有风险 ？
输出评估结论后 ，要将结论与各业务方沟通 ，并逐步消除不确定项。确认结论的时间主要围绕需求评审的会议时间展开 。
②会上评审
要及时主动参与需求评审 ，在评审过程中勇于发表建议 、提出疑问。对于存在争议的内容最好可以在会议上达成共识 ，而非等到会后再私下沟通。如果认为方案存在体验问题 ，要针对体验坚守底线 ，及时准确地表明自己的态度 。最后 ，要根据需求评估结论再次检查是否明确了全部信息 ，防止遗漏 。
会上评审主要作用
③会后确认
跟进确认自己关注的信息 ，沟通确认会上遗留问题 、梳理方案设计前的信息是否完备 ，未完备进行沟通获取。
确定以上信息无误后 ，就可以准备进入后续项目流程 。
最后 ，我们再回顾一下完整的需求评估过程 ：
需求评估流程回顾
除了上述提到的方法 ，设计师在实际沟通需求时 ，可以帮助我们解决问题的手段还有很多 。使用何种方法只是表象 ，更重要的是要培养自己透过现象看本质的能力 ，形成自己的工作方法。
作为设计师 ，学会需求分析 ，辨别需求真伪是很关键的 ，这在需求沟通 、需求分析中会形成较大差异 。当然这并非是一朝一夕可以提升的 ，需要通过不断增强对用户行为及体验的理解 、对商业的理解 ，在实践中锻炼自己 ，不断积累经验才可以提升 。
感谢你的阅读 ，希望对你的设计工作有所帮助～
作者 ：VMIC UED
版权声明：行行出状元网 ，转载请注明出处：https://www.v8q.cn/html/41b86599093.html
