保姆级教程！掌握大厂设计师必学的可用性测试完整方法

设计市场初期会 PS 就能够找到工作，慢慢演变为需要做好看能找到工作，在之后变成既好看又好用能找到工作，直至现在既要好看又要好用，还要能证明为什么好用，都不见得能找到工作。

企业越来越过分，总是既要又要还要，想去好公司就必须具备多项能力，会用研、有设计思维等成了各企业招聘得重要标准。但很多伙伴出自小厂，没人带、没人教、哪里会形成完整的设计思考。最终形成了去大厂要设计思维，但是不去大厂又学不到设计思维的死循环。

今天带领着你学会一些用研知识，打破死循环。

伙伴们可把学到的知识推演到自己项目中，包入作品时完整呈现在改版前发现问题的过程，让改版有理有据，避免面试官看到你作品时“一眼假”。

不会用研进不去大厂 ，不仅大厂不会用研，死循环

一、用户研究之可用性测试

设计都是偷窥狂

什么是可用性测试？

官话来讲：可用性测试是通过观察用户使用产品完成典型任务，发现产品中存在的效率与满意度相关问题的方法。说人话：别人操作，你偷偷观察他的操作过程，并总结分析产品问题。

可用性测试目的是为探索设计的可能性、验证设计的有效性、或是为了方案对比，最终可以归结：想让用户爽。

为什么一眼假、不真实？就是因为我们大刀阔斧改的方案，根本没站在用户的角度、不考虑企业的利益，换句话说是我们在主观的为用户做出选择，都是个人“意淫”，必然看起来假。

想要做好这件事，就要搞清楚设计为谁做，目的是什么。

二、为甚么要做可用性测试？

为你上盘菜，吃了你就知道了。

上盘菜

假说你从没下过厨，但想为你非常重视的男神做道菜。你看着网络教程做，做完自己也不尝尝直接端给男神吃？这种可能性不大吧？即使有教程，第一次下厨很大概率也会搞出黑暗料理，严谨一些的流程应该是什么样的？

想为男神做饭—开始做饭—自己品尝—邀请闺蜜品尝—收集反馈—优化菜品—邀请男神

抗风险

为避免翻车，自己会品尝菜品，回归到设计这个举措叫什么？自测试吧？但是你认为好的就一定好吗？不一定！此时还需第三方评价，在客观的角度上做出认证。邀请闺蜜试吃就是为了对抗上线翻车风险。

邀请闺蜜试吃这件事就属在进行可用性测试，类似于这样的事大家都做过吧？

很多时候我们自认为的好设计 都是产品、设计、老板自己想出来的，大家总会说：我觉得、我认为…可用户不要你觉得他们只要他觉得，你认为的不见得一定是对的，所以在产品每一个阶段我们都可以通过测试来判断用户到底需要什么。

方案初期验证方案的可用性、有效性。上线后可以通过测试来进行体验性的验证，同时可为后续迭代做准备，对抗未知风险。

你是故意的 ，还是不小心？

不要小看这一步骤，被称为最强阳谋的小胖为什么会被评为淘汰（这里是一个综艺节目，小胖用未清洗大肠做饭，让评委吃）自己都不试吃啊，翻车实属必然事件。

三、3+1 形式：测试前准备

老 3 样：时间、地点、人物。+1:任务

时间 、地点、人物、任务

时间

测试的进行时间需要控制住 1-2 小时以内，并要提前预约好别人时间。

想来你闺蜜也不会随叫随到吧？人家不需要陪男朋友吗？与参与者的时间一定提前约定好。

控制测试时长，避免时间过长让参与人员产生对抗情绪。

提前整理好参与测试人员名单，备注其姓名、工作、约定时间、以及该用户特征。资料沉淀，无论是给领导汇报还是入作品集都是非常加分内容。

时间

地点

这一点无需多说啦，咱请人吃饭总得有个地方吧，总不能蹲在大马路边上吃吧？是在家吃、还是在客厅吃？

测试地点自然会议室属最优选择咯，相对属于安静的环境。PS：专业的用研公司会有专门的房间来进行测试，双面玻璃的观察房那种。咱小企业不需要考虑这么多了，成本过高就不必奢求。

