产品QTI用研模型：用一个方法完成问卷、访谈和测试，提高交互设计体验！

编辑导读：本篇文章先是简述了产品交互设计中用研的重要性，给出了可用的敏捷式用研模型——QTI法，然后拿出APP从0到1的工作项目来举例分析了该模型的运用流程，并在每一个环节笔者都做了非常详细的操作说明和建议。

该方法论适合人群：

1. 在校学生。帮助他们完成课程项目、学术论文中的用户调研部分，提供清晰的可用思路。
2. 中小型公司的产品经理或设计师。在无用研团队提供支持的情况下，可根据QTI模型制定适合所在企业、团队和项目的适用方法。
3. 其他感兴趣人员。有希望转行的或对产品设计有兴趣的同学，觉得传统用研理论太多且过于学术化，可以参看本篇文章，了解实际的使用场景后再有目的性地去补充学习。

一、产品用研的现状

1. 需求质疑实质

无论是在学校的互联网产品类、设计类大赛评审，还是互联网公司内部评审，永远绕不过去的争论主题是：

这个需求存在吗？这个设计有用吗？

这些问题的背后实质是： 产品和UX团队内部对目标用户的认知不统一。

人都是基于自己的经验来解读用户，自然导致对需求理解的不一致，更何况很多产品经理整理出来的 需求本身就是畸形的 ，依据都是行业数据和报告参考，这种数据不是精确独立、让人信服的，因为大家都是拿到相同的数据，最后又沦为主观否定主观之争。

2. 无用研的原因

大家当然知道用户研究的重要性，但还是受到很多原因无法去做：

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

虽然很多非设计类产品经理转行学习过相关的用户需求知识，也有基础的用户意识，但很难变为行为上的重视。

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

耗时耗力耗钱是根本，中小型公司很难会花费大量成本在用户研究这种“玄学”环节上，因为成果是“看不见摸不着”，但成本确是实实在在的。

3. 无用研带来的问题

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

俗话说，一鼓作气，再而衰，三而竭，业务方会陷入反复修改的时间浪费中。

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

产品经理、设计师和开发人员对产品以及目标用户群体理念不统一，产品容易收到挑战和质疑。

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

二、QTI敏捷用户调研法

什么是敏捷用研？笔者斗胆定义：

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

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

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

1. 核心要素

1. 要素Q：分为问卷调查和主观体验量表
2. 要素T：分为可用性测试和协作测试
3. 要素I：分为个人访谈和多人访谈（焦点小组）

2. 参考流程

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

（1）准备 ：制定了调研主题、流程和时间安排，完成问卷、访谈、测试的设计。

（2）挑选 ：向相关用户群发送调查意向动态，从中选取合适的用户

（3）预演 ：找非用户人员进行预先演练，调整内容描述和流程

（4）实操 ：确定用户排期，将用户分成多个小组，先邀请若干用户进行预调研，确保实际流程无问题

（5）正式 ：进行正式调研，流程包括问卷调查、产品测试、量表填写、问题回顾以及访谈 （QTQII）。

（6）多轮 ：第一组用户结束后快速统计问题，解决掉有歧义的问题后进行第二组，此时重点关注第一组提及的问题，第二组结束后统计两组的共同问题，涉及到产品操作问题的迅速记录反馈给开发团队，接着进行第三组，可适当侧重共同问题，以此类推。

（7）结束 ：调研结束，表达感谢，赠送礼物

（8）整理 ：将各组的内容进行整理，提取关键的共同问题和差异点，尽快处理数据统计，遇到疑惑的地方可查看录制的视频或音频，必要的时候可以联系相关的用户。

以上就是我处理用研的流程，基本上是按照实际情况进行调整的。

三、实际工作举例

光说不练假把式，笔者有幸主导过app从0到1，故拿出该项目作为案例进行拆分解读，给大家一个具有实际背景的事例作为参考，这样能有一个直观的感受。

该项目实际资料和用研文案都进行了脱敏处理（ 保护重要数据从我做起 ），但不影响观看体验。

项目背景：

在无实际用研结果下，只是用行业报告和产品人员的判断确定了用户需求和产品功能，app已经完成了团队内部的测试验收工作，但没有实际的用户使用过，故希望通过调研一批目标用户来完成对产品的可用性测试和用户需求收集工作。

1. 准备方案

（1）确定调研主题

发现可用性问题：

主要是通过产品的可用性测试和用户反馈，来确定真实用户在操作中遇到的卡点问题、歧义问题和BUG。

