在工作中，我们经常需要和产品经理对接需求，通常来说都是产品经理先出需求文档，设计师根据需求文档进行设计支持。B端产品业务通常比较复杂，如果设计师对业务的了解不够透彻，很容易局限在体验好不好，视觉好不好看，在没了解清楚需求本身的情况下按照产品给的原型去进行设计，这样很容易导致设计出来的结果偏离问题的本质，所以我们要在需求开始阶段时就参与其中，在了解需求根源的时候对其深入。

一、确定产品定位

在实际的工作场景中，设计会和产品经理产生意见冲突，很容易一开始陷入细节的讨论，大家各抒己见，乱成一团，最后都不知道在讨论什么内容；还有一种情况为了1%的用户需求牺牲了99%的用户体验......

造成这些原因的关键在于忽略了产品定位

产品定位是产品设计的方向，也是需求文档和设计产出的判断标准，它包括两部分：产品定义和用户需求。产品定义主要是产品经理从系统的角度考虑，用户需求需要设计师从用户角度考虑

• 产品定义

  
  

产品定义就是用一句话来描述这个产品，如果一句话描述不清楚，很有可能产品定义不够清晰，例如：我目前做的项目是帮助学校老师快速出卷进行考试的系统。得出来简单的产品定义：

使用人群：老师

主要功能：考试

产品特色：快速出卷

这样产品定义为产品限定了大致的范围，整个团队思想更统一

• 用户需求

这里我们可以使用5W1H法，也叫六何分析法进行思考

原因（ Why）：

需求的背景是什么，产品在当前遇到了什么问题，比如数据差、体验反馈差等。

想要达到什么目标，是商业需求还是用户需求？

产品所在行业的竞品情况如何，市场趋势如何？

对象（ What）：

需求的内容是什么，基于需求的背景、目标，产品即将做什么事情？注意不能局限于做某个具体形态的事情，可以尝试描述这件事情如何满足需求。

场景（ Where）：

什么场景出现这个需求？

需求的最终产物会在什么场景/页面/模块出现？

时间（When）：

什么时间节点出现这个需求？

需求的最终产物会在什么时间节点出现？

用户（Who）：

产品的用户是谁？这个“谁”不是只某个个体，而是产品的某类典型群体。

用户需求是什么？用户遇到了什问题？可以将用户需求枚举出来，但是需要注意用户需求不一定等于产品需求。

方法（How）：

需求所要做的这件事情，实现方式是怎么样的？

有没有其他可能的方式可以更好的实现这件事情？

我们需要了解目标用户、使用场景、用户目标。了解这些场景以后，帮助用户解决问题，并在这个过程中让用户感到愉悦。

二、收集需求

在明确了产品的方向以后，就可以根据产品的定位采集匹配的需求了，在实际项目中采集需求的方式主要是用户调研、用户反馈、竞品分析、产品数据四种方式

• 用户调研

虽然在大公司会有专业的用研岗位，但是不同角色的关注点不完全一样，设计师比较关注的用户体验，交互逻辑，界面细节这些问题在用研人员那里容易被忽视，作为设计师需要第一时间接触到真实用户，直接了解用户的诉求，通过用户调研挖掘需求的方式主要有三种：问卷调研、用户访谈、信息采集

• 用户反馈

在产品测试阶段或者正式发布后，收集一波用户反馈，C端产品可以通过APP store、应用商店、微博、贴吧等一些公开渠道借助第三方检测平台平台七麦、酷传收集用户评论。B端产品公开渠道很难找到，可以通过公司的销售运营人员那里得到反馈。通过用户反馈往往能发现很多意想不到的问题，比如用户找不到想要的内容，看不懂文案，找不到点击按钮等～

• 竞品分析

找具有代表性的同类产品，对比优劣势，取长补短，特别要关注产品的功能与用户体验设计方面

• 产品数据

产品上线后去搜集相关数据，比如常规的访问浏览数据、浏览痕迹、点击痕迹、在每个页面上的浏览时长、整体的浏览顺序等。为了能很好的获取到这些数据，要在设计的时候做好数据埋点。收集到数据后再进行分析挖掘数据背后潜在的意义。

三、整理需求

通过上述方式来采集需求，这时候我们会收集到各种各样的需求，由于用户角色和诉求不同，会掺杂大量个性化的诉求，这时候不能完全被用户牵着鼻子走，先把一些不合理的、目前技术不能实现的、明显意义不大的需求过滤掉；其次要通过现象看本质，挖掘用户的真实需求，并且考虑怎么去解决；接下来，进一步分析提炼出的用户真实需求是否符合产品定位，被选中的需求根据匹配程度排列需求优先级；最后考虑实现成本以及收益。

四、最后总结

最后我们得出了一条设计师如何挖掘需求的流程，先要明确产品的定位，然后通过不同的方式收集大量需求，识别这些需求的有效性，根据产品定位和项目资源的情况进行筛选，提炼出产品需求，定义优先级。由于整个过程不仅涉及对用户的分析和理解，还包括了对产品的定位，项目资源的考虑，所以在每个阶段都应该是产品经理和设计师配合完成。这样就避免了很多在沟通时候 “我觉得......” 好几个小时，结果全是无效沟通，只有完全理解需求设计师在工作中才会有更有主导权，也更容易得到项目组其他成员的认可。

参考文献《破茧成蝶》