短小精练是这本书的好处,我希望它还可以更容易记忆一些,也当作是摘要,所以我记录一遍算是笔记。重点是中间部分,当然,头尾部分也有很多很难得的不容错过的精辟经验。读过三遍,在日后设计页面的时候肯定受用;又好比一剂良药,见效超快,立马就能启发设计用户界面的真谛,也是这本书的又一个好处:被作者举例 + 图文,处理得非常易懂。tanks! steve krug
如何测试你的网站
第九章:一天10美分的可用性测试
让测试简单—-这样你能进行充分的测试
关于测试的几个事实:(1)如果想建立一个优秀的网站,一定要测试:了解它是否运作正常的唯一方法就是测试;最好把测试看做是旅行,一种开阔视野的体验他能提醒你人们有多么不一样,又有多么相像,并且能让你从新的视角看待事物;同时,你也意识到有很多你认为想当然的事情,对别人来说切并非如此。(2)测试一个用户比不测试好一倍:测试总是会有效果,哪怕对错误的用户做一次最糟糕的测试,也会让你看到一些改善网站的重要方面;(3)在项目中,早点测试一位用户好过最后测试50位用户:早点做一次测试—-在你还有机会用上你的测试所得的时候—-总是比以后进行一次复杂的测试更有价值;关于web开发的一些常见看法是,他们很容易开始,也很容易进行修改,但一旦一个网站开始投入使用,要改变它就不那么容易了;所以任何在开始时就有助于防止你犯错误的方法都很划算;(4)人们对招募用户代表的重要性估计过高:如果进行测试的用户接近可能使用网站的用户,那更好,但更重要的是尽早和经常进行测试;(5)测试的关键不是要证明什么或反驳什么,而是了解你的判断力:测试能做的就是给你提供有价值的参考,加上你的经验、专业判断和常识能够让你更容易地在A和B之间做出更明智—-也更自信—-的选择(6)测试是一个迭代的过程:测试不是做一次就够了,而是要遵循开发、测试、修复、再度测试的过程(7)没有什么比现场用户的反应更重要:坚持试验一些细微的变化,看能否再改进它
跳楼大减价的简易可用性测试:可用性测试已经存在很长时间了,它的基本理念很简单:如果你想知道软件、网站或VCR的遥控器是否容易使用,那么在一些人试图使用的时候观察他们,记下他们在哪里遇到问题,然后修改这些问题之后再度测试
应该测试多少用户:steve krug认为每轮测试的理想用户数量应该是3—-4个,前三个用户可能会遇到几乎所有最明显的问题,而且更重要的是多做几轮测试,而不是写下每轮测试里面发现的所有问题,只测试三名用户有助于你很快进行下一轮测试,也便于在同一天完成测试和总结,这样你就能马上利用刚刚得到的这些结果
宽松招募,曲线上升:测试对象是谁并不重要,利用你能够找到的任何人(满足最低要求),然后曲线上升
实际上,我们都是初学者,找到一位专家,你可能发现他也在勉强应付—-只不过再高一点的层次上;设计出的网站只有你的目标群体能使用,这通常并不是一个好主意,在很多情况下,你既要满足专家的要求也要满足新手的要求,如果你的祖母也能使用的话,专家就能使用;专家通常不会介意对初学者来说很清楚的页面,每个人都喜欢简洁,是指真正的简洁,不是把一大堆内容藏在下一级页面的那种简洁
如果你的网站几乎只由某一类用户使用,而且招募这一类用户并不困难,如果你的目标用户是女性,那么务必只测试女性用户就好了;如果你的目标用户群体可以分成几个明显阵营,而且这些阵营有着完全不同的兴趣和需要,那么你至少要从每个阵营里选择用户进行一次测试,然后在其它回合的测试中,你可以选择任意的搭配;如果使用你的网站需要专门的领域知识,那么,你至少要在一个回合的测试中招募具有该领域知识的用户;提供合理的奖励,因为1、这明确表示他们的意见很重要2、人们更加会准时出席,积极参与;邀请要简单;避免对网站(或网站背后的组织结构)进行预先讨论;别不好意思请朋友和邻居帮忙,这样你不必觉得你在强求别人,他们也会学到一些以前不知道的电脑或网络知识
应该由谁来引导测试:几乎所有人都可以引导可用性测试,真正需要的工作只是鼓励测试用户去尝试;选择一个有耐心、冷静、有同理心、善于倾听、天性公正的人
谁应该进行观察:任何想观察的人;可以鼓励任何人—-团队成员、市场和业务拓展部门的人员以及其他涉众来参与
测试什么,什么时候测试:关键是要在web开发的各个阶段及早进行测试(真的没有太早这一说),还有经常测试,甚至在你开始设计网站之前,就应该测试一下同类的网站,可以是实际竞争对手或者和你脑海中在组织方式或功能上风格类似的网站;由于同类网站是“真实”的,你可以进行两种测试:“理解”测试和关键任务测试:
(1)理解测试:就是让测试用户看到网站,然后看他们能否理解这个网站,理解网站的目标、价值主张、组织方法、运营方式等
(2)关键任务测试:让用户完成一些任务,然后观察他们是怎么做的
如果你能想办法观察用户执行一些他们有权参与选择的任务时,会得到更有用的结果,当人们执行苍白、呆板的任务时,不会进行感情投入,也不会尽可能应用个人知识;在你刚开始建立自己的网站时,越早把设计思想展示给用户越好,从你的第一张草图开始,用户更愿意评论一些看起来还没有完成的东西,因为他们知道你还没有投入太多,还有机会进行修改,而且这还不是一个精雕细琢的设计,用户不会被实现细节所吸引,可以把注意力集中在要点和措辞上,这种非正式测试效率很高,也能减少很多潜在问题
立刻回顾测试结果:在每轮测试之后,你应该尽快让开发团队回顾每个人的观察,决定接下来该如何处理,你们要做两件事:
(1)给问题分类—-回顾大家看到的问题,决定哪些问题需要修正
(2)解决问题—-找出修正这些问题的方法,似乎这会是一个艰难的过程;这是一个循环的过程,因此团队不必对完美的解决方案达成一致,你只要确定下一步做什么就可以了。
常见问题:你在测试过程中最有可能遇到的问题
用户不清楚概念:他们就是不理解,他们看着网站或者页面,要么不知道他们说的是什么,要么他们以为自己知道,但是理解有误
他们找不到他们要找的字眼:这通常意味着(1)你用来组织内容的分类不符合用户的习惯(2)分类符合他们的习惯,但没有使用他们期望的名字
内容太多:在这种情况下,你需要(1)减少页面上的整体干扰(2)把他们需要看到的内容设置的更加醒目,让他们从可视层次结构中更加突出
一些问题分类指南:关于决定修正什么内容(不要修正的地方),下面给出一些我的建议:
忽略用户暂时出现错误,又在没有任何帮助的情况下回到原来轨道的问题;抵制添加的冲动,去除某个(或一些)让人混淆的内容,而不是增加另一些干扰;不要太看中人们对新功能的要求,他们只是再告诉你他们的喜好而已;抓住够得着的果实,你的主要目标是寻找重要而不费力的收获;
别把孩子也泼出去:和任何好的设计一样,成功的网页往往要进行巧妙的平衡,重要的是要记住,哪怕一个微小的变化都会带来不小的影响,只要你进行改变,就要仔细思考它将会影响哪些其他的内容,当你把某些部分调整的更为突出的时候,是不是把其它内容的重要性降低了
每个月一个上午,我们就要求这么多:在理想情况下,web团队应该每个月花上一个上午时间进行可用性测试,在一个上午完成测试也大大增加了团队成员调整时间观看至少一部分测试过程的机会,团队将决定你们要修改什么,没有报告,没有无休止的会议