一个人也能低成本进行目标用户研究——QTI敏捷调研法

编辑导语：在对用户认知不统一时，团队内部则可能出现混乱，导致后续业务推进的延后。那么，我们应该如何做好用户调研，获得一手的用户反馈数据，明确用户的真实需求呢？本篇文章里，作者总结了一个人也能采用的QTI敏捷调研法，一起来看一下。

笔者从事产品工作一年多，在工作以及和产品朋友聊天中发现，很多需求都会受到各方的质疑，其背后不能简单归类为沟通问题，更多的是没有真实用户数据的支撑。虽然他们都知道用户调研的重要性，但受限于资源和环境原因，他们并没有进行过有效的用户调研。

笔者通过学术项目学习过较为系统的用研理论知识，但在经历过实际的从0到1的项目落地工作中发现，产品经理自己就可以一个人用较低的成本进行快速高效的用户研究活动。

现基于自己的用研经历总结出了一套自己的方法论，希望能给到各位帮助和启发。

本文结构如下：

先从工作场景出发，分析需求质疑背后的核心问题以及主要原因，指出了以此导致的项目问题与影响，并提供了解决思路，再基于个人经验介绍一套可用的可自定义敏捷用研方法，最后提出了需要注意的问题。

一、需求质疑

1. 产品的高血压场景

立项评审会上，到了提问的环节，领导倚靠在椅背上，双手交叉，扫了一眼PPT上的用户画像，漫不经心地朝你问：

• “这个需求我感觉不够痛，如果我是用户，是不可能需要这个需求的。”
• “说了很多次，要站在用户的角度看问题，这个需求别人也知道，你做的就比别人好吗？”
• “你这个需求从哪里来的，经过验证了吗？有多少用户提到过？”

产品狗心中：^ – ^

还不容易你擦着汗熬过了立项，版本需求评审会上，客户端同事和服务端同事对视了一眼，干巴巴对你说：

• “这个功能没啥用啊？”
• “我感觉先弄一个XX功能是不是比这个更好？”
• “这个功能开发难度有些大，我觉得这个版本就别上了，优先级放低些。”

产品狗：^ – ^

……

作为一个产品人，写到这里再回忆一下那时的场景，瞬间低下头看了下手表上的心率，果然变高了。

2. 需求质疑的实质

很多人会把这些问题归咎为沟通层面的问题，例如需求的讲解不够简单而详细，没有让领导和开发听懂；又或者说是因为“魅力”的问题（？），让一个妹子产品经理来说可能就更合适了，当然也会有人说是开发的问题，开发就应该老老实实地接需求做事情就行了……

但一年后，两年后，三年后这种情况还会出现难道也是沟通问题吗？

现象反映本质，我们需要看到这类现象背后的实质问题： 团队内部对目标用户的认知不统一。

无论是领导、开发、设计还是运营同事，他们尽管会有意识避免自己的主观偏见，但或多或少都会基于自己的经验来解读用户，自然导致对需求理解的不一致。

说的不好听点， 他们不信任你的需求结论 ，甚至有些产品人都无法说服自己相信。

很多中小公司项目所谓的经过分析而得出的 需求本身就是畸形的 ，因为需求结论背后的依据大部分是二手货。

什么是二手货？就是各类行业市场产品报告中的用户画像。

大家的检索能力都不差，拿到同样的报告数据，最后大多沦为主观否定主观之纯凭经验解读，那么作为领导、作为同事凭什么相信你的解读呢？

当这些数据只有少部分人拿到的情况下，数据才是可贵有效的，通过解读可以拿到超额剩余价值，但数据每个人都能拿到的话，那数据就变成了全行业都得到的相对剩余价值了。

之后就是看能否拿到更为详细的一手数据，数据越精确越独立，价值才会越高，解读才会让人信服（又卷起来了哈）。

所以，要保证团队对用户需求认知的一致，就需要保证基础的用户数据是真实有效的，你需要对当前项目的目标用户进行有效的调研。

二、用户研究的无

1. 无用研的原因

明白了很多人生道理，但还是过不好这一生。

作为产品人，自然知道用户研究的重要性，可实际上由于各种原因，用户研究最终还是不了了之，或者蜻蜓点水而散去。