地点

吃饭总需要餐具吧，碗啊盘子啦、筷子啦、餐巾纸之类的内容总是要准备的吧？那可用性测试需要的‘餐具’都是什么呢？

物品准备

如图所示，记录本、笔、录音笔（实在没条件可以考虑用手机录音）测试用的手机和电脑，还需准备一台用于记录信息的电脑，如果有需要可提前准备录屏软件，还有一个重要事情～准备好给用户的小礼品哦。

招募人员

人物：招募用户

时间、地点、餐具都准备好就可以有请你的好闺蜜们闪亮登场啦。

你对于选闺蜜，选男友有要求，我们对于招募用户也是有要求的，招募的用户可从用户画像中寻找相关特征，比如说你用户分层有老年人、青少年、儿童，那你则需要把着三类用户都招过来才好。每组 4-5 人即可。

小心研发为你挖坑

当然也可以粗暴的将用户分为两类，专家级用户、小白用户。

专家级用户就像我们这种做设计师、或者研发、产品、具备竞品经验用户、用户特征和我们的产品匹配的。普通用户所指没有相关经验的，了解行业较少小白用户。有些伙伴应该发现了我标记的红圈，测试时要注意不要让同组产品或者研发作为被测试人员，东西都是他们研发的，你让他们说哪里有逻辑 bug 那他能告诉你么？又当裁判又当运动员可不行。

核心目标在哪里 ？

有目标才会衍生任务

时间地点人物介绍清楚了，就要说一下我们测试目任务是什么，毕竟有目标才会有前进的方向。

例：你想成为设计高手所以来阅读文章

例：做了两个设计版本，想确定哪一个版本更好，所以测试

例：不确定当前方案是否满足用户诉求，所以进行测试

例：功能已经上线，想观察用使用状态，进一步总结为迭代做准备。

不可能今天咱脑门儿一热，突发奇想来做个测试吧？

我们要做的事情 ，搞清价值、理清任务、设计量表

任务 1：明确功能本身价值，此能帮助用户解决什么问题？（一句话说清楚此功能的作用，换句话说就是这个功能最起码有用）。

任务 2：确定好功能后围绕此功能 展开其用户操作流程。

例：我想在购物软件上买一架直升机，流程大概是：打开 APP—搜索并挑选—加入购物车—下单并支付，将此流程记录形成任务（流程）大纲。

大纲特征也可帮助指导我们筛选招募人员，例上述流程可判断出招募人员的特征最起码要帅气！多金、有购物（网购）习惯的用户。

价值与任务

输出这样一份表格，将目标、任务细化。

还需要准备几份量表，ASQ 量表、SUS 量表等。不要被名字吓到，其实使用起来非常简单！！！这两份量表内容都是固定的，咱拿去套用就行。

ASQ 量表：用户执行任务后对有效性、满意度做出评价。毕竟测试做的是否成功，任务设计的是否复杂需要一个标准来衡量，我们测试做的是是否成功？是不是需要和领导做汇报？拿什么去汇报？这个表不就解决问题了。

SUS 量表：用来判断咱们产品的可用性和易用性。

虽说题目是固定的，但大家要对其中内容有所了解，例 SUS 量表中第 6 条：我发现产品中很多不一致的地方，用户可能会疑惑，这是啥意思？需向他进行解释，比如说颜色使用不一致，字体大小不一样，设计风格不一致，操作上、流程上和用户的使用习惯不一致等等。

这两种量表都是 5 分制，分别是从非常不满意—非常满意，拿到用户评分后进行平均值计算就好啦。

ASQ 、SUS

说一下 SUS 量表的计算规则，敲黑板啦！！很简单一听就会。

这 10 道题里

将奇数题：用户评分-1（如用户第 1 题评 4 分，那该道题的得分则是 4-1=3）

偶数题：5-用户评分（如用户第 2 题评 4 分，那该道题的得分则是 5-4=1）

然后将 10 道题的分数相加在乘 2.5，就等于总分啦。

