应当避免一个产品变成产品经理自己的设计、或者某个领导拍脑袋的想法。作为产品团队的一员，交互设计师有责任和义务进行需求调研，拿到第一手需求资料，而不是接受莫名而来的需求列表。

这个比喻有点形象，当需求经过多人之手，传递到设计手里经常都变了味道，貌似所有接触过需求列表的人都喜欢改两笔，尤其是初成长的产品团队。

很多设计师都是坐办公室里完成界面设计的。阅读本文后，倒是希望大家能去看看你们的产品市场，用户的使用场景，用户的需要，用户使用产品的想法，以及用户的期望。

收拾下，申请外勤出差吧~不去看看真正的市场，你可能发现不到，团队内有时候纠结的那些问题，对用户实在太微不足道了。

在之前的文章《可用性测试：让交互设计变被动为主动的利器》讲过，设计师的的强大后盾是用户，考虑他们的立场、思维和体验，你的设计一定不会差。

设计师，你理解需求了吗

我遇到的一个例子：

产品团队纠结“用户列表”功能界面是不是该新增一个按钮叫做“用户分组”。

为什么需要分组呢？

因为作为一个人员管理的工具，产品经理认为对于有相同属性的人员是应该归类为一个组，这样，调阅一组名单可通过组名来选取。

很多同事也会认为，这个新需求就是在界面上加一个新增分组按钮。如果用户勾选了列表里的一批用户名单，点击新增分组，输入分组名称，分组就完成了。

好像这就是日常~

直到有一天，跑过现场的同事收集到了情报：

分组功能很多用户不知道，也没用过。他们只是按名字和电话搜索用户而已。

会议上：

• “我们是不是要培训，要教育用户？”
• “是不是设计的不好用啊？”
• “加个引导吧”

好了好了，别跑远了。可能起初的需求就有点拍脑袋的意思，这个需求用户并不觉得重要。

为避免上述情况，设计师最好领一下任务，任务做完，你就升级了~拒绝不合理需求，做有意义的设计。

产品需求到设计需求的转化

产品需求大多是纸面的文字，excel表，word文档，里面列出了产品需要的功能。我很好奇有多少人对产品需求提出过质疑，貌似每一个都超级重要。

这里我的经验是，产品需求与设计需求是相关联的，相辅相成，但并不等同。产品需求给了产品想要的功能模块定义，优先级大多与研发周期挂钩，优先级越高，说明越要最优先实现。

设计需求由主导产品的交互设计师确定，作为设计师的你需要进行需求转化，依据重要性，使用频次，层级关系等把产品需求转化为可视化界面。这些可能不是产品经理直接能给你的，你也很难自己一个人搞定，准确无误。

不要看到需求就一上来画线框稿，先来需求转化。

举个例子：

产品需求是：用户列表、业务1、业务2、结果分析四大模块；每个里面还有细节的功能点，这说明产品经理构想出了产品大致的轮廓架构。

交互设计师需要理解相关概念，其次，问问为什么？

产品经理可能会说“这是第一版，后续还要考虑XX功能，,当前XX功能不考虑，如果某个地方用的好，我们可能考虑…”

我相信你问了，产品回答可能会有点模糊，尤其是少竞品、从无到有、又要体现功能特色的产品。正式上线前，新生产品的功能块、使用频次、重要性、优先级等等产品经理自己可能也是模糊的，尤其是新手产品对产品的预期更不明确。

指望产品经理回答所有问题，他的压力很大的。设计师们，我们的存在是解决问题的。

对于不明确的需求，我们可以找用户。

别怕费时间，因为真的很有意义。

洞察需求方法一：通过“重要性-满意度”调查得出设计重点

这个阶段，设计师可以让产品经理安排几个用户，进行简单的测试。前期调研，哪怕人数少，也好过前期不做，后期找一堆人改。

把需求列表里几个主要功能名称，拿去给用户看看。

1.可以做一个功能-重要性-满意度列表，每一项进行打分。

重要度高，满意度低的功能点，应该是设计的重点。

可以设定重要性、满意度打分范围均是0-10分，综合分数表明机会所在，产品的机会就是用户痛点，也就是对用户很重要，但是用户非常不满意的功能项。比如，业务2，重要性得分：9，满意度3，那么综合得分：9+max（9-3,0）=15。之所以有max存在，是因为重要性比满意度权重更高。如：

• 重要性10，满意度0；（用户觉得非常重要，但是非常不满意）
• 重要性0，满意度10；（用户觉得不重要，但是非常满意）

以上两个，你觉得哪个是你的设计重点？

这里避免一个误区，是直接相加。因为重要性的权重更高，重要的功能是设计的重点。对不重要的功能做过多的设计其实是没抓住核心。

重要性-满意度打分是常见的用户调研的方法之一。具体分值指标，可以在调查表中设计并调整。

• 不重要，很满意：属于过度满足，考虑减法或隐藏，别喧宾夺主（衍生或非核心功能的情况）；
• 很重要，不满意：属于用户痛点，集中在痛点区域的一系列需求，都是设计要点。

大的功能模块刚刚得出重要性优先级别排列，接下来，我们需要对每一项需求进行进一步拆分。如果这个事情是产品经理做了，那么设计师需要好好理解大功能下的小功能模块是如何切入进去的。

洞察需求方法二：核心功能的细分，绘制“Job Map”

对核心任务的理解，可以设置几个关键点串联：

Plan：计划——Execute：执行——Moniter：监控——Conclude：结束确认

来个栗子：德国博士Bosch，一个做电动工具的公司，把电动锯产品的核心功能——锯木头功能，做了Job Map。

采用当面访谈、用户调查、电话访谈、集中研讨等多种方法，依据细分步骤，搜集用户在每一步期望达到的效果（outcome）。每一个outcome，都是一个顾客需求。

收集并明确了需求，才可以定义设计指标，找出让用户提高工作效率的方法，或者设计出更便捷的流程。

总结

现在，明确产品的需求来源（1页PPT）及需求内容（2页PPT），来源大致是5W（调研的时间when、地点where、谁who、调研了什么what、为什么why），再做上面列出的需求洞察方法：重要性-满意度分析痛点、或画出Job Map。你就能够明确需求，排除需求干扰项，推动你的产品设计思路。

搜集和筛选需求不止这两种方法，以上两种方法是我在工作实战中的经验总结，你可以利用这两种方法的步骤，明确你的设计重点。

要明确你的设计重点，排查不合理需求。

可能，一些不合理需求并不是真的很不合理，只是不分析，它的重要性与层次会误导很多人，这个把控就在你了，产品或交互设计师。

当然，只有洞察需求还是不够的，我们还没转化完成。

对于每一个设计内容，都需要一个可衡量的指标，确定之后再考虑出图流程与步骤。

后续我会再发一些经验帖，上述仅是我个人偏好的方法汇总，当然方法不止这些，大家可以选取喜欢的方法进行需求采集与分析。感谢大家的关注。

本文由 @葛达尼尼 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自PEXELS，基于CC0协议