主要的原因可分为外部和内部。

1）内部原因：产品人的用户意识不强

产品经理的专业背景一部分是设计专业或心理专业，是有过用户体验相关的课程学习和研究经历的，所以他们的用户调研意识会比较强，但大多数的产品岗都是跨专业背景更多，尤其是工程技术导向的专业，虽然他们转行学习过相关的用户需求板块，也有基础的用户意识，但很难变为行为上的重视。

2）外部原因：公司部门的支持不足

很多的大厂都直接或间接地组建了自己的用户研究团队或用户体验团队，但很多的公司是没有足够的资源去建立用户研究部门或者团队，甚至连用户研究员都没有。

大多数小公司，处于成本的考虑，都可能会让产品经理既要负责交互设计，又要负责产品测试，对于“没有看得见摸得着的产出”的用户研究，公司更不会考虑花钱招人了。

产品团队面对繁多的任务，必定会导致精力的分散，很多人面对用户研究众多的耗时耗力的方法望而却步，就会草草了事，要么电话和几个用户对着问题聊聊天，要么就直接花钱买一份报告，好一点的可能会聘请外包的市场团队进行线下的拉人写问卷。

当然了，还有其他一些众多原因，就不再一一列举了，但 无论是什么原因，都不是不做用户研究的借口。

2. 无用研的影响

需求，尤其是面对 C端市场 的需求，都需要花费一定的成本去接触真实的用户，需求一旦刚开始就弄错，后面很多都是做无用功，无论是时间还是人力，都是极大的损耗。

1）影响其一：导致立项评审反复修改

俗话说，一鼓作气，再而衰，三而竭。需求部分作为立项的重要一环，如果各方沟通无法达到统一极易引起对立情绪，业务方会陷入反复修改的时间浪费中。

2）影响二：开发理解不一致，验收易冲突

在需求评审和技术评估后，项目就进入了开发阶段，虽然开发同事明白功能所要实现的整体效果，但他们如果在前期没有和产品同事保持对功能背后需求的一致的理解，那么很多的细节就会存在问题，因为对于开发来说，“跑通了就问题不大”，若需要修改的东西涉及到底层的架构，那开发分分钟要撕了产品。

3）影响三：运营方案定位存在问题，ROI过高

严格意义上说，运营部门需要在立项的时候就要参与到沟通中，需要了解核心的需求，方便产品开发的时候他们准备方案的制定。

术业有专攻，方案的制定也是耗时耗力，若双方对需求和定位的理解不一致，最后投入的资金和活动必定是竹篮打水一场空，双方又陷入锅谁背的扯皮中。

所以，前期做好用研，保持各方认知一致，能够很大程度上减少后续的沟通成本和资金浪费。

三、敏捷式用研

1. 解决思路

那么，在没有用研资源的支持下，作为产品经理如何用较短的时间、较小的成本完成有效的用户研究活动呢？

首先，强化用户意识。

当对某事物的意识不坚定的时候，只要是个人，他就不会主动去付诸行动，哪怕是尝试了，一旦遇到他人的劝说或过程上存在困难，便会轻易放弃。

当你正在准备问卷的时候，同事拿着咖啡走过来看了眼说：“这个我之前做过的，没有什么用，看看报告就行了。”

当你完成一半的访谈的时候，你发现收集的答复非常凌乱，你心中是不是想过：“收集一半差不多了吧，就把这些数据自己优化处理下，作为自己观点的论据就行了。”

如果没有较强的用户意识，很难坚持下去。

其次，避免学术，敏捷处理。

商业产品，不是学术研究项目，不要带有书生气去看待问题，也不要去追求所谓的完美主义。

功能实现不了，那就降低维度换一种方式来实现。

同样的，用户研究本身就是一个庞大的领域，不可能短时间内掌握（除非转岗沉浸其中），若没有专业人员的支持下， 产品经理只需要系统了解后根据目前项目情况选取合适的方法进行删减以及恰当的组合即可。

麻雀虽小，但也五脏俱全。

最后，mvp快速试错，及时调整。

