作者:向晴 研发效能（DevOps）工程师（中级）认证学员

引文

作为从事B端产品管理的我们来说，往往面临三大苦难：

• 自己做的产品，自己永远也用不上

往往我们做了很多年的2B软件产品，却难以成为最终用户。但是即便2B，也必须要有用户的思维和最接近用户的方法，否则做的产品也只能是纸上谈兵。所以，靠自己单打独斗是不行的，必须借助外脑。

• 客户和用户分离，到底该听谁的？反正自己说话不管用

我们的客户往往也不是产品的实际用户，那到底谁来定义产品，IT的同事往往也没有话语权。

• 客户要求极高，容错度极低

相比2C用户，2B客户那要求往往更高，每一个细节都会反复确认，更重要的是不！能！出！错！谁也不承担出错的风险。很多时候我们要花费了80%的时间在20%的细节上反复调试修改。

针对以上的问题，本文将从如何开展用户研究及需求调研等相关工作展开阐述，重点帮助大家正确地识别业务痛点，并定义简单需求背后的核心问题。希望通过本文的介绍，我们能够从以下几方面给大家带来一定的启发。

（1）了解需求获取渠道及需求池的概念

• 获取渠道

内部渠道：用户、竞品、不可抗力因素、第三方

外部渠道：产品、领导、同事、自己

• 需求池

需求管理和项目管理的依据

（2）学会需求洞察的几种常见方法

• 竞品分析
• 用户访谈
• 调查问卷

（3）能够选择恰当的形式传达洞察结果

• 干系人地图
• 同理心地图
• 用户画像

第一部分 获取用户需求

1、需求来源

需求来源众多，需求池容量并不是固定的，多源且海量需求驱动数据的汇集，会不断扩大需求池的体积，还需基于这些需求进行产品规划、需求拆解、需求优先级分析等工作，为产品的迭代发展提供基础。产品迭代完成后用户继续使用，可以形成新的用户行为数据和反馈，促使产品更贴合用户需求。

我们将竞品分析、领导要求、产品团队对用户需求的分析挖掘、产品自身数据、政策文件、业务发展、组织机构变动等输入源定义为产品提供侧的需求，而将括用户使用后产生的用户行为数据、用户的反馈等定义为产品使用侧的需求。根据我们实际情况举例，比如我们公司内部的移动门户竞品分析需对比飞书，其中的任务、日程等应用可能均有优化的地方，政策要求进行国产化改造，数据库、中间件等需使用国产工具等等。

2、需求获取方式

需求获取的方式我们根据用户需求来源的不同划分为内部需求获取方式和外部需求获取方式。

（1）内部需求获取方式

• 产品

通常情况下，有两种东西会直观地反映出一个人的心理，一个是他所说的话，另一个是他所作的事。用户调研和用户反馈，就是去听用户“说话”。

数据分析，则是去看用户“做事”，就是用户在使用产品过程中所产生的行为，用户的这些行为会以数据的形式被记录下来，可以帮助我们更好的理解用户需求。

• 领导

领导往往是站在更高的战略层面提出需求的，多数情况下都要特殊考虑。通过深入沟通的方式获取领导的需求。

• 同事

运营、市场、客服是距离用户最近的人，往往最能理解用户抱怨的点，也最有可能对产品提出建设性意见。可以与这些同事交流，通过头脑风暴及各种方式挖掘问题。

• 自己

产品经理应该是产品的目标用户，我们使用产品的次数越多，就越有可能在使用过程中发现问题。注意要避免成为产品的重度用户，以免影响自己对于普遍用户行为的判断。在现实生活中发现需求，时刻保持好奇心，注意观察平常生活中遇到的一些问题，想想这个问题能否用产品来解决

（2）外部需求获取方式

• 用户

从用户处获取需求，主要通过线上的意见反馈、论坛、APP Store评论、线下用户访谈、问卷、日常观察等方式。这些方法概括起来为两大类：用户调研、用户反馈。需求研究法则：10/100/1000法则。每个月必须做10个用户调查、关注100个用户论坛、收集反馈1000个用户体验。

