在产品开发之前，用户测试必不可少，这能帮助设计师更早发现问题。而其中需要注意的细节也很多，文章针对用户测试的一些流程以及相关的注意事项进行了总结梳理，希望对大家有所帮助。

在开发前的设计阶段就进行用户测试，能够更早发现问题、降低开发试错成本。可这一方法对于国内的互联网行业来说还比较陌生。

我之前整理过一套产品设计流程，在这个流程里，用户测试就是相当重要的一环。

虽然很多人对用户测试比较陌生，害怕尝试，但我认为用户测试不论是从可行性、实用性还是效率性上，都是很高的。唯一的缺点就是，它有一定的认知和学习成本。然而一旦了解入门了，你会发现用户测试是一种高效科学提升产品体验的利器。

设计师做用户测试有什么好处？

有人可能会质疑，设计师学会利用设计理念出方案就好了，测试不是用研的专业领域吗？

我觉得这样的认知是错误甚至危险的。

首先，依赖设计理念做设计是非常不靠谱的。因为很多设计理念没有一个量化标准，而且很有可能必须在某种特定的条件下才能生效。例如，“少即是多”要少到多少才合适没有明确、“情感化设计”要有多少情感才行、“以人为本”的与商业化的平衡是什么……

这样的设计方法，就好比共产主义的口号，在特定的时候看起来也许很美好，但是如果把握不好轻重，可能一边把自己推入深渊还一边自我感觉良好。

如果说团队里的用研能够承担用户测试的职责，那当然好。但以我的了解，很多公司的用研主要为业务做调研，实际工作更像是市场调研。为老板做报告PPT已经够忙了，他们没有时间精力顾也没有理由顾及到产品体验甚至是设计方案的优化。

而设计师能直接利用测试结果，为设计方案增加实质性的依据，无论是面子上还是里子上，都是有利的。

尤其对于需要较多汇报和论证的ToB业务来说，用户测试的效果更加显著。我的实际经验告诉我，要搞定甲方领导，用户测试远比设计理念有效得多。因为哪怕是对互联网和设计一窍不通的门外汉也知道，产品好用与否，用户才是最有发言权的。

体验评测流程

用户测试是一个很宽泛的概念，涵盖的方式方法非常多，很多我都有实践或研究过。文章末尾我会告诉你哪里可以看到这些用户测试。

例如：眼动实验看似高大上实际上不但成本高而且很难让用户在自然的情景下做测试、 Think Aloud 虽然能够发现很多细节问题但是用户教育成本过高而且很难把握好平衡；Focusing Group 看似省时省力其实很难把听到用户的真实声音；用户参与设计耗时耗力还一不小心就被带节奏走偏了…

也许是因为自己的理科底子，我对用户数据说话的用户测试很感兴趣。这些年来大大小小做了十几二十次，被我带动着一起参与进来的设计师至少也有两三百人。期间我也和小伙伴们输出了一些体验评测报告，文末我会告诉你在哪里可以看到。

每做一次我都会总结问题、优化方法，直到现在终于整理出了一套适合产品设计者、较为通用、简明高效的体验评测方法：

1. 制定目标

没有什么事情能够一蹴而就，用户测试也是需要根据实际情况制定目标范围的。这个目标范围可以是一个功能列表，即评测产品的主要功能或本次迭代的主要功能等。

例如一款快餐外卖小程序的目标范围可能是：

• 浏览和搜索菜单
• 收藏和查看
• 优惠券查看和使用
• 选择地址
• 选择口味
• 点餐和支付

除非做得很细，否则不需要很复杂，就是圈一下几个功能就好。

2. 编写任务

你需要写一个任务列表给测试用户，让他们看着这个任务列表使用产品，不需自由发挥和现场询问，就能够把目标范围里的功能统统使用一遍。

例如上面那个测试目标的任务列表可能是：

1. 在菜单中找到任意一款带饮料的套餐并收藏
2. 搜索米饭并添加到购物车
3. 在收藏列表找到套餐
4. 使用新人优惠券购买收藏的套餐和米饭
5. 送到现场，口味选择不辣
6. 支付

这个任务列表要简短到让用户一眼看懂，明确到不需要用户现场提问，但又覆盖了目标范围内所有的功能。

3. 编写问卷

任何形式的用户测试和访谈都最好附上一份问卷，一方面是记录备案，另一方面也是从用户那里获取观点想法的机会。

对于如何做问卷，谁也无法给出一个标准答案，因为这就是一个具体情况具体分析的东西。不过我这里有一个从HCI教授那里得来的框架，还比较通用：

• 基本信息：如：年龄、性别、职业…
• 行为：有没有用过产品、使用频率、相关日常行为和生活习惯。如：是否使用过评测产品、点外卖的频率是多少、喜欢什么类型的快餐食物、能接受的价位是什么…
• 动力：是否愿意/不愿意使用评测产品、理由有哪些。如：愿意使用外卖平台还是餐馆小程序、怎样的优惠福利会有吸引力…
• 态度：对评测产品和相关事物的喜好和印象。如：对餐馆的印象、对快餐的喜好…
• 技能：使用产品和设备的熟练程度。如：使用手机点餐频率有多高…
• 资质：学习能力或学历认证。如：最高学历是…

对于定量问题，为了方便统计，一般会固定分为五个/七个等级，例如：