任何一种方法论不可能在初期就能一次成功，作为产品经理一定要在出第一版方案后，先找同事进行快速排查流程问题，再邀请小体量用户进行预调研，从中发现关键问题进行优化，再调整后才可大范围投入。

方法论并不是一成不变，一个项目结束后，需要针对性进行复盘，在下一个项目中继续发现问题、优化问题，方法论是随着项目经验的不断增多而越发完善的，会成为产品人的一大笔经验财富。

2. 定义敏捷用研

敏捷式开发我们知道，那么什么是敏捷用研呢？

我们先看下传统的用研定义：

用户研究（User Research）是指基于以用户为中心的设计理念，为了确定用户需求痛点、提供设计启发与优化，通过各种不同方法调查研究产品潜在用户和现有用户的而开展的研究活动。

用户研究根据研究的重点，可分为态度和行为研究，根据研究方法的性质，可分为定性和定量的研究。其常见的方法类别有访谈法、观察法、问卷法、测试法等。

具体的内容介绍就不多说了，很多文章和书籍有较为完善的说明，大家可以自行检索归纳。

从上可以看到用户研究方法众多，有的涉及到非常专业的知识，包含了社会学、心理学等等，甚至一些严谨的活动会用到专业级设备，如眼动仪、生理监测等等。

实际上，我们没有必要（实际上没钱没人）做到如此严谨复杂，完全可以根据自己的需要进行方法的改造，主要维持其理念核心（道）不变，方法（术）和工具（器）都可以进行调整，这就是敏捷式用研。

个人将敏捷用户调研定义为：

基于现有项目限制条件下，选取并组合一定比例的结构性方法来对目标用户进行分批次的迭代式研究活动。

核心一：现有项目限制条件。

需要根据当前项目的进度，计划好一定的时间和资源支持，如一人力投入一周、资金预算（奖励、访谈地点等）3000元。

核心二：选取和组合方法。

时间略短的情况下，可将部分定性和定量方法结合在一起进行某一环节的研究，例如个人访谈和可用性测试。

核心三：分批次迭代式。

如果符合条件可配合研究的用户有限，可以进行分组，例如原本十人的焦点小组，可以分为两次五人焦点小组，根据前组情况调整下一组的提问内容。

四、QTI法

QTI法是笔者 根据自己之前用研经历所使用的方法的总结 ，也可以说是敏捷用研下的一个方法模板。

QTI由Questionnaires（问卷）+Test（测试)+I nterview（访谈）三个部分 组成。

1. 核心要素

1）要素Q：分为问卷调查和主观体验量表

问卷在前期可用于筛选用户群，一方面可以大范围收集相关的人口学数据，另一方面通过问题的分析可在一群人中筛出适合调研的用户。

量表主要用于产品测试后的感受量化工作，通过分数来统计用户的整体感受。

2）要素T：分为可用性测试和协作测试

可用性测试，不仅可用于本项目产品的评估，还可以使用在竞品上，帮助发现一些问题，提前避免。

协作测试，如若存在沉默用户（不发声思考）或涉及到多人配合使用的产品，可以组织多位用户进行测试。

3）要素I：分为个人访谈和多人访谈（焦点小组）

顾名思义，访谈对象是个人和多人（狗头），但一定要分配好活跃用户或意见领袖的比例。

说了理念，笔者将自己的项目背景作为例子进行简单使用说明，后续有空再开几篇文章详细说下具体的使用流程和操作。

2. 举例说明

首先大家要明确一点，没有什么方法是一成不变的，QTI法并 不是严格按照顺序 进行执行，该方法根据项目的不同情况可进行自由组合和适当增减。

我的一个项目背景：

根据公司战略，负责一个APP从0到1的落地工作，但因为疫情大环境和支持不足原因没有做过用户调研，只是根据报告和竞品完成了1.0版本的功能开发，测试包出来的时候，我需要组织用户调研，一方面就是来挖掘用户需求以便后续迭代规划，另一方面就是发现APP的使用问题。

方法实例：

1）向上级申请许可并要到了一些奖品。

2）制定了调研主题、流程和时间安排，完成问卷、访谈纲要、测试任务集和量表设计。

