其实我是一个非常喜欢做用户测试的设计师，开始设计前可以做线上产品测试，设计完可以做原型测试，遇到搞不定的方案还可以做A/B测试……

虽然有些领导和同事对用户测试不太相信，总觉得浪费时间又得不出什么有效的结论。

然而，他们看了我的测试报告后，态度都一下子来了个 180 度大转变，甚至有人变得不测试验证一下就不敢上线了。

后来我才发现，他们之前不信任用户测试的原因，是因为之前有设计师这样做过，但是结果无法让人满意。

其实可以理解，因为用户测试原理简单，其实不是随便学学就能做好的。

P.S. 如果你不知道啥是用户测试/可用性测试的话，还是先去这里看科普吧：与几百人实践了数十次，我发现设计师应该这样做用户测试

用户测试为什么难做好？

很多业内小伙伴都或多或少接触过用户测试或可用性测试这类东西，很多大公司的体验度量体系也将其纳入指标中。

虽然学习资料很多，但是要真正做好，确实很不容易。

书上教的方法大多来国外老前辈们，他们虽然厉害，但毕竟国家文化、职场环境和时代背景都与我们相差甚远。

直接照搬书或网上的方法是很难成功的，更何况很多人就连照搬方法都很难做到。

我到目前为止做的用户测试应该有三五十场了，每次都能总结出新的经验。

有些朋友可能会觉得奇怪，用户测试不就是列出几个任务，邀请一些用户来使用，然后记录问题就好了吗？有什么难的？

今天就来分享一下，我过去失败的 3 点经验，给想尝试的朋友一点参考。

1. 

要仔细挑选任务，

不是把主流程走一遍就好

通常用户测试的教程会告诉你要列出一些任务给用户去做。

然而一个产品，哪怕只是一个模块，可以测试的功能点太多了。例如我现在正在用的公众号文本编辑器，字号、加粗、字体、行间距……任何一个小图标，都可以用来测试。

但是，你不可能让用户花费好几个小时帮你把所有功能都用一遍，因为：

1. 耐心磨掉后，用户就不能保持正常状态了，测试表现也会失常；

2. 如果一个用户就花费好几个小时，那么多个用户就要花费好几天，不一定等得起；

3. 让用户花费较多时间意味着要支付较多的酬劳，但是如果酬劳太高又怕用户不能在测试中表现真诚。

所以，我们只能挑选一些有价值的任务，要么是对业务有帮助，要么是对设计觉得有帮助。

最好是做用户测试之前，就能预判用户可能在哪里出问题。

2.

除了记录问题，

还要记录任务完成率

一般可用性测试的教程都会告诉你，测试时最重要的是记录可用性问题，例如用户没有找到什么按钮、没理解什么功能……

但是根据我多年做用户测试的经验，记下任务列表里各项任务的完成情况也很有用。

看下面这个例子就知道为什么要这样做了：

上面两个方案，从测试结果看，哪个问题更大呢？

方案 A 虽然问题很多，但并没有影响用户使用；方案 B 虽然只记录了一个问题，但是却让用户没有完成任务。

所以方案 B 的问题更大，更需要修改。

但是如果没有记录任务完成情况只记录了问题，就看不出方案 A 的优势了。

3. 

公认问题评级标准，

不一定合适

用户测试收集到的问题，通常都需要经过评级，才能筛选出哪些是重要的。

为了让结果更加准确可信，通常是让几个人一起按照统一的标准给问题一一评级。

学术界和行业里有不少可用性问题评级标准，我以前用得最多的是 Jeff Rubin 可用性评级标准（本公众号后台回复「问题评级」可以查看）。

但在实际工作中做久了，我发现这些评级标准都太不接地气了。

因为这些标准都以可用性为核心，但在我们实际项目中，要评判一个问题的优先级，可用性并不是唯一的标准，甚至有时候不是主要的标准。

上面两个问题，虽然可用性评级都是很重要，但是因为业务影响和解决难度的差别，一个最后决定立即改，一个最后决定先不管。

更多……

如果你想要通过项目实践来快速提升，可以参加我们「体验设计学习社」即将举办的「体验评测训练营」，只需三周时间带你完成一个真实项目的有效评测，大大提升你对用户体验的认知。

这周日晚 8:30 我会开直播（今年太忙了，这应该是第一回）和大家聊一聊一下更多关于用户测试的事情，大家有什么问题也可以现场交流，而且还有福利发放：

本文来自微信公众号“体验进阶”（ID：Advanced_UX）。大作社经授权转载，该文观点仅代表作者本人，大作社平台仅提供信息存储空间服务。