前言

学习的时间不短了，案例也分享了许多， 所以~~我打算自己做一次可用性测试了：

本次可用性测试的目标为‘到位’，支付宝版本为9.9.8，网络为WiFi环境。总共有9人参与测试，均有多年移动app使用经验。测试发现：到位的在系统可用性量表（SUS）上的得分为60.6，在Lewis和Sauro的等级表中评级为D级，优于该数据库中30%左右的产品。

接下来将是对测试过程的详细描述。

测试目标

本次测试的目的在于探索‘到位’4个核心流程的可用性，并在测试结束后使用SUS量表评估‘到位’整体的可用性基线水平。

测试流程

测试前（3~5分钟）：a) 了解用户对‘到位’的认知；b) 用户花3~5分钟的时间熟悉到位的界面和功能。

任务测试（25~30分钟）：分为3个任务情景，共5个任务，涉及‘到位’的4个核心流程：

背景A：你最近时间比较宽裕，希望找一份家教的兼职来填充空闲的时间并获取一定的报酬。

a) 在‘到位’中找到一份合适的家教（去帮忙）

b) 在‘到位’中提供自己的家教工作（发布服务）

背景B：今晚你的朋友都没有时间，但你希望能够有人陪你一起运动（跑步、打球等）。

c) 在‘到位’中找一个合适的人陪你运动（找服务）

d) 在‘到位’中提供你需要找人一起运动的诉求（发布求助）

背景C：你需要马上把文件带给你的同学，但你和你的朋友现在都无法脱身。

e) 在‘到位’中找人帮你把文件从北区李苑419带到南区人文楼505

备注：用户使用自己的移动手机完成任务并在操作时做出声思考；在测试中对背景A和B的测试顺序进行平衡处理；每个任务完成后退出至支付宝首页再开始下一个任务；通过手机摄像记录下用户执行任务的过程；任务e的目的在于测试‘到位’的易学性。

任务/测试后（3~5分钟）：用户在每个任务后完成SEQ问卷；在完成全部任务后，填写SUS量表。

测试结果

测试完成度：用户的测试情况分为完成，放弃和错误三种。后两者分别是用户主动放弃继续任务和用户错误地认为自己完成了任务。需要注意的是，尽管任务描述中鼓励用户在地图中探索以完成任务，但用户使用搜索/发布功能也算作任务完成。各个任务的完成情况如图：

任务难易度：用户在每次完成任务后对该任务的难度进行从非常困难到非常容易的7点评分。在第一轮测试3名用户后发现用户容易的评价其完成的任务为非常容易，放弃的任务评估为非常困难。因此在之后的测试中将‘打开支付宝’这一任务定为‘非常容易’的标准。在统计分数时，也只计算6名的SEQ分数。如图，用户在执行第一个任务时经历了最高的难度，随着测试的进行，用户开始熟练到位的使用，任务的难度开始下降（图中数值大代表难度低）。

可用性分析

1. 分析录像：在黄色的贴纸上记录用户的操作路径和部分言语；在旁边通过不同颜色的贴纸记录观察到的可用性问题或亮点。

2. 归类整理： 将不同的可用性问题按照类型进行分类和计数。

可用性亮点

1. 使用路径  到位中可以通过多种操作路径达成同一任务目标。大多数用户的使用路径为：在地图界面探索---使用导航栏或搜索进行筛选---（无结果的话）发布服务/求助。有一名用户表示没有注意到搜索功能。

2. 功能模式  用户能够通过地图直观判断距离和地区；地图上的气球图标能够吸引用户的注意力并鼓励探索；服务封面有助于用户对服务提供者进行第一印象的判断。

可用性问题

1. 服务vs. 求助  6名用户在使用中没有切换找服务/找帮助，且在发布服务/求助时存在犹豫。其中1名用户在表示‘这里没有人需要家教’而放弃了任务，3名用户在找家教的任务中预约了他人的家教服务。

2. 交互细节

a) 在地图界面：两名用户表示‘只想和女生一起跑步’，但只通过地图气球一个个探索；

b) 在发布服务表单：8名用户忽视了导入封面图片；所有用户都触发了‘描述不可低于50个字’的提示（后期确认表示如果不是测试，会填写更多内容）；界面中中显示已存在图片，但提示‘图片上传未完成’。

c) 在发布求助表单：用户似乎会将发布服务时学习到的规则套用在发布求助的表单中（用户在描述求助时输入完整的用户背景，有一名用户在求助发布成功后惊讶于没有50个字数的限制）；用户输入标题的内容通常与求助分类相同（找人送文件的任务）。

3 .命名

a) 主要体现在发布服务和发布求助时二者的分类并不存在对应关系；

b) 发布服务时有较多分类，用户经常跳过‘教育咨询’，有两名用户选择了‘专业咨询’；

c) 发布求助时，用户对分类的理解存在歧义：在发布‘找人一起运动’的求助时，有6名用户选择了‘其他’，剩下的2名用户分别选择了‘寻人’和‘跑腿’，还有一名用户在‘寻人’和‘其他’之间犹豫后选择后者。

4. 其他

a) 地图vs.列表模式：尽管在初次打开的时候有着蒙版提示，但仍只有1名用户在任务前的熟悉产品阶段发现了列表模式，并在任务中持续使用。

b) 推广：在测试前所有用户均不知道‘到位’功能，即使更新了支付宝；

c) 网速制约：地图气球的加载速度导致用户误判‘这边没有人用这个啊’；

d) 新旧版本规则冲突：测试中有一名用户使用的旧版本，所以在添加6张图片后仍然收到‘请添加封面图片’的提示；

e) 可信度问题：1名用户表示不知道能否相信服务提供者，并表示不知道‘芝麻信用’代表什么。

建议：

1. 对找服务和去帮忙两个底部TAB做更明确的区分：用户通常不会切换底部TAB，而是在默认的首页进行探索；

2. 搜索和筛选功能的优化：尽管地图气球鼓励了用户在到位中进行探索且能够快速对比距离差异，但事实上大多数任务是通过搜索或发布完成。

3. 对表单中项目的填写限制和必填/非必填项做出明确的标识；

4. 为服务描述提供可选的模板，避免过多的输入操作导致用户流失；

5. 对服务和求助的类型进行优化，以方便用户快速选择分类；

6. 新旧版本间规则冲突的BUG修复。

测试中踩的坑

1. 一定要事前确认设备的版本等信息。我在测试中看到同学支付宝上有‘到位’就默认他更新了，但事实上是旧版... 虽然也发现了新产品的规则被直接套用在旧版本上这种BUG.. 但源于该用户的其它测试结果（SUS,SEQ）我就无法使用...  在真正的用户研究中这部分的招募、测试成本就基本白费了...

2. 测试过程中应该关注用户的操作并适当的做笔记。在第一轮测试中，我明显更多关注了摄像的效果怎么样... 以至于不得不在后来和他们再把视频过一遍才知道该问些什么，对于一些明显需要提问深入了解的部分也没能够及时关注。

3. 计划与变化。用户执行任务的过程中，总有在项目计划时考虑不周的地方，在有条件的时候应当做到及时调整。我觉得我在SEQ的问题上做的不错啊~~

4. 为了完成任务而完成任务：为任务制定精细而明确的目标应当能够避免这种情况。

5. 对任务目标的定义不清晰：由于没有明确的定义目标，对用户的输入内容没有严格控制，所以不能将完成时间作为评价指标。

PS. 整个准备+测试+报告在晚上或实习的空闲中完成，时间预计在3个工作日左右。

附录：

测试任务卡（用户版）：

测试任务卡（观察者版）：

SUS量表：