• 竞品

竞品分析，寻找出有代表性的竞争产品，从多个维度对比该产品与我们产品之间的相同与不同，从中分析出两者的优劣之初，得出结论，为产品设计与迭代提供突破口或者带来启发。竞品分析应该是持续的，也就是说，应该持续关注竞品动态，并作出调整。

• 不可抗力

政策调整：关注行业相关的政策调整，并思考其对需求和产品的影响

动态资讯：关注行业资讯，思考行业动向对需求和产品的影响

行业数据：利用行业数据报告、行业数据统计工具获取需求

• 第三方

合作伙伴及集成系统的变更引起的需求变化，这种需求获取方式与从用户处获取需求的方式一致，有调研和反馈两种

3.需求分类

需求获取后，我们按照产品属性、产品职能两类标准进行划分，产品属性包含Idea、新增、优化、BugFix等，产品职能包含功能类需求、运营类需求、数据类需求、设计类需求。

4、需求池管理

完成需求调研后，怎么进行需求管理及后续的落地是我们需要思考的问题，需求全生命周期可以定义为

    为了更好地承载我们获取的用户需求，我们可以设置一个需求池进行需求承接，需求池可以给我们带来如下价值：

• 需求容器

不同来源的各种需求都可以进入需求池（简单评审），进入后的需求进行再次的评审，最终决定这个需求的去留。需求池可以完整统一的记录多处信息源，避免因信息分散而导致需求遗漏。

• 缓冲地带

短时间内收集到较多的需求，而承接人无法第一时间评估需求的合理性，这时候可以先将需求放进需求池内，后期进行了解调研，再严格的评估需求的合理性。

• 需求追溯

记录需求信息源头，并进行追溯，避免传递需求时导致需求变形。

• 版本规划

经过再次评审后留下来的需求，可作为下个版本发布的内容或下几个版本迭代的内容，目的是确保在做版本规划时有足够的素材来源，而不仅仅的靠自己盲目的规划。

第二部分 精准洞察真实需求

通过前期的需求调研，我们初步识别了用户需求并使用需求池进行了管理，那怎么识别哪些需求才是用户的真实需求呢，可以使用哪些方法呢？首先，没有哪个需求洞察方法能适应全部场景，我们可以根据特定业务场景选取合适的方法。本文将摘取一些常用的方法来进行讲解。

1.竞品分析

可以在产品开发周期的任何时间做竞品分析，不过，在开发周期中还是有一些时间点更适合进行竞品分析：在生产需要时、在进行重新设计之前、当竞争对手作出重大改变。

• 直接竞争对手

有产品，与你的产品相似的服务或功能，专注于同一群观众，本质上你们在试图解决同一个问题

• 间接竞争对手

要么有类似的产品但是关注与你不同的受众；要么有不同的产品，但是受众与你相同

• 竞品分析的步骤：

a、列出竞品分析的目标，确保你的目标明确

b、创建一个包含竞争对手列表的电子表格，应该包含5-10个在名单中

c、找出想要比较的特征特性，要与你的目标一致

d、研究每个公司

e、分析你的发现，发展趋势和主体，与自己的相似之处

f、报告中总结你的发现

竞品分析后一般会输出竞品分析报告，但要记住报告是对竞争对手优缺点的概述，而不是记分牌。

2.用户访谈

访谈是一种用于收集深度信息的洞察方法，关于人们的看法，思想，经历和感受，面对面进行，问一些开放问题，访谈步骤一般包含：

• 挑选受众

确定挑选标准，注意不要用过多的因素来定义目标受众。

• 找到受众

自行从现有的联系人中挑选、自行从更广泛的人群（其他利益相关者）中挑选。

• 预约排期

预约排期的过程很大程度上取决于需求洞察的过程

• 邀请

说明需求洞察的目的、参与的重要性、地点、时间等信息

• 准备访谈问题

在正式进行访谈前最好列示需要访问的问题清单，访谈问题的设计可参考下图：

• 进行访谈记录

