得到APP是由罗辑思维团队推出的主打付费知识音频服务的APP,通过订阅专栏、音频课程、拆书解读等方式为网友每天提供有价值感的知识内容,主要模块有「每天听本书」、「订阅专栏」、「大师课」、「精品课」和「电子书」等。
在设计师完成某个页面后,设计师和维护人员通常需要对界面进行可用性的检查和评估。在设计周期初期用户量不多的时候,常用的评估方法主要有启发式评估、可用性测试。
启发式评估即找几个评审员根据一些可用性理论和以往的设计、使用经验来判断产品界面的可用性问题。可用性测试即让用户通过模拟现实生活中的使用情境来使用产品,从而设计师可以观察到用户使用时的操作绩效和表现出的感受和体验。一般而言,用户操作绩效可以通过三个指标来进行评估:操作完成率,完成时间和完成路径。本次对得到APP进行可用性评估采用的是可用性测试的方法。可用性测试除了以上的客观操作指标外,还通过出声思维的方式采集用户认知过程作为补充。
出声思维即让被试在测试的时候言语报告其思考,使得思维过程外显化,能够被直接观察。可用性测试中的出声思维要求被试在完成任务的同时以口头言语的形式报告出任务操作情况,可用性测试专家通过对被试报告内容的分析,可以获知被测系统中存在的问题、哪些部分常为被试所忽视或误解以及被试对使用系统的看法等。
1. 任务设计
在进行任务设计前,首先梳理了得到APP的产品结构,如上图所示。由于时间和技术条件有限,本次只对该APP的核心模块进行测试,如「每天听本书」、「订阅专栏」、「电子书」等,主要测试各模块下的内容搜索/查找、内容的可用性、使用效率和满意度。一共设计了13项任务,具体任务清单不在这里公开。任务设计遵循以下三个原则:
2. 测试流程
整个测试一共包含3个流程,依次是事前访谈、任务测试、事后访谈。我们对整个流程设计了执行指南,执行指南详见附录B。
事前访谈
事前访谈主要包括:1) 取得录像/录音许可,签订信息保密协议;2) 被试信息的采集,主要包括个人基本信息、相关APP的使用习惯、感兴趣的知识领域等,我们会根据相关信息,调整任务的情境;3) 对被试进行事前说明,并进行出声思维的训练。详情见附录B。
任务测试
事前访谈结束后,我们根据事前准备好的执行指南让被试进行任务测试。在整个任务测试过程中,用户被试是主角,我们则是隐藏的观察者,我们的任务是正确传达任务指示,让被试了解任务目的,并在一个任务结束后引导被试进入下一个任务,遵循“不提问、不回答、不注视”的原则,对被试提出的要求只能是“请认真完成任务”,在原则上不给用户任何帮助,对用户的操作不肯定也不否定,确保被试自由发挥,独立完成任务。在所有测试任务结束时,我们让被试填写SUS可用性满意度问卷。
事后访谈
在实际操作中,由于各种各样的原因,被试往往未能发言说出思考的内容,我们并不能获得完整的信息,这些遗漏的信息将在事后访谈进行补充。这里采用回顾法(回顾法 Retrospective Method) 对被试进行事后访谈,访谈的主要内容包括:
3. 测试结果
被试基本信息
从XX大学招募了5名被试,包括3个iOS用户,2个Android用户,4女1男,年龄都在18~24岁之间,可支配收入大概都是2k左右。其中:
任务完成概况
统计了每一个被试的任务完成情况,主要包括1) 是否完成任务设定的目标;2) 每一个任务起点到任务目标的平均跳转次数;3)平均耗时等,具体结果不在这里公开:
问题统计
根据被试的任务完成情况以及事后访谈所反馈的信息,整理了这5个被试在测试过程中遇到的问题(这里不公开),为了保证准确性,我尽量还原了被试对问题的描述。
随后我把被试反馈的问题按性质分成了三类:可用性问题、效率问题、满意度问题。结合这些问题发生的频数,我对这些问题进行了影响度分析 (见下表),问题影响度主要反映了问题的严重程度和待解决的优先级,其中:可用性问题>效率问题>满意度问题;高频率>中等频率>低频率
发生频数 |
可用性问题 |
效率问题 |
满意度问题 |
高 (3-5) |
|
|
暂无 |
中 (2) |
|
|
|
低 (1) |
听书/电子书不能试听/读; |
|
|
注:得到APP的核心需求是提供优质的内容,但这里只关注并解决交互设计相关的问题 (排除战略和技术层面的问题),因此在后续的解决方案中,只筛选出相关问题进行解决。
可用性满意度
整体满意度评价使用了SUS量表 (见下表),内容如下:最后计分得到59.2,根据量表评分经验(60分为临界),由此可见用户对得到APP的可用性不太满意。
SUS可用性满意度量表:
题目及序号 |
1=非常不同意,5=非常同意 |
1.我愿意使用得到 |
2.6 |
2.我发现使用得到很复杂 |
2.2 |
3.我认为使用得到很容易 |
3.0 |
4.我需要专业人员的帮助才能使用得到 |
2.0 |
5.我发现得到的各项功能都能很好的整合在一起 |
3.0 |
6.我认为得到的使用过程中存在大量与我的想法不一致 |
2.8 |
7.我认为大部分人都能很快学会使用得到 |
3.6 |
8.我认为得到使用起来比较麻烦 |
2.4 |
9.使用得到的过程中我很有信心 |
4.0 |
10.使用得到时我需要大量学习 |
2.2 |
4. 问题分析
根据任务完成一览表,可知被试没有达标的任务有1-1、3-1、6-2、7-2、8-1、11-1。这里只对没有完成任务的可能原因进行了分析。
任务1-1
得到APP首页
任务3-1
得到APP电子书模块界面
任务6-2
订阅专栏的课程表
任务7-2/8-1
任务11-1
音频播放界面
其他问题(可以完成但不是很理想):主要有两类,一类是搜索功能的入口位置,另一类是个性化设置。信息搜索过程中,当用户进行几次搜索后没有找到相关信息,会知觉到信息噪声过多,进而寻求筛选/搜索功能。得到APP涉及到很多个内容展示列表,比如电子书列表,专栏目录等等。但这些列表并不是每个都具备搜索功能,可以说不具备内部功能的一致性。个性化设置方面,定时功能也不太符合用户的具体使用习惯。
对相关问题进行分析后,我们对这些问题进行了改进方案的设计,并进行了在测试对改进方案进行检验。
1. 改进方案设计
任务1-1:属于商业战略问题,不在我们解决的范畴。
针对任务3-1:在“电子书”界面内增加分类和搜索,与“听书”和“商城”中的检索方式保持一致。减少信息噪声比率,使用户找书过程中更有信心,效率更高。
改进后的电子书浏览界面
针对6-2:把包含了课程表信息的“发刊词”进行置顶。
改进后的订阅专栏内容界面
针对任务7-2/8-1:a) 增加用户交互反馈——用户点击“❤”后,弹出“已收藏”字样,让用户知道这到底是什么;b) 在“我的”中新增“我的收藏”按钮,图标与爱心符号一致,使信息结构符合用户认知。
改进后的收藏反馈界面和“我的”界面
针对任务11-1中出现的问题,在事后评估时发现,这是与音乐播放器不同的两种设计方式,是否需要修改有待进一步研究才能得知。
2. 再测试
根据改进方案,我使用Axure制作了改版原型 (用浏览器打开可进行操作),让另外的5名被试进行了二次测试,流程和原来一样,但只针对那几个问题任务进行了测试。
测试结果在这里不公开,最后的结论书:任务完成比率都达到了100%,平均跳转次数也有所降低,可用性得到提高 → 解决方案有效。
总结
虽然最终提出了一定程度上可行的改进方案,但在整个可用性测试环节中,这里仍存在以下几个问题:
=>回到目录