尤其是歧义和bug的地方，歧义主要是因为专业人员在开发的时候很容易地就用上了专业术语，如各类弹窗和toast里的“服务端数据异常”、“接口错误”，还有些是“确定”“取消”傻傻分不清；bug主要是因为测试人员都是按照常规使用流程进行的测试，而实际用户有各种想不到的骚操作，例如他会将某些“敏感”图片作为头像，这时候就得接入图片审核。

收集用户需求原材料：

最初不做用户研究限于成本可以理解，但产品临近上线，是一定要收集定量和定性的数据来做分析，作为后续功能迭代优化的依据。

通过问卷获得人口学数据和定量数据，通过访谈和反馈来获得用户主观的数据，当然，这些都是原材料，还需要进行分析与处理。

（2）确定方案

方案分为两种类型，一种是流程性方案，即先做什么后做什么以及不做什么，另外一种就是执行方案，就是在某一环节使用的具体方案。这个好比功能流程图和页面图的关系

流程性方案：

大致流程就是上面介绍的参考流程，可根据实际再做增添，记住，流程可万变，但一定要实事求是。

这时候还需要 确定活动所需成本 ，包括人力、精力还有钱，因为成本也是需要上报的（打工人泪目）。如：

人力：投入1个产品经理和1个开发同事

精力：产品经理抽出0.8个人日，开发同事抽出0.2个人日

钱：预计接触20位目标用户，准备20份奖励，共1000元。

具体方案：

Q. 问卷调查设计

如下图，基本结构就是用户基本信息、问卷说明、容易问题、思考问题以及结束语。

1. 用户基本信息填写要考虑是否有必要，如用户姓名可用昵称代替。
2. 问卷说明写明目的，最好写出本方实际信息增加信任感，并且点明不会给到第三方（用户隐私很重要！）
3. 简单易选问题，第一题目内容不歧义（能让人读懂），二是区间选项一定要穷尽无交叉，比如A是1～10，B是10～20，那用户是10的话是选A还是B？
4. 耗时思考的问题，一定要给预选项和补充项，因为很多选项是设计的时候考虑不到的，例如学习的目的，不可能将所有目的都能考虑到，这时候需要给予“其他”以及“：”。
5. 结束，多说说感谢。

T. 产品可用性测试设计

如下图，基本结构就是产品介绍、测试注意事项、具体测试任务和结尾。

1. 产品介绍里写清楚产品的定位，让用户有所了解。
2. 注意事项里要提前说好可能会出现情况，尤其是要加“不会回答你的操作问题”。
3. 具体的任务描述不能带有指导性，例如，“你会选择xx进入到xx”，“你使用xx功能”，而是要设立场景，即“当你遇到xxx情况时，你会如何？”。
4. 多说谢谢。

Q. 用户体验量表设计

如图，其实可以直接使用很多标准量表，如SUS量表，这个量表的使用率是相对比较高的。

因为可以计算得分，还可以根据等级表进行软件评分评级。

注意，有些用户可能无法理解有些问题的含义，毕竟是英文转汉意的，最好能按照自己的语言再整理出一份，或者在测试的时候讲解（费力）。

I. 回顾或简短访谈

如图，有访谈说明、访谈内容记录和结尾组成。

1. 问题内容根据实际情况而定，一般来说预设问题都是产品经理和设计师提前设定好的，多是定性的想了解的问题，其次一定要留有一个自定义问题空白，方便调研人员发现个人问题的时候进行询问。
2. 需要留有记录空白，方便进行快速的关键词编写。

2. 挑选与预演

（1）挑选用户

一般来说，一类目标用户群体中不是每一个用户都适合邀请过来进行调研的，尤其是对于访谈而言，很多用户本身不太外向，导致问题无法深入交流，这比较考察调研人员的主持能力，是不可控的，所以需要对目标人群进行筛选。

合适类型：

