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