读《妙手回春:网站可用性测试及优化指南》

一些有的没的

豆瓣的读书笔记功能比较松散,设计得更像是摘抄,只能选择单一页码。有时候对某一小节的内容有整体的感想,在填写页码时就会纠结不已。长评也不适用于想法不连贯的我。

先总结一下前两天看的《用户体验要素》。这本书的副标题是「以用户为中心的产品设计」,所以要收回对把这本书列入产品经理必读书单的人的吐槽。只能说有缘再细看。收获最大的是看书要看副标题从不同的视角(功能、内容)看产品,以及对提出「正确问题」的强调。

再谈一下昨天上课听到的,关于练习和重复的小故事:同学们问机器学习大佬吴恩达老师,如何改进自己的算法。大佬说,先不要急着改进算法,把数据集扩大再多跑几次试试看。(大意)
联想到自己一开始怎么也意识不到用户的重要性,看人物角色也只注意到「虚构」二字。之前就学到的用户故事,在课上用得也未必很好。可能还是输入不够,没有掌握重点,而非学习方法不对。作为 slow learner ,慢慢来吧。

这本书

分为三部分:找出问题、解决问题、成功之路。只列出对我比较有启发的部分。

可用性测试试举例

在正文开始前,作者给出了一个他自己做可用性测试的例子(在书中称作 DIY 可用性测试),并要求尝试在看完测试后提出三个用户遇上的可用性问题。我跟着做了,结果发现,自己在提出问题的同时也提出了解决办法,并且尝试用答案去描述问题。

比如,在测试中,用户提出想要能计算总价。我将这个问题描述为「车费的计算显示,应该显示总和」,心里同时思考了一下添加计算器、选项之类的。我没有注意到这位用户在此之前已经口算出了结果,在整个过程中没有感到困惑或者有挫败感。或许其他用户会因为难以计数而不爽,但针对这个用户,「总和」问题不是应该被优先考虑的。

在看了作者提出的可用性问题后,我将其总结为:
<用户[因为遇到了某种情况]而[感到【负面情感比如沮丧、困惑】]>
要抓住用户情绪上的变化,意识到是系统的哪部分造成的。

测试人数

这本书反复告诉读者可用性测试很简单,而且越早进行越好。这里采用的是缩减版测试,一次只测 3 个人(毕竟每一本书都要提一提 5 个人和 85% ,我也记住了✌️)。如果频率可以保证的话,3 个人也没问题(?)。

测试现有的 & 其他人的网站

记住了。这可能是现在没有什么项目的我的最好入门方法。毕竟要去试一试才能知道。一般前者是为了重新设计自己的网站,后者是为了学习经验教训。

宽松招募

目标受众、有代表性的用户、实际用户,这些当然是用户测试的不二人选。但是有时候出于成本的考虑,未必要生搬硬套(当然还是首要考虑他们)。对我来说,就是如果暂时克服不了寻找「真实用户」的恐惧,也可以寻找身边的人。这是一种偷懒的行为,但是如果不先这样想,可能就无法开始了。

治疗师

有趣,作者把用户测试的主持人比作心理治疗师。要让参与者表达、要保持中立、要有一套重复的说辞、要有道德感。「中立」这一点在我有限的测试经历来说是比较难的,除了说出一些看起来具有指向性的话,甚至有时候忍不住也开始生气了。

在这里,作者给出了一些参考的话语,不要使用带有褒贬的词语,在面对询问时,反问对方「一般是怎么做的」、「您认为呢」。积极的反馈只能是在参与者担心自己帮不到测试人员时(即使真的帮不到,也要积极地反馈)。

录像问题

上周刚问过导师关于录像的事情,我担心录像会破坏被观察者的「平常心」,但是忘了录像可以作为日后起了争执的参照。在这里,录像指的是录制屏幕,同时录入声音。作者不建议对着参与者的脸进行录像,毕竟听声音、所说的话也是能知道情绪的。似乎这也更容易让人接受。

眼见为实

别忘了这一点。在这本书中不仅有测试主持人,还设立了观察员这一角色。设置观察员的目的除了可以帮忙记录、参与测试讨论、得出更好的可用性问题进行修复外,更重要的是,改变观察员对可用性测试的看法,让他们了解用户的行为。不仅设计人员不是用户,开发人员、产品经理也不应该是用户。而参与测试能让大家对这一点有更深的体会。

越少越好

目前看过的书中提及到建造、修复都是在强调未必要完美,应当学会做减法。

放弃大规模的重新设计,而拥抱分阶段的连续重新设计。

后续阅读

Cost-Justifying Usability 书中的例子可以用于说服管理层重视可用性测试(或多或少)。


参照这本书的第一部分就能很好地实施 DIY 可用性测试了。即使在移动应用大行其道的今天,书中针对 Web 的可用性测试也有很好的实用性。可以定下一个小目标,在 11 月 30 日前测试一下米课(算是 2% 的我参与制作的网站)。