3）向相关用户群发送有偿调查动态，从中选取一批合适的用户，将参与者分成了个人和小组两个大类，人数比例基本为1:1。

4）抓3位同事进行预先演练，调整内容描述和流程，再邀请2位用户进行预调研，确保流程无问题。

5）先进行个人调研，流程为问卷调查、APP可用性测试、量表填写、问题回顾以及访谈 （QTQII）。

6）将个人分成三组，第一组结束后快速统计问题，调整完操作问题后进行第二组，此时重点关注第一组提及的问题，第二组结束后统计两组的共同问题，涉及到APP操作问题的迅速反馈给开发，接着进行第三组，针对共同问题可适当侧重。

7）个人调研结束后，将三组的内容进行整理，提取关键的共同问题和差异点，以此调整后续小组调研的内容，尽快安排开发完成问题修复。

8）将小组人数分成两个焦点小组，流程为问卷调查、访谈讨论、APP可用性测试、量表法以及回顾法 （QITQI）。

9）调研结束后，尽快处理数据统计，遇到疑惑的地方可查看录制的视频或音频，必要的时候可以联系相关的用户。对了，别忘了给每个用户的奖品。

以上就是我当时处理用研的流程，基本上是按照实际情况进行调整的，例如个人和小组的APP可用性测试环节顺序是不一样的，主要是考虑到焦点小组耗时更长，访谈放在后期不容易进行问题的广泛讨论，放在前期效果更好。

以此类推，假如 立项结束，有目标领域报告但无直接竞品，打算调研需求，那么如何处理呢？

方法例：

1. 根据市场报告划定目标用户所在的用户群体；
2. 发放筛选问卷，招募10人；
3. 将10人分为三组（4，3，3），协商好访谈时间，准备流程和材料，并进行预演；
4. 对第一组4人发放问卷，根据访谈大纲进行个人访谈，结束后发放奖品；
5. 根据第一组得到的回答情况，适当调整问卷和访谈内容，进行第二组；
6. 根据两组的回答情况，取出共同点针对性调整，进行第三组，第三组注重共同点的回答；
7. 三组结束后，结合录像或音频进行整理，有问题或遗漏的地方询问相关用户。

大家发现了，这里只会用到QI，按照实际情况减去了T的内容。

那么再比如： 产品上线了，但使用流程存在问题，已经迭代了一个大版本，需要验证流程可用性，那如何处理？

方法例：Q（产品使用用户）+I（焦点小组收集反馈）+T（可用性测试）+Q（量表），当然严谨还是需要一批未使用过的用户过一遍流程。

……

3. 三个问题

无论大家最后是采用大而全的方法好，还是采取短快的敏捷式也好，在面对用户提出的需求时，都需要注意三个问题：

1. 你所接触的这个用户真的是目标用户吗？
2. 这个用户所说的就是用户真实的想法吗？
3. 用户反馈的这个需要可以直接拿来用需求吗？

第一个问题，如果做一个游戏项目，结果招来的人并不是那么热爱游戏，那么这个用户说的话就需要打上一个大大的问号了。

第二个问题，在和用户接触的时候，碍于情面或隐私，用户往往会说出自己认为可能合适的回答，这种回答一旦和产品经理的偏好接近，会直接影响到产品经理的后续判断。

第三个问题，用户反馈的内容，即 “我需要一个XX”、“有一个XX功能就更好了” ，这种功能上的回答往往都是基于他们的认知所得出的解决方法，就好比他们想要更快的马。

作为产品经理不能将用户所说的需求当作以用户为中心的圣旨，因为作为商业产品，必定是在商业、需求和技术中取得平衡，产品经理要站在更高的纬度去看待产品，而不局限于一些零碎的说法。

五、结尾

本文从需求质疑现象出发，分析了原因以及解决思路，提供了可供参考的QTI敏捷法，希望大家无论做什么产品，都能够切切实实去主动接触自己的目标用户， 多一些实事求是与变通 ，少一些僵化和偏执。

感谢你看到这里，如果你觉得我的文章对你有用的话，欢迎大家在留言区提问和交流，下次有空的话会写几篇文章说说具体的实施步骤和方法细节。

 

本文由 @苹果核 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自Unsplash，基于 CC0 协议