1. 特别不喜欢
2. 不喜欢
3. 一般
4. 喜欢
5. 特别喜欢

4. 招募用户

很多公司不愿意做线下用户测试是因为觉得需要的人太多，成本太高。其实体验评测采用心理学研究方法，讲究质量和深度，并不像大数据那样无法确保质量只能靠数量来凑。

尼尔森在2000年经过试验表明，只需要5名用户就能发现80%的可用性问题，而真正重要的问题通常已经包含在这八成之内，剩下的二成问题一般都不会特别重要。这对于很多小版本迭代来说，已经足够了：

对于大部分轻量产品的小版本迭代来说，五名用户已经足够。再复杂的，一般也不会超过十多二十个。

招募的用户当然最好是符合产品目标人群的，尤其是对需要正式汇报的项目而言。毕竟精准用户的某些特别需求和认知想法会不太一样。

但是这并不代表随便招揽用户就不OK。像那种在街上随机找人的走廊测试，也照样能发现不少对设计有帮助的问题，因为很多可用性问题都是诸如找不到XX按钮、缺少XX功能之类的“通俗”问题。

5. 进行测试

招募到用户后，你可以把他们约到同一天，一个一个单独见面测试。测试至少需要一名记录员全程引导和观察，需要做的事情有：

1. 引导用户完成任务（可以录屏/录影）
2. 记录任务完成情况（成功/失败）
3. 记录下所有用户发生的可用性问题
4. 引导用户完成问卷

可用性问题可能有人不太理解，这里给出一些范例：

• 找不到搜索功能
• 点击收藏图标后没有反应，不确定是否收藏成功
• 难以找到口味选项
• 默认定位不准，必须手动搜索
• 加载速度太慢，用户丧失耐心
• …

记录问题的学问大了，很多细节需要实践才知道，这里稍微给一些提醒：

• 记录员避免与用户交谈，哪怕必须对话，也要避免给出任何引导性的指示。
• 不要漏掉关键信息，例如“没找到入口”可以改成“没找到优惠券入口”。
• 记录问题而不是给出修改建议，例如“说明颜色应该深一些”可以改成“用户没看清说明文字，颜色太浅”。因为一个问题的解决方案非常多，记录员应该把问题如实写下，后面可能和团队一起思考解决方案。
• 记录事实结果而不是猜测原因，例如“菜单信息太过繁琐”可以改成“难以理解菜单信息”。因为记录员的猜测也未必准确，很有可能对其它查看记录的人造成误导。
• 用户在任务之外的使用过程中遇到问题也可以记录下来

为了方便整理，可以使用统一的模板。下图是我做的这个模板，在文末会有下载方式：

6. 统计分析

等测试完所有用户后，需要把记录写入电子表格。

下面这个任务统计表是我的做的，在文末会有下载方式：

分类其实不是特别重要，从实用角度来，如果不是特别正式的报告看不做也OK。如果要做的话，可以使用已有的分类标准或者根据具体情况自创分类标准。已有的分类标准中，比较常用的是启发式评估法：

1. 系统状状态可见
2. 系统与用户现实世界的匹配
3. 用户控制与自由
4. 一致性与标准化
5. 错误预防
6. 认知而不是记忆
7. 使用的灵活性与效率
8. 美观而精炼的设计
9. 帮助用户识别、诊断和修正错误
10. 帮助和文档

分级才是最关键的，因为它可以帮助我们梳理出产品的主要问题，为方案优化和迭代改版提供数据依据。问题分级的标准有很多，你也可以指定自己的标准。我自己用的比较多的是 Jeff Rubin 可用性评级：

• 四级、无法使用产品的某一部分
• 三级、难以完整使用产品的某一部分
• 二级、大部分情况下能够使用，但需要付出较大努力
• 一级、偶尔发生且容易解决，或者问题并不在产品的主要功能上
• 零级、不是可用性问题

可以有多个人一起来评级，取平均数作为最后的评分。不过也没有必要太过纠结，问题评级一定是一个有些主观的东西，小争议难免，但是真正的大问题通常不会变成小问题，真正的小问题也不会变成大问题。

用户问卷的信息也是可以统计出来的做成图表的。如果用问卷网站来做调查，这些都可以自动生成，就不是示范了。

7. 优化设计

当你把任务、问题和问卷三张统计表整理出来后，就可以进入下一阶段了。

• 任务统计表是用户测试的硬指标，任务完成率低证明用户体验对业务转化率造成了直接影响，解决相关问题迫在眉睫。
• 问题统计表是用户测试的主要指标，可以通过问题评级或加权问题评级（评级×发生率）排序，来看看设计方案有哪些重要的体验问题需要解决。
• 问卷统计表是用户测试的基本参数，例如通过分析问卷统计表，可能发现某些问题可能只有某类人群会发生，那么就可以综合考虑是否需要投入成本为这类人群修改设计方案。

有了这些指标和参数，你也就对设计方案的用户体验心里有底了，接下来赶快去改稿子吧。

改了之后可以再测一下，不行再改，循环往复直到没有大问题为止。

作者：Z Yuhan，一名前华为腾讯交互设计，在英国学习了人机交互，乐意带你由浅入深了解产品体验；更多的阅读和资料，请关注我的公众号：体验进阶。

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

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