这篇文章写给踌躇在「如何与用研合作」的产品经理和设计师，以及埋在自己研究小天地里的用户研究员们。
论相互了解，产品与设计师间往往水乳交融爱恨交织，每天给设计师买早餐的产品经理可不罕见。但对于用研人员，大家总觉得蒙着一道面纱，不知大堆看着头晕的数据背后的他们究竟在干什么。在合作前，双方往往需跨越一道很大的叫做「用研如何与产品设计合作」的鸿沟。这道鸿沟之下，往往产生了诸多问题。
问题
- 没做用研
- 沦为工具
- 研究滞后
- 各角色对用研缺乏了解
- 用研对产品的渗透不够
- 用研工作本身缺乏规划
由于不清楚哪些问题可以通过用研解决，许多争议被拍脑袋决定了，等发布后收到恶评才追悔莫及，此时再改，付出的代价就大了。
等方案都出来了，才想到找用研来「验证看对不对」、「我想说服老大这么做，帮我找一下依据」。用研对产品的创意参与少，贡献度低，存在感弱。
等产品和设计师提需求过来才想到要做。等辛苦做完用研，大家已经不幸 move 到下一个重点，不关心这些结论了。
缘由
造成这些问题的原因来自多方面。
听到同事对我说得最多的话是「用研都干些啥啊？」「我这有个问题，不知道该不该做用研…」就连合作很久的产品经理和设计师，对用研的职责也大多比较模糊和零散。只知道有问题可以找用研，但什么样的问题适合采用用研解决？不清楚。
研究本身的深度与成效一般，团队对用研结论的推动不足；用研好似蜻蜓点水，做完一件项目便转移到其他产品，缺乏持续追踪，都可能造成用研并没有站在产品的第一线。
用研的规划较为长远和粗略，简单根据产品重点勾画出研究方向，往往跟不上产品版本节奏。但其实规划这件事情，并不是用研自己关着门就能列出来的，它需要紧密配合产品的周期。
用研解决什么
前面提到，许多产品和设计师并不明确什么情况需要进行用户研究。我的理解是，用研擅长解决典型用户在典型场景下的典型问题。大部分问题的关键词（当然也有例外）包含着Who、What、When、Where、Why、How。
先来看一个例子。下图列举了某产品在某版本的不同阶段进行过的用研项目。大家猜猜是什么产品?