• 如果是年轻人，可以在论坛微博、同类产品反馈（吐槽）里寻找到活跃用户，向他表明来意，这类用户一般是很愿意配合的，当然最好是本地的。
• 如果是中老年人，可以去当地社区或该类型人流量较大的地方进行观察，再进行邀请，不过这个容易引起误会，想当年我去农村调研被当成了手机贩子，差点被POLICE抓了(汗）。

（2）内部预演

顾名思义，先几个非项目组人员进行演练，千万不要找项目内的，不然嘻嘻哈哈，都是自己开发的产品相当熟悉了。

这个时候，注重看有哪些流程是浪费时间的，哪些部分是需要去除或更改的，根据我的经验 ，最起码会修改两到三次， 如果一次都没有是绝对不正常的现象。

3. 正式调研

确定用户排期，将用户分成多个小组，可以分为个人组和团体组，也就是个人调研和团体调研。

（1）实操

先邀请1到2位用户，按照标准流程进行调研，这个时候还是注重流程问题，因为之前的内部检查还是有很多细节没注意到。

记录好方案问题，立即返回进行修改，这个过程很短，不会耗费多少时间，但很重要。修改完整之后就可以作为最终版本正式进行大范围调研了，调研期间最好不要做更改，以免数据不够统一标准。

提前测试好硬件，有眼动仪、生理监测仪器当然好，但一切都可以从简，准备两套设备：三脚架+手机，一套俯拍用户操作，一套录制访谈。

（2）个人调研

一般来说流程是 问卷Q+测试T+量表Q+访谈I， 摄像头和录音笔准备好

问卷：

不干扰，直接填写

测试：

就默默观察他处理任务，手里可以简单记下节点情况 ，一般来说是用户疑惑（挠头）或者是完成其他任务的情况。

在这个环节中，基本上每个用户都会问：我做的对吗？这种都是比较“讨好”调研人员的表现，他们抗拒自己操作错误显得“白痴”，此时你应该微笑摇摇头，“你继续使用就可以了”。

千万不要去教用户如何做，否则就是白浪费时间。用户出现的这类问题很大程度上就是产品的问题，一定要观察好。

量表：

可以提前解答每句话的意思，但还是建议用自己的话再写一份量表。

访谈：

一个小tip：先送上礼物。经过前面几轮，用户有些不耐烦和疲倦很正常，提前给礼物能让他更加积极！传统理论里会让调研者在结束后再给，其实没有必要（一般人我不告诉他）

问的时候，有些用户会很简短， 此时调研者要深入问下去，一直问为什么，得到答案后再叙述下。

例如：

• 你觉得平时英语学习中遇到的最大困难是什么呢？
• 答：听力我觉得好难。
• 再问：是觉得什么地方难？
• 答：主要是听不懂，虽然四级考试听力听说很简单吧。
• 再再问：意思是说四级听力在你看来是没有那么简单的是吗？
• 答：是的，我听过很多次，但总是抓不到重点，做选择的时候就会错过很多问题。
• …….

这样，最后访谈的答案就不是一个简单的“听力难”的记录了。

结束后， 测试机子和app账号记得清空或还原，避免历史数据干扰！

（3）团体调研

团体调研一般来说是促进广泛启发沟通的，和个人访谈是相辅相成。

流程一般和个人访谈一样，但不同点是在测试T和访谈I上。

测试：

不可避免，他们直接会相互交流， 但好处是个人的问题可以得到群体性赞同 ，“这个我也发现了，我还以为是我一个人的问题”

访谈：

小组访谈，也被称为焦点小组，是指 调查者以一种无结构的自然形式与被调查者交流，通过倾听一组从目标市场中选来的被调查者间的讨论，从中获取对一些有关问题的深度了解。

其中的问题，除了开始与个人访谈一致的访谈问题外， 还需要添加之前个人访谈中出现的共同问题和特殊问题 ，以发动群体的广泛讨论，发现一些潜在的关键点。

但要注意，一群人里总会有“社交牛逼症”，也就是意见领袖，用户有时会因为受意见领袖发言的刺激而修改自己的发言，并且会加以主观润色，这很考验主持人的控场能力，也得找个更为社交牛逼症的理性主持人

（4）注意

尼尔森说过：“5个人测试可以发现80%的可用性问题。”

那么分成多个小组，每组五个人，就可以进行问题收集的迭代

也就是前面几组可以收集到大部分显见的可用性问题，如果开发足够快，能快速解决掉前面问题，再用剩下几组做测试，就能发现一些较小问题中的较大问题。

4. 结束与整理

• 表达感谢，送走用户
• 整理数据，分析并可视化

在汇总完测试和量表数据后，出一份可用性测试报告 ，整理问题的优先级，然后交付开发，继续推进上线工作。

同时根据问卷和访谈的数据整理出主要和次要的人物模型 ，人物模型后续大家感兴趣的话，我再写文章分享下如何简单构建。

四、结尾

最合适的调研方法取决于调研目的、要解决的问题和生命周期中的阶段。

经典调研方法论并不是要一成不变全盘使用，也不是毫不借鉴 ， 而是要在实际访谈工作中，使用其理念 ，也就是定性和定量的运用模式、用户情绪点的深刻把握。

很多产品和设计师，说自己所在团队没有多少资源可以用，做不了用户调研，但还是用户意识不到位，希望本篇文章的QTI方法能够给大家启发，其实成本真的不高（可能有点点高）。

如果你觉得分享的内容对你有所帮助的话，点个赞收个藏哦～

理论参考来源：《市场调研》《用户调研与可用性测试》《用户体验面观》

 

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

题图来自Unsplash，基于 CC0 协议。