如果平均分超过了 70，使用体验已经甩出其他产品几条街了，如果低于 58 分，那这项功能需要慎重考虑一下了哦。

除此之外还需准备记录表、日程表、用户知情同意书、保密协议等等（不过类似于这种玩意公司内部测试很少用，除非保密项目或一些 B 端项目，严谨就准备一下，单纯分析调研倒不用那麻烦，依自己公司情况来定就好啦）。

串联一下

四、测试前的准备

总体串联一下：

咱想请男神吃饭这，先邀请闺蜜来家里试吃。

测试目标：测试饭菜做的好不好，是不是达到上线标准（测试价值/目标）

测试时间/地点：下午 2:00 在家里（预约受访者）

准备物品：餐盘、餐巾纸、刀叉等等（设备准备、各类表准备）

参与人员：生活精致、爱美食、女性巴拉巴拉（根据特征进行用户筛选、招募测试人员）

测试任务：先吃沙拉后吃酱、先吃甜点后吃饭（任务大纲梳理）

五、执行可用性测试

准备工作已就绪，是骡子是马走上一圈～

团伙作案

团伙作案

团伙先占领会议室：团伙配置要求需 2-3 人，不易过多，你想想如果你在吃饭时一群人围着你，能自在吗？如果人员不够，则最大标配主持人、观察员。

主持人：最好是行业相关的人，亲人、不要总板着脸，总不好请一个光头、膀大腰圆的花臂大哥吧？会吓到客人（反正我害怕）。

观察员：需降低自身存在感默默在一旁观察、记录他的罪证。

座位要求：客人要坐在主要位置，其他人可选择坐在斜对角、侧面、避免给客人带来心理压力。

注意：测试过程中不要随意的去打断客人操作！咱要讲礼貌不是～

暖场子

暖场子

人都来了总要吱个声打招呼吧！先把场子暖起来！！嗨起来！！

参与测试者和我们大概率不熟，需寒暄一下、进行段自我介绍，记得随行伙伴也要介绍，毕竟你不是来说单口相声。

告知测试目的、注意事项告知，毕竟可能会录屏、录音、摄像等等，需让参与者知情，告知录像录音之类的只用来做分析，不会泄漏出去。告知操作不分对错，测试者可按自己习惯操作，如遇困难尽量努力解决，我们不会提供过多帮助巴拉巴拉...这种话术就自己编辑一下就好啦～

切记做介绍时不要照着稿子念，毫无感情色彩会让人感受上非常不适，我们只是唠家常而已，像朋友一样聊聊天，可以围绕着想要测试的功能进行询问。

举个栗子

例：怎么样，最近忙不忙？平时还有机会和伙伴出去聚餐吃饭什么的？你和朋友出去通常都吃些什么？你们是提前预定还是直接去餐厅吃呀？你是如何通过软件预定呢（进入主题）

也可以做测试前的访谈，了解一下用户的年龄啦、岗位啦、习惯特性之类的（不过我更倾向用户特征内容可在招募用户时的问卷中收集）

通过聊天形式了解用户，拉近距离，同时引导他们进入操作场景

如测试的场景出现概率比较低，可通过讲故事、提假设、引导用户操作，总而言之，言而总之要给用户一个执行任务的理由。

提出任务

为用户设计的任务要聚焦在核心流程上，不要搞那种找到某个功能按钮，可以把这些个小问题融合在大流程内一起测试，正所谓好钢用在刀刃上。

要是招募人过来就是为了找不同，实在是对不起这份折腾。

明确任务的起始点在哪，用户会在哪里开始，哪里结束，这也是对于任务设计是否合理判定标准之一，关于起始点和任务流程前面说过 这就不再赘述了。

明确起始点

提个注意事项，布置给测试者的任务不要颗粒度过高，要符合用户的操作逻辑。

吃饭就好好吃饭，不要要求人家吃几粒米、菜要嚼多少口，限制过度、任务颗粒度过高会导致用户无法按照个人操作习惯进行执行，测试也就失去了意义。

符合逻辑，大家都知道甜点应该饭后吃，你上来就让人家炫甜点明显不符合大家正常逻辑，不符合逻辑的操作，用户只会觉得莫名其妙罢了，不会带来实际价值。