访谈时尽量面对面开展，且在访谈过程中做好访谈记录，方便时候进行访谈问题分析。

3.调查问卷

调查问卷是用来收集用户资料和验证产品需求的一种常用调研工具。本人将从调研问卷结构和调查流程来详细阐述。

（1）调研问卷的结构

• 标题：问卷的题目
• 卷首语：调查的目的、意义及主要内容
• 问题和答案：问题及指导说明
• 编码：问题和答案的编号
• 结束语：感谢或意见征求

（2）调研问卷的流程

• 前期准备

明确调研目标、明确目标用户、了解行业情况、总结前期调研报告

• 设计问卷

问题的种类可包含背景类、客观类、主观类、检验类等，问题的结构包含难易、类型、时间，问题的表述方式可以有具体、单一、通俗、准确、客观。设计完问卷后需要进行评审。

• 问卷收发

需设置好问卷收发时间和用户答题时长，可通过多种渠道比如APP推送、广告位、用户邮箱等进行发放，问卷的发放对象必须是目标用户。

• 分析报告

回收用户问卷后需要进行数据清洗，包含筛选掉错误、非目标等数据，然后进行基础数据分析，比如一些简单的数据统计，也可以进行深度分析，比如进行一些交叉分析和定性分析等。

第三部分 有效传达洞察结果

选取恰当的形式，包含用户画像、描绘场景、业务流程、描述系统等方式，将结果转化为成果，进行洞察结果的有效传达，这是保障价值交付的第一步。我们需要考虑需求相关者的接受方式，不需要把表现形式的不同类型分隔开，可以将最有用的图表和模型类型放在一起进行呈现，以达到传达洞察结果的目的。

   我们比较常用的传达方式包含：

1.用户画像

• 用户组

一组有相似兴趣目标或关注的人

• 人物角色

虚构的用户，代表了特定用户组的需求，可以帮助识别用户的行为模式，并指向用户组所经历的共同痛点。

• 用户画像

一种勾画目标用户、联系用户诉求与设计方向的有效工具。

2.用户故事

从人物角色的角度讲述的一个句子故事，启发和影响设计决策：

• 公式：作为一种用户，我要行动起来，这样才能获得收益（以用户为中心）
• Who：用户类型描述了我们的设计对象
• What：行动是用户希望发生的
• Why ：好处是用户希望动作发生的原因

 3.用户旅程

用户与你的产品互动时一系列的体验，建立在你已经创建的角色和故事之上，帮助你像用户一样思考和感受。如果人物角色是书里的角色，用户故事是书里的情节，用户旅程就是故事大纲。

以上图为例，通过绘制用户旅程，可以帮助产品经理，为用户创建无障碍设计；减少设计师偏见的影响，确认是为用户设计而不是个人；突出了新的痛点，识别改进机会。

4.报告、演示（原型等）

一份好的需求洞察报告不仅包括一个产品问题列表，还应该能够使开发团队对产品进行改良，避免今后再出现类似的问题。呈现形式通常包含：

• 非正式报告

通常情况下，不一定以正式报告的形式来提交成果。简单的需求洞察，如游击式的使用性测试，结果可以使一份邮件或站立式报告。

• 准备与演示正式报告

使用性报告、纪实性报告、设计出发点报告

• 演示

不仅限于阅读报告，结果展示方式和报告总结一样重要，需求洞察的复杂性往往很难通过描述来理解，对功能细节的解释，演示比文字更容易。演示的形式通常也包含绘制手写版原型图样等。

• 工作坊

需求洞察的工作坊不同于其他类型的设计思维工作坊，有时也称之为解释性会议，主要目标是使用户研究成为未来行动规划的共同参考点。

以上各种形式均是为了更好地将需求调研的结果进行下游环节的传达，传达要根据传达对象的不同制定不同的演示形式，终极目标是保障下游交付流程能够更顺畅，工作更高效。

参考文献

【参考文献】 《洞察用户体验：方法与实践 （第2版）》作者（美）Elizabeth Goodman，Mike Kuniavsky，Andrea Moed。