任务大纲只需给个大概，让其自由操作就好，如测试结果于我们计划的相差甚远，需反思一下是不是话术引导出了问题，或者功能本身出了问题，又或是我们未给出任务框定条件，例：想让用户操作产品中的地图导航，布置任务时告诉用户要从地点 A 到达地点 B，参与者直接掏出百度地图！这明显脱离测试范围，需要及时干预、补全任务条件：仅使用某某 APP 完成此任务。

总结：创建任务注意事项

任务聚焦：聚焦核心流程、能为用户来带价值意义的功能上，任务安排不易过简单。

场景化：布置任务前先为用户塑造场景，为用户执行任务创造理由。

常规化：任务操作逻辑合理，步骤安排颗粒度不易过高。

起始点明确：判断用户是否完成的主要依据。

听她说 、看他做

开始「偷窥」

此过程中主要是听她说、看他做。

听她说：可让用户在每步操作时说出来他要做什么（这也称之为：发声法），或谈自己的想法，我们跟着用户思路就好，如用户操作过程中忘记说出自己的操作，或在某一页面长时间停留，可适度提醒：此时你在想什么，可以分享一下吗？或者问您在看什么？您在操作什么？

如用户操作过程中出现困惑，向我们求助，我们要尝试进行反问：您觉得接下来怎么操作比较合适？您平时是怎样进行操作的呢？引导鼓励用户进行思考。

全程我们应保持中立，不要诱导用户做出操作，如确实遇到了 BUG 无法避免未知错误时可先引导跳过此步骤。

看他做：多观察用户的操作、肢体、表情等。例如他在操作某步骤时皱眉、忽然浅笑、抚摸下巴、 摸耳朵等等，任务结束后需及时提问让其为你解答（看您在操作某某步骤时浅笑了一下，可以和我分享一下原因嘛？看到你操作某步骤时不断摸下巴，是遇到了什么困难吗？等等）。

用户访谈

提问过程属于访谈内容咯，这里就不进行展开谈啦～后续会继续写篇访谈技巧文章的～

问卷回收/总结

任务、访谈结束后就可以掏出咱们准备好的各种表让他填啦。ASQ、SUS 等等量表。

着重说一下用户体验记录，此表需让用户根据（京东团队整理的）21 条可用性原则辅助理解进行填写，21 条会将问题进行分类：例导航、页面、内容、功能需求等等，方便我们后续对问题进行整理。（注意表中需允许用户插入图片，可以辅助我们准确判断用户所阐述问题点在哪。）此表偏向于让专家级用户填写，对小白用来说户理解成本偏高，咱们很难有效回收问卷。

汇报一下

总结汇报

将咱们访谈过程遇到的问题、问卷回收问题进行分类整理。描述问题点、问题出现原因是什么、缺陷重要程度、是否有优化空间、是否存在对应的某些设计难点等等。总结并输出设计建议反馈到领导以取得支持。

总体来看一遍访谈流程

知道很多伙伴可能看的看那么多字，在此总结了测试框架，大家按框架去执行可用性测试就好啦。

流程框架

此外担心表格内容看不清，为大家放大一下，有需要的伙伴可以拿去抄作业。

记录表 、汇总表、维度表

ASQ 、SUS、21 条

21 条/纬度包含了大部分设计落点，不会定义目标的伙伴可在表内寻找问题，带着问题进行倒推 走查自己的项目。

可用性测试还需要用到用户记录表、剧本设计、任务表等等，这里就不为大家一一展示了，毕竟每个人所做的事、所处的环境不同，此类表大家按需自定义就好咯。

伙伴们也可将本篇框架带入自己的作品集，多提一嘴，咱们总谈到的‘用户体验地图’其实也与可用性测试息息相关，如果你有在作品中提到体验地图，将其与可用性测试关联在一起可很大程度的怎加地图可信度。

这就是发现问题—分析问题—提出方案的过程嘛～有框架做支撑就不会让人觉得的作品设计一眼假喽～希望本次写的内容可以对你有所帮助。

最后！祝你和男神女神吃饭愉快

拜拜～