可用性测试 - UCD大社区

简单快速的可用性测试

++ — 2011-01-27 21:53:18

可用性测试是改善产品的最佳方式之一，这一点，在内部已经是不争的共识。只是由于用研人手总是不足，所以为了能让各个部门的同事能更快速地展开一些研究和测试的工作，我们陆续整理了一些简单的文档和教程，并计划通过集中的培训来普及一些用户体验的方法。因此，要特别强调的是，本文所介绍的测试方法是简单，非正式的，小样本的，以发现严重问题为目的的。如果要深入了解测试的原理，方法，请参阅以下几本书：
Handbook of usability testing

Usability testing and research

Measuring the user experience

在开始之前，我要强调，测试要尽早开始，并且只需要简单的设备就可以进行。

什么是可用性测试？

其实可用性测试并不复杂，简单概括就是观察用户使用产品。如果稍微扩展一些，我们可以将其解释为：通过观察有代表性的用户，完成产品的典型任务，而界定出可用性问题并解决这些问题。而目的呢，则是为了让产品用起来更容易。

如何设计和进行可用性测试

根据上面的定义，我们在如何设计和进行可用性测试的部分将主要回答以下几个问题：

l 如何设计任务

l 如何找用户

l 如何进行测试

l 如何分析找到可用性问题

如何设计测试任务；

设计测试任务是可用性测试前期计划的核心，我们建议最好在任务设计之后再确定用户招募的标准，因为测试中涉及什么样的任务和你要描述的用户操作经验直接相关。确定了前者，后者也就更明确了。

在设计任务前，需要反复的问自己：

“我设计的测试任务是真的反应了用户的实际目标么（而并不是我认为用户想要做的事）？”

在问了三次以上上面的问题，并且确定可以肯定的回答自己之后，就可以开始设计任务了。

通常的方法是：

a) 先列出一个任务清单，用简单的短句来描述测试中涉及的任务——主要是给内部人员看的。由于是快速测试，因此，任务不宜过多，必须是重要的，核心的，你觉得可能会有问题的任务；

b) 在筛选完任务清单后，将任务变成场景——场景就是你要读给用户听，或者要给用户看的内容。因此必须要包含用户的目标和动机——因为对用户来说，你的功能并不重要，重要的是他们的目的以及他们完成目的的过程。这时候，你可以再问一次自己上面的问题。

c) 确定操作任务需要的条件：比如是不是需要一个新的账号，是不是需要准备好必要的文件等等；

d) 预测试：预测试主要是为了发现任务设计的问题，可以找公司内的同事，利用午休时间快速完成

如何找用户；

在利用各种资源找用户之前，我们要首先明确，我们要找什么样的用户来？

找什么样的人来？

以前，在测试计划阶段，我们和产品以及设计的同事沟通，他们对用户的描述，往往是：25~30岁，上班族之类。但事实上，我们在测试中最关注的是用户的操作行为，因此，在确定用户甄别的标准时，们最应该关注的是产品使用经验和使用行为，而不是人口统计学特征。关于这一内容更详细的解释，可以参看这篇文章。http://www.uie.com/events/uiconf/2008/articles/recruiting_participants/

找几个人来?

一谈到要找几个人来测试，就不得不请出Nielsen的这张经典图表。虽然学术界对于5个用户究竟是否足够有很多争论。不过，从我们的实践角度来看，只要在第一个阶段界定的好，找到合适的人，那么，5个用户真的已经可以发现明显的可用性问题了，当然，这里要再一次强调，快速测试的目的是为了发现严重的问题而不是全部的问题。

此外，我们发现，在平时的测试中，在观察前三个用户测试时，单面镜后的产品和设计人员往往精力集中，下笔如飞，但到了5个之后，新的信息越来越少，大家不是发呆，就是干脆睡了（像图中的兔子一样）。所以，从工作状态的角度讲，5个以内的测试用户，能够保证大家精力集中，并且愿意去观察和倾听。

如何找用户？

在确定了甄别的标准和用户的数目之后，找用户就成了头痛的问题。在这里，我的建议就是，由于是快速测试，就尝试用尽一切办法，无论是找同事（同部门的同事就不要找了），朋友，朋友的朋友，网站论坛发广告等等，只要快，并且在招募时，坚持要求，大家是可以“不择手段”的。当然了，如果这时候能有一份平时就在维护的用户列表就再好不过了。

如何进行测试

因为是快速的测试，主持人从用研人员变成了产品和设计人员自己。因此，在这里要强调的是，在测试中不要试图教用户如何使用产品，也不要试图向用户推销你的产品。

主持人做什么

记录人员做什么

无论是有条件实时观察（有专门的体验室或者工具），或者需要回看录像来观察，记录时都要注意，记录的重点不是用户说了什么，而是用户如何使用。记住，在测试中，做了什么比说了什么更重要。当然，由于是为了发现严重问题而进行的测试，并且严重的问题总是显而易见，因此，可以同时记录问题，但不要急于讨论问题的解决方案。因为马上想到的方案或者用户提出的方案并不一定是最好的，这个工作可以留待可以安静思考或者大家讨论时进行

如何分析找到可用性问题

在完成测试后，需要主持人和观察人员趁着记忆犹新的时候快速地将有用的信息整理出来，可以采用便利贴，也可以专门空出一块白板或者建立一个文档。总之把用户相关的操作，提出的问题，和我们自己发现的问题迅速地写出来。但，不要快速下结论。

在所有测试完成后，整理已经有的便利贴，列表等，然后找出那些最严重的问题，快速地修复它们。在这一环节，重点是一再地明确，究竟那些问题才是最重要的，并且可以马上修复的。这样，测试的结果才是可执行的，而不是仅仅变成了一张存档的问题列表而已。

相关话题：可用性测试源地址：http://uedc.163.com/4151.html

准备用户测试的6个步骤

jameguilin — 2010-11-24 22:51:36

准备用户测试需要令人惊叹的准备工作。这里我列出来6个关键的步骤，它们是准备就绪的必经阶段。

1. 创建用户测试计划

识别你的网站需要评估的方面，建立一个包括大约6个任务的列表。每一个任务包括以下内容：

情景 - 这是参试者将阅读的说明。它需要包括任务的目标和想象的环境，一些能够让情景觉得真实的东西。例如：“下周是你朋友的生日，你打算为他买一份生日礼物。你知道他喜欢动作片。请为他购买最新的蝙蝠侠DVD。”
停止条件 - 网站中参试者到达即代表完成任务的页面或程度。这能够帮助你客观的决定一个任务是否已经被完成。
正确的途径 - 记录下参试者达到目标所应采取的正确的途径是非常有用的。如果主持人在测试当天生病了，他的同事就可以帮助进行测试，即使他对于产品网站不很熟悉。
可能产生的问题 - 一个页面上可能有一打需要评估的要点，进行测试时记住所有这些要点有可能会很困难。因此，对于每一个任务，可以总结一个可能产生的问题的列表用于测试过程中参考。

最后，把测试计划与客户，项目相关利益人或者项目赞助人分享，检查计划是否包括了他们想要达到的每一个目的。

2. 招募参试者

招募是要做对的最重要的事情之一。如果参试者不能够代表目标用户，那么测试的结果就不可信。如果他们在测试时迟到，或者根本就没来，就需要重新安排测试计划。

为你希望参与用户测试的人员建立一个招募人物概要。你的招募者需要这个来保证他们邀请到正确的人来参与。

确保参试者了解到测试地点的准确并易于理解的路线图。给他们一个电话号码，好让他们路上耽搁的时候可以通知别人。最后，测试前一天给他们打个电话，确保他们知道测试的准确时间和到测试地点的路线。

3. 检查被测网站

对你要测试的网站或原型尽可能的熟悉。越熟悉测试就会越顺利。

如果时间允许的话，将测试安排在网站预定完成的日子之后3，4天。很多时候，设计和开发会拖延，而对将要进行的可用性测试造成间接影响。

进行可用性测试的时候，暂停被测网站的一切开发工作。你不会想被测网站在测试进行的时候产生变化，尤其是，由于技术原因突然出现问题。尽量在你将要使用的机器上保留一份本地的版本，以备万一有什么事情出现问题，比如，网络连接。

4. 安排测试设备

提前足够的时间预订测试设备，以保证测试时候所有的设备都是空闲的。提前一天搭设好测试环境。

尽量把测试安排在客户或者项目相关人士可以通过单面镜子观察测试的实验室。人们觉得观察测试是一件有趣的事情，并且可以帮助他们建立对用户的认同感。这是让人们认同在可用性上投资的一个好机会。同时，尽量将测试安排在可以录像的地方，这样以后可以参考。

如果你没有合适的实验室，可以从进行可用性测试和市场研究的公司租用。Webcredible就是租用伦敦的实验室。

5. 准备注意事项列表

每个测试开始的时候，都有很多要给被试者解释的事项，通常很容易遗忘其中的一两件。例如，录像，希望被试者出声思考，你并不是评估他们的表现等等。准备一个注意事项列表写出要记住的事情，每次测试开始前可以参考。

在开始前还有其它一些也会是你想做的事，例如开始/停止录像，删除浏览器历史（因此其他人不会看到以前的被视者访问过的链接）。把这些事情也写到注意事项列表中。

6. 进行测试演习

与同事进行一次演习。在真正的将要进行测试的地点进行，检查每件事情是不是都准备好了，都工作正常。演习所有测试计划上的内容，保证所准备的测试情景别人能看得懂，并且可以在规定时间内完成测试（通常是1小时）

结论

进行用户测试的时候你希望任何事情都不会出错，客户和项目相关人对你的工作满意。这6个步骤能够帮助你准备可用性测试，保证事情的顺利进行。

这篇文章由Abid Warsi，用户体验咨询公司, Webcredible的高级咨询顾问所写。Abid热衷于提高网站的用户体验，负责各类不同用户体验设计项目，包括眼动追踪和信息架构。

阅读本文英文版（翻译：李鱼）文章来自：UI花园

相关话题：可用性测试源地址：http://uiclub.blogbus.com/logs/85161579.html

Desktop端UI测试概要

小气的神 — 2010-10-03 11:33:39

最近在做一些测试，为产品的顺利公测做部分支持。

以下为Desktop端的测试。

第一部分： Windows程序UI设计初步

1.背景介绍

UI就是用户界面( user interface ) ,就是人和工具之间的界面。在人和机器的互动过程中，必须经由界面。这个界面实际上是体现在我们生活中的每一个环节的，例如我们开车时候方向盘和仪表盘就是这个界面，看电视的时候遥控器和屏幕就是这个界面，用电脑的时候键盘和显示器就是这个界面，到了使用软件的时候，用户能够通过视觉看到的都是界面。这个界面包括硬件和软件。我们这里讲的UI设计特指Windows操作系统下的软件界面。

用户界面设计有三个基本的原则：a. 置界面于用户的控制之下；b. 减少用户的负担；c. 保持界面的一致性。从程序设计开发的角度来看，界面设计可以分为结构设计、交互设计、视觉设计三个部分。

结构设计也称概念设计（Conceptual Design），是界面设计的骨架,通过对用户研究和任务分析，制定出产品的整体架构。基于纸质的的低保真原型（Paper Prototype）可提供用户测试并进行完善。在结构设计中，目录体系的逻辑分类和语词定义是用户易于理解和操作的重要前提。

交互设计是程序的神经，使用户与软件处理部分进行沟通，最终目的是使产品让用户能简单使用。任何产品功能的实现都是通过人和机器的交互来完成的。因此，人的因素应作为设计的核心被体现出来。

1)有清楚的错误提示。错误操作后，系统提供有针对性的提示。

2)让用户控制界面。“下一步”、“完成”，面对不同层次提供多种选择，给不同层次的用户提供多种可能性。

3)允许兼用鼠标和键盘。同一种功能，同时可以用鼠标和键盘。提供多种可能性。

4)允许工作中断。例如用手机写新短信的时候，收到短信或电话，完成后回来仍能够找到刚才正写的新短信。

5)使用用户的语言，而非技术的语言。

6)提供快速反馈。给用户心理上的暗示，避免用户焦急。

7)方便退出,如手机的退出，是按一个键完全退出，还是一层一层的退出。提供两种可能性。

8)导航功能。随时转移功能，很容易从一个功能跳到另外一个功能。

视觉设计是在结构设计的基础上，参照目标群体的心理模型和任务达成的,是程序的脸面，要达到使用户愉悦的目的，包括色彩、字体、页面等。视觉设计的原则如下：

1)界面清晰明了。允许用户定制界面。

2)减少短期记忆的负担。让计算机帮助记忆，例：User Name,、Password、IE进入界面地址可以让机器记住。

3) 依赖认知而非记忆。如打印图标的记忆、下拉菜单列表中的选择。

4)提供视觉线索。图形符号的视觉的刺激；GUI（图形界面设计）：Where, What, Next Step。

5)提供默认（default）、撤销（undo）、恢复（redo）的功能

6)提供界面的快捷方式。

7)尽量使用真实世界的比喻。如：电话、打印机的图标设计，尊重用户以往的使用经验。

8)完善视觉的清晰度。条理清晰；图片、文字的布局和隐喻不要让用户去猜。

9)界面的协调一致。如手机界面按钮排放，左键肯定；右键否定；或按内容摆放。

10)同样功能用同样的图形。

11)色彩与内容。整体软件不超过5个色系，尽量少用红色、绿色。近似的颜色表示近似的意思。

2. UI设计的一些原则。

对于Windows用户来说，用户认识到的就是所看到的。必须看到的现实就是：界面是面向用户的，用户需要的是开发者开发的应用软件满足其需求，并且易于使用。好的用户界面使得用户不用阅读用户手册或接受培训就能使用应用软件。

2.1 交互设计的一些原则：
2.1.1有清楚的，针对性的操作提示。使用讯息和标签措辞要适当。屏幕上显示的文本是用户主要的信息源。文本措辞直接影响用户的理解。要使用用户的语言，而非技术的语言。讯息措辞要积极，显示用户处于控制之中，并提示如何正确使用软件。如， “你输入了错误信息”还是“帐号应为8位数”会给用户不同的体验。此外，讯息措辞要一致，在屏幕上显示的位置要一致。
2.1.2让用户控制界面。”下一步”、”完成”，面对不同层次提供多种选择，给不同层次的用户提供多种可能性。让用户知道自己当前的位置，使其做出下一步行动的决定。允许工作中断，方便退出。整个交互过程提供快速反馈。给用户心理上的暗示，避免用户焦急。
2.1.3允许兼用鼠标和键盘等多种输入。同一种功能，提供多种方式。
2.1.4使用非破坏性的缺省按钮。通常每个屏幕定义一个缺省按钮，如果用户按了回车键调用此按钮。问题是有时用户会意外敲击回车键，结果激活了缺省按钮。缺省按钮决不能有潜在的破坏性，如删除或保存(也许用户根本不想保存)。最好的方法是使用组合键来设置按钮，更彻底的方法是去掉默认按钮，这违背了同时支持多种输入的原则，但是在特定的场合是可以考虑的。

2.1.5在操作焦点处打开窗口。当用户双击一个对象显示其编辑／详情屏幕，用户的注意力亦集中于此。因而在此处而不是其它地方打开窗口才有意义。
2.1.6弹出菜单不应是唯一的功能来源，主要功能菜单不应该被隐藏起来。适当使用上下文相关菜单。根据情况提供鼠标右键的这种菜单，缺少过滥都是不科学的。

2.1.7提供标准的常用功能 ,提供界面的快捷方式。如，常用的按钮、菜单应该有和其它同类软件相同的快捷键，一般打开放在文件菜单下。如果一个菜单项，按下去会弹出一个窗口，那么这个菜单项的文字末尾应该有一个省略号来暗示用户，例如 “打开…”

2.1.8要考虑各种层次的用户的操作水平的不均衡。

2.2视觉设计的一些原则：

2.2.1一致性。保证界面的协调一致。对于列表框来说，如果双击其中的项，使得某些事件发生，那么双击任何其它列表框中的项，都应该有同样的事件发生。所有窗口按钮的位置要一致，标签和讯息的措辞要一致，颜色方案要一致。

2.2.2 界面布局很重要。人们是自左而右，从上而下阅读，基于人们的习惯，屏幕的组织也应当是自左而右，从上而下。界面清晰明了，屏幕不能拥挤，拥挤的屏幕让人难以使用。实验结果(Mayhew，1992年)显示屏幕总体盖度不应超过40％，而分组中屏幕盖度不应超过62％。如果要表达的信息比较多，最好分屏显示。区域排列。当屏幕有多个编辑区域，要以视觉效果和效率来组织这些区域。区域左对齐是最好的方法。与之相应的标签则应右对齐，置于编辑区域旁。这是屏幕上组织区域的一个整洁有效的方式。数据对齐要适当。对一列列的数据，通常的作法是整浮点数右对齐，字符串左对齐。有效组合。逻辑上关联的项目在屏幕上应当加以组合，以显示其关联性。反之，任何相互之间毫不相关的项目应当分隔开。在项目集合间用间隔对其进行分组／或用方框也同样可做到这一点。

2.2.3界面间切换很重要。如果从一个屏幕转换到另一屏幕很困难，用户会很快灰心并放弃。当屏幕流程与用户想完成的工作流程相符，此软件对用户才有意义。由于不同用户工作方式不同，应用软件需要有足够的灵活以支持他们不同的方式。尽可能的提供给用户一个相对容易、自由的操作界面；
2.2.4 提供视觉线索。图形符号的视觉的刺激远远大于文字。尽量使用真实世界的比喻。如：电话、打印机的图标设计，同样功能用同样的图形。加图标的目的是为了使它更醒目，更突出。但是如果不加区分的全加、滥加，反而突出不了重点，都是重点就等于都不是重点。加图标要保持风格一致，不要一个按钮的图标是XP风格的真彩图标，下一个又成了Win95风格的16色图标，到下一个又成了Mac风格的唯美图标，这样一个大杂烩显得极不专业，降低用户的信赖度。
2.2.5色彩与内容。整体软件不超过5个色系，尽量少用红色、绿色。近似的颜色表示近似的意思。颜色使用要适当,得一致，以使整个软件有同样的观感。此外，在不同平台上，色彩的表现不尽人意.在一个系统上看上去很好，在另一个系统上常常看上去很糟,需要考虑软件的运行环境而不是开发环境下闭门造车。颜色的使用要遵循对比原则。确保屏幕的可读性，最好的方法是遵循对比原则：在浅色背景上使用深色文字，在深色背景上使用浅色文字。蓝色文字以白色为背景很容易读，但以红色为背景很难辨认。问题出在蓝色与红色之间没有足够反差，而蓝色与白色之间则反差很大。字体使用要适当。要用那些可读性好的字体，如Times Roman。节俭、有效地使用两、三种字体的屏幕看上去远胜于使用五、六种字体的屏幕。此外，字体的使用要一致，要记住每次改变了字体的大小、风格(粗体、斜体、下划线，……)、样式或颜色，都是在使用不同的字体，就表示了他们的不完全一致。显示一定要考虑用户所使用的输入／输出设备，如触摸设备相对要大些。

2.2.6豪华界面，不适合所有的软件。华而不实的感觉往往来自界面。一般来讲，游戏类、播放器类，需要美丽的界面。

3．用户的操作

对于用户来说，操作越简单越好，程序的使用思路越清晰越好。下面结合环境简单说明一下常用控件该如何合理使用。

3.1对于较长时间的运算：

建议使用进度条（progress bar）比如要进行数据库操作，需要时间长的情况。使用进度条可以让用户有个等待的时间，否则用户不知道你的程序在干什么，用户对于不明不白花费的时间一般容易恼火。设计的时候，对自己的操作运算时间进行估算，确定是否需要使用。如果只有5秒钟，用户一般是可以忍受的，加入进度条反而会产生画蛇添足的效果。

在使用进度条的同时，可以配合使用状态栏。StatusBar经常被放置在窗体的下面，建议使用dock。可以在状态栏中提供多个面板（pane）来提供不同的信息。状态栏中，通常都会有一个面板来提示程序运行的信息，例如显示进度，时间等。需要扩展的话，需要owerndrawn属性支持。可以添加按钮等，如取消。一般，在长时间的后台运算开始时，在状态栏中设置开始的状态信息，在计算结束之后，清除状态信息或将状态信息设置为停止状态，在后台运行期间通过状态栏来显示必要的错误信息，提示用户当前的状态。比如，进行一个计算时，开始显示：正在计算，请耐心等待。当运算结束时显示：可以结束，正确退出。

等待指针的使用，在进行计算的时候，尤其在很难计算出这些操作的进度的情况下，设置前台鼠标指针为wait cursor是对用户一个很好的提示。如果有些操作必须是阻塞的，这时需要使用等待指针（wait cursor）也是对用户很好的交代。同样，光标的形状是非常灵活的，合理的使用能够给用户恰当的提示。

总之，使用上面的控件，能通过可视化的方式通知用户有一些程序正在执行过程中，可能需要等待一定的时间。

在程序中合理使用try…finally语句可以达到很好的效果。保证无论遇到什么情况，是正常也还，是异常也好，反正最后都会执行到finally。

3.2操作开始之后，在适当的时候提供必要的程序开关。

用户应当能够通过界面操作取消或终止较长时间的运算。不管你在做什么，都要给用户一个机会，因为用户是程序的使用着。当然，不能让用户，任何时间都可以插手程序的操作，比方，一个数据保存的界面，保存，关闭，取消三个按钮，当正在保存数据的时候，如果强行关闭的话，会导致数据的异常，在这种情况下就需要适当的启用，禁用控件。对于该界面来说，“保存”点击后，禁用“关闭按钮”。在保存处理完毕后，再启用“保存按钮”。

3.3适时合理禁用一些菜单

通过可视化的方式提示用户在运行某些程序的时候某些功能是被禁用的，程序结束后，重新启用一些被禁止的菜单和控件，并通过适当的方式提示用户操作已完成。同时，适当的启用禁用菜单可以使用户更清晰的理解应用程序的工作流程，理解应用程序执行的逻辑。比如用户，一般先要看你界面上什么功能可以使用，什么需要达到一定的前提才能使用。在执行某功能的时候，通过禁用启用，可以知道这个不能执行。当执行完毕后，用户发现，哦，那个按钮亮了，可以执行了。

3.4验证用户的输入，使用validation control。

避免因为用户的失误，导致程序的失败，意外。使用界面友好的MessageBox，注意要在提示对话框中使用适当的按钮和图标，它的重载比较多，根据具体的情况选择不同的图标和按钮。比方说，如果用户强行退出，可以弹出警告，这个时候就应该告诫用户可能产生的不良后果。

3.6使用适当的控件

使用TreeView控件来显示有层次的数据，使用ListView来显示一组具有多个列的数据，使用DataGrid控件可以让用户改变每一个单元格中的数据，使用TabControl可以将窗体中的控件按照使用逻辑进行分类，根据具体的需要开发复合控件，扩展控件，自定义控件。

3.7 合理使用Splitters Docking与Anchoring属性

当窗体放大时，你的窗体上的各种元素是否能够按照比例放大，并且填充区域呢。

用Splitter控件来分离用户区域，使用Dock属性的Fill选项使控件能够填充屏幕的一部分，设置Anchor可以在窗口大小变化时，保证窗体中的控件与窗体的相对位置不发生变化。通过设置

3.8不同分辨率下显示效果的自动调整。

考虑到用户的使用环境，程序在高分辨率下，字体，图片，显示需要随着分辨率自动调整，以满足用户的视觉效果。

3.9通过使用Common Dialog可以让用户通过熟悉的界面来实行标准的操作

ColorDialog，FontDialog，OpenFileDialog等等

3.10对于较长时间的操作，不要阻塞主线程，也就是UI线程

如果时间长的话，建议使用多线程。可以使用ThreadPool.QueueUserWorkItem()来进行异步调用。在该类中，管理线程，QueueUserWorkItem：将方法变成代理，将代理交给QueueUserWorkItem，如果没有其他线程，则立即计算，否则需要等待，给用户提供取消/停止的功能。从其它线程中更新用户界面中的控件，需要使用BeginInvoke和delegate。Hook，当前线程中调用的方法，获得另外线程中的方法，在另外的线程中操作。不是用来创建线程，只是让线程去执行想执行的方法。代理函数指针的封装，自己作为对象在程序中传递，实现callback机制。在NF2中，使用辅助线程Backgroundworker

3.11关闭确认原则。关闭需要激活原则，使权限不够的用户不能关闭程序。对实时软件尤其重要。

第二部分：UI测试要点

一． UI测试概念

UI测试指测试用户界面的风格是否满足客户要求，文字是否正确，页面美工是否好看，文字，图片组合是否完美，背景是否美观，操作是否友好等等。

用户界面 (UI) 测试用于核实用户与软件之间的交互。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外，UI 测试还可确保 UI 中的对象按照预期的方式运行，并符合公司或行业的标准。包括用户友好性，人性化，易操作性测试。UI测试比较主观，与测试人员的喜好有关，比如：页面基调颜色刺眼；用户登入页面比较难于找到，文字中出现错别字，页面图片范围太广等都属于UI测试中的缺陷，但是这些缺陷都不太严重。

二． UI测试要点

1. 按功能将界面划分局域块，完成相同或相近功能的按钮框起来, 并要有功能说明

2. 界面要支持按Tab键的自动切换功能;Tab键切换是否正确; Tab键的顺序与控件排列顺序要一直，目前流行总体从上到下，同时行间从左到右的方式;

3. 默认按钮要支持Enter及选操作，即按Enter后自动执行默认按钮对应操作

4. 菜单点击,窗口初始化

5. 父窗体或主窗体的中心位置应该在对角线焦点附近;子窗体位置应该在主窗体的左上角或正中;多个子窗体弹出时应该依次向右下方偏移，以显示窗体出标题为宜

6. 在各种分辨率下是否显示正常

7. 前景与背景色搭配合理协调，反差不宜太大，最好少用深色，如大红、大绿等。常用色考虑使用Windows界面色调。

8. 如果窗体支持最小化和最大化或放大时，窗体上的控件也要随着窗体而缩放；对于含有按钮的界面一般不应该支持缩放，即右上角只有关闭功能。

9. 窗体能否多次正确关闭，打开

10. 滚动条是否能拖动，并可通过键盘自动拖动

11. 与正在进行的操作无关的按钮应该加以屏蔽(Windows中用灰色显示，没法使用该按钮)。

12. 对可能造成数据无法恢复的操作必须提供确认信息,给用户放弃选择的机会,如删除确认提示,退出前确认是否保存

13. 可写控件的数据类型及长度,尽量在前台进行控制

14. 非法的输入或操作应有足够的提示说明, 让用户明白错误出处，避免形成无限期的等待,提示、警告、或错误说明应该清楚、明了、恰当;提示顺序按Tab顺序

15. 对一些特殊符号的输入、与系统使用的符号相冲突的字符等进行判断并阻止用户输入该字符, 特殊字符常有；;’”><,｀‘：“［”｛、\|｝］+=)-(_*&&^%$#@!,.。?/还有空格

16. 在读入用户所输入的信息时，根据需要选择是否去掉前后空格。

三．一般客户端测试逻辑划分

１. 标题栏

a、标题文字描述的正确性

b、标题栏中（最大化、最小化、关闭）按钮，根据窗口的特性，如没有最大化或者最小化状态的窗口，应该不显示最大化和最小化按钮，或者把按钮Disable状态显示。

２. 文字

（1）文字描述的准确性：

a、检查文字的描述和所对应的功能是否一致；

b、检查错别字。

（2）文字用语的一致性：

（菜单、界面按钮或者Label等、ToolTip、窗口标题）比如选项设置，在主界面的有按钮可以进入选项设置对话框，或者菜单中有菜单项可进入选项设置对话框中，那么，按钮、菜单、对话框的标题都应该统一用词，如用“选项”或者“设置”，而不能又用“选项”，又用“设置”，或者还有其他的的用词。

（3）为了全面的检查所有的文字，应该检查程序中的所有文字资源，因为一些对话框可能比较难在黑盒测试的时候能全部都出现过。

３. 控件

（1）控件对齐：

a、并排关系的控件间应该左对齐，同行的控件应该横向对齐。

b、有所属关系的控件应该缩进。

（2）控件状态：

a、不能操作的的控件的状态应该为Disable，这样界面也起到引导用户使用操作的效果。

b、有依赖关系的控件，比如（几个选项供选择（CheckBox或者RadioBox），每个选项下面都有独立的设置（其他的控件：Edit、 ComboBox、CheckBox等），那么当所属的选项没有选中时，下面的控件应该是Disable的，相反为Enable。

（3）控件的TabOrder

控件的TabOrder应该依次从上到下、从左到右的顺序，界面中默认的TabOrder应该落在界面上的第一个Enable状态的控件上面。

（4）控件的右键菜单支持

允许输入的控件都应该支持右键菜单，方便习惯使用右键菜单的用户复制、剪切、粘贴、全选等操作。

（5）控件的操作方式

a、单行文本的Edit输入框中，对回车符的支持：回车默认操作是本窗口中的“确定”按钮的功能。

b、在可操作的列表控件（List、ListView）中，鼠标双击的操作、键盘操作都应该有对应的默认操作。比如下面的图中，双击列表中某一项，默认操作就是Modify按钮的操作；双击列表中的空白处，默认操作应该是Add按钮的操作；选中列表中的项的情况下，按下Delete键，默认操作应该是 Remove按钮的操作。

（6）Edit控件对输入的有效性判断

a、类型判断：整型、浮点型的数据输入框中，不允许输入非表示数据的其他字符串（如：abcd或者其他字符等）；

b、大小判断：数据类型的数据如有大小范围限制的，要对输入的大小进行判断（如：表示月份的输入框中，只能允许输入1－12的数字。

c、长度判断：如果是程序处理的字符串有长度限制，但是输入框中没有对输入的数据长度进行限制，将有可能会造成程序错误，或者处理后的结果和输入的不相符合。

d、正确性判断：表示路径的或者文件名全路径的输入框，要对输入的路径是否为有效的路径进行判断，如：输入aaaa或者 C:\\//等为不正确的输入。

４. 图片

图片显示的篇幅不要太大。

５. 界面整体的颜色搭配

６. 窗口在任务栏上的系统菜单

每个应用程序，如窗口在系统任务栏上有缩小图标的，都应该有系统右键菜单的支持（还原、最大化、最小化等），要测试右键菜单中各个项的Enable和Disable状态的正确性以及功能的正确性。

7. 提示对话框测试

1、文字描述的正确性

2、图标显示的正确性：

a、程序错误、操作错误、禁止操作等的提示：MB_ICONHAND, MB_ICONSTOP，MB_ICONERROR

b、询问的提示：MB_ICONQUESTION

c、感叹、警告的提示：MB_ICONEXCLAMATION ，MB_ICONWARNING

d、普通信息的提示：MB_ICONASTERISK，MB_ICONINFORMATION

第三部分： UE测试概要

UE（User Experience 用户体验）:指的是软件应用和审美价值，是以用户至上的观点作为基石的。主要由以下四种因素构成：
1、印象（感官冲击）
2、功能性
3、使用性
4、内容
这些因素相互关联，不可分割，共同形成正确的用户体验。这些因素也是一个软件成功必不可少的主要因素。其中“印象”也可以归结成这个软件塑造的一个“品牌”效应。

用户体验是一种纯主观的在用户使用一个产品（服务）的过程中建立起来的心理感受。因为它是纯主观的，就带有一定的不确定因素。个体差异也决定了每个用户的真实体验是无法通过其他途径来完全模拟或再现的。但是对于一个界定明确的用户群体来讲，其用户体验的共性是能够经由良好设计的实验来认识到。

用户体验主要是来自用户和人机界面的交互过程。在早期的软件设计过程中，人机界面被看做仅仅是一层包裹于功能核心之外的“包装”而没有得到足够的重视。其结果就是对人机界面的开发是独立于功能核心的开发，而且往往是在整个开发过程的尾声部分才开始的。这种方式极大地限制了对人机交互的设计，其结果带有很大的风险性。因为在最后阶段再修改功能核心的设计代价巨大，牺牲人机交互界面便是唯一的出路。这种带有猜测性和赌博性的开发几乎是难以获得令人满意的用户体验。至于客户服务，从广义上说也是用户体验的一部分，因为它是同产品自身的设计分不开的。客户服务更多的是对人员素质的要求，而已经难以改变已经完成并投入市场的产品了。但是一个好的设计可以减少用户对客户服务的需要，从而减少公司在客户服务方面的投入，也降低由于客户服务质量引发用户流失的机率。

现在流行的设计过程注重以用户为中心。用户体验的概念从开发的最早期就开始进入整个流程，并贯穿始终。其目的就是保证（1）对用户体验有正确的预估（2）认识用户的真实期望和目的（3）在功能核心还能够以低廉成本加以修改的时候对设计进行修正（4）保证功能核心同人机界面之间的协调工作，减少BUG。

在具体的实施上，就包括了早期的focus group（焦点小组），contextual interview，和开发过程中的多次usability study（可用性实验），以及后期的user test（用户测试）。在设计–测试–修改这个反复循环的开发流程中，可用性实验为何时出离该循环提供了可量化的指标。

相关话题：可用性测试源地址：http://www.mdong.org/?p=1643

揭露在线可用性测试的神话

Bill Albert — 2010-06-01 21:50:36

我很喜欢《流言终结者》这个电视节目，因为我认为他所面临的挑战就是真实。在节目中，用一种令人愉快的和科学的方法来对人们普遍认同的留言进行测试。在节目中我最喜欢的部分，当然除了爆炸的部分，是我所信仰的被证明是不真实的。这一直让我开放思想，专注于现实。我也喜欢另一个方面——揭露还没有建立起来的流言。这就是我这篇文章的视角。特别地，我将突出有关与网络可用性测试的五个常见的流言，同时解释为什么我认为这些流言是不真实的。

写这篇文章的动机是帮助用户体验研究生人员在线可用性测试时打开思想。已经有很多研究人员使用这种方法许多年，而且很有用（在某些情况下）。其他人则是刚开始接触，并希望了解更多的关于它的优势和局限性的信息。最后，一些用户体验研究人员已经形成了关于在线可用性测试的一些观点，并认为不是对各种各样的原因（没有形成的）都有用。我希望通过我揭露这些流言，作为用户研究团体的我们能够根据真实的功绩来评估这个工具。

1、有大量的干扰因素影响数据的可信赖度

可能大部分关于在线可用性测试的的流言是数据都不是很可信的。一些人认为这些参与者不会很努力，在参与调研时也是心烦意乱，会尽可能快的完成调研以获得相应的激励，或者虚假陈述他们调研的质量（目的就是获得奖励）。这的确是事实，大体上在所有的案子中占到5%-10%。但是，这已经是一个好消息了。

这儿有一些很好的技术来清除这些数据。鉴别（和移除）“精神骗子”并不难。这些人的行为是可以预测的。“扁平化”是指一些人的答案都是1或5，在5个等级量表中。“速度检测”是一种检测这些人（看问题6在这幅图下）的方法，确保他们确实认真阅读了每一个问题。一致性检验可以用重复词语的问题，并来分析一致性的回答。移除不切实际的任务时间也是很容易的，并能帮助处理那些在任务中间周末回家的参与者。同时，筛选问题可以写信给那些欺骗性最小的参加调研的参与者（那些伪装自己的人）。

归根结底，在线可用性测试的数据能够和传统的实验室测试一样可靠。唯一的不同就是在跳到分析阶段以前需求做一些清理。

2．你只需要收集数据

当人们告诉我在线可用性测试只适用与收集基本的数据：比如任务的成功、完成时间、满意度等时，我一直感到惊奇。因为某些原因,人们认为这只是因为你有一个大样本量,你只能收集定量数据。网络可用性研究是没有意义的,如果你想要收集关于用户体验的定性数据,。这些不能远离事实。

在线可用性测试的好处之一就是研究人员可以收集大量的关于用户体验的定量和定性数据。举个例子，如果用户对特殊的任务有困难，他们可以提供注解，说明他们为什会在这些任务上有困难，或者他们希望在交易时有困难的地方出现什么。定性数据，经常是详细的评论，能够在他们体验的任何一个环节收集。当用户展示某些行为时，他们甚至可以提示提供一些详细的评论，比如中途放弃交易或者偏离了导航行为。

详细的评论不仅很容易收集，而且很容易分析。现在有很多可利用的方法来选出来描摹这些详细的评论。在详细的回答中，词组群（见下文）是一种能得到快速反应的关键模型的方式。

3.在线可用性测试在设计阶段不能取得好的功效

大部分人认为在运行在线可用性测试只适用于产品建立好以后。这样的在线可用性研究只是总结性评估的一个部分，同时并不适合与实际设计阶段。在线可用性测试并不能指导设计，要么花费太多的时间，要么花销太大在设计阶段。这些并不切合实际。

在线可用性测试能在几个小时内建立起来，也能够很快的收集数据。我们已经能在一天内建立、发布并分析来自在线可用性测试的数据。不仅能够快速的建立，而且能够帮助回答在设计阶段发生的问题。例如：关于导航方式、标签、外观和感受的参数选择的问题。还有一些其他设计参数选择问题不能在小样本两中得到真实的回答。有时候，为了确认重大的设计方案，我们需要快速地从成千上万的用户中收集数据。

4.它只适用与网站

研究人员认为在线可用性测试只适用与网站评估。而不能用于软件，语音应答系统、手机、家用电器和烤箱。虽然大量的在线可用性测试专注于网站，但是没有必要。

多年来，我们用在线可用性测试方法并不局限于网站交互界面的评估。从理论上来说，这仍然是相同的方法。参与者会被提问一些问题，给予一些任务，提供一些关于他们真实体验的反馈。唯一的不同是不能跟踪参与这的行为。但是，可以收集大量的关于他们体验的数据，比如：他们是否能顺利的完成他们的任务，花费了他们多长时间，他们对这个体验有什么感受，或者他们有什么困难。因此，即使你可能放弃了一些行为数据，仍然有大量的他们的体验可以研究。

5.在线可用性测试花销太大

一些人说他们希望做很多在线可用行测试，但是经常性的使用会比较昂贵。这个确实昂贵，但是很幸运，在最近几年有各种各样的工具可以使用，使得在线可用性测试不再需要花费大量的经费。有大量的自我服务供应商，允许你建立并进行在线可用性研究。你只需要付费给他们的技术。请访问www.measuringux.com看一下供应商一览表。

如果预算确实比较紧张，可以用一些打折的在线可用行测试方法，或者基本上是免费的。利用一些在线测量工具（比如调查Gizmo或者调查猴子），一些HTML和JAVA脚本，你可以逐一的建立你自己的几乎免费的在线用户研究（请看下面图作为一个例子，是本土的方法）。而当你没有预算来进行在线可用性研究时，在这种情况下放弃一些数据和功能是必要的。请访问www.measuringux.com ，你能看到更多详细的关于怎么创建一个打折的在线可用性测试的说明。

自己试一试

我可能不一定能说服你相信这些流言是不真实的。不管怎样，我支持你把在线可用性测试作为你用户体验设计和研究努力的一个部分。这样做，你将会发现它的优点和局限性。毕竟，每一种用户研究方法都有它自己的优缺点，在线可用性测试也不例外。

编辑注：如果对这个课题感兴趣，Bill最近撰写了《超越可用性实验室：指导更大规模的在线用户体验研究》

第一次可用性测试

卡卡西的小巢 — 2010-05-06 21:59:55

上个月，借产品可用性测试机会，身平第一次接触了产品可用性测试。

以前，说到可用性测试，我的脑海里总会浮现出一些测试卡片、摄像机、价格昂贵的眼动仪等等高科技设备。真实经历了以后，发现原来那些根本就不是主角，真真的主角是找到合适的用户。

另外用户体验测试，实际上是通过用户的一些真实测试，检验产品的可用性，然后作为产品上线的重要参考。我觉得需要做好以下两点：

1、用户体验测试方案

产品可用性测试，是观察用户使用产品的、最自然的状态。换句话说，就是把用户扔进可用性实验室，然后你藏到一边，通过监控屏幕，偷看用户怎么折腾产品的全过程。但是，这次就这么干，发现用户总是在漫无目的地随手在页面上乱点。我希望用户在打开页面时的第一反应是是先听歌还是先搜索，用户却用鼠标轻轻一点从导航直接发进入了社区。用户体验测试就让用户这些折腾的吗？显然不是，这样太漫无目的，太费时费力了……

怎么才能避免这种状况呢？

事后，与这次负责体验测试的同事，沟通商讨得出以下结论：

首先对参加可用性测试的用户（尽管有可能老用户），但也要弄清楚的他们心理状态和期望值。因为用户会揣摹你的心思：到底想测试什么呢？所以，在进入体验测试环节以前，最好先了解一下用户。

然后，再将预拟定的体验测试任务书发给参与测试的用户，任务书不要太笼统，最好将大任务分解成一个一个的小任务，就样顺理成章地，这些用户就会根据任务书，一项一项的完成任务，最后发现他们在完成任务的过程中有可能出现的问题。在任务过程中，要让用户处于单独的环境，也不要提醒。

2、用户体验测试结论

最后，测试任务完成以后，对每个用户都聊一下，是否达到他们的期望值，得出每一个用户的体验测试得论，并综合得出体验测试的结论。决定产品是否上线，还是进行优化？

总之，做好体验测试，要做好以下3点：

1、找到合适的用户
2、准备测试方案，测试任务文档
3、得出正确的结论

可用性测试过程【图】

Ryana — 2010-03-15 22:11:58

可用性测试过程有6个阶段：

1 计划可用性测试

2.1 招募测试参与者

2.2 创建情景与任务

3. 处理可用性测试

4. 分析可用性测试数据

5. 编写与演示可用性测试报告

6. 逐条探讨报告中的建议是否采纳

原英文地址，偶给加上了中文。

浅谈易用性测试及GUI常见的测试要求(z)

gengdian — 2010-02-24 22:04:00

对于一个需要面对用户的软件产品来说，最直观的UI和使用感受也是产品能否获得用户认可的关键一环。个人认为，在毒霸的产品传统中，从设计到开发再到测试，对产品的易用性和GUI的规范往往给予的关注较少。我在测试过程中就遇到了很多影响使用心情的非关功能方面的 BUG。希望此文可以在毒霸的易用性和GUI方面的测试中给同学们提供一些参考。

易用性测试

易用性(Useability)是交互的适应性、功能性和有效性的集中体现。

在《软件工程产品质量》质量模型中，提出易用性包含易理解性、易学习性和易操作性；即易用性是指在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力。易用性测试包括针对应用程序的测试，同时还包括对用户手册系统文档的测试。通常采用质量外部模型来评价易用性。包括如下方面的测试：

(1) 易理解性测试

(2) 易学性测试

(3) 易操作性测试

(4) 吸引性测试

(5) 易用的依从性测试

易用性测试方法有：静态测试；动态测试；动态和静态结合测试。

由于易用性缺陷的主观性，因此测试人员和UI设计人员经常产生不同意见。UI通常被当作创造者的作品，而测试人员说某处是错误，就可能挫伤“艺术家”。易用性是软件缺陷中的敏感问题。

人体工程学(ergonomics)是一门将日常使用的东西设计为易于使用和实用性强的学科。人体工程学的主要目标是达到易用性。

1、用户界面测试

用于与软件交互的方式称为用户界面或UI。

2、优秀UI的构成

软件测试员要负责测试软件的易用性，包括其用户界面。

记住，软件测试员不需要去设计UI，只需要把自己当作用户，然后去找出UI中的问题。

优秀UI具备的七个要素

(1) 符合标准和规范

重要的用户界面要符合现行标准和规范，这些标准和规范由软件易用性专家开发。它们是由大量正式测试、经验、技巧和错误得出的方便用户的规则。如果软件严格遵守这些规则，优秀UI的其他要素就自然具备。

(2) 直观性

* 用户界面是否洁净、不唐突、不拥挤？

* UI的组织和布局合理吗？

* 是否允许用户轻松地从一个功能转移到另一个功能？

* 下一步做什么明显吗？

* 任何时候都可以决定放弃或者退回、退出吗？

* 菜单或者窗口是否深藏不露？

* 有多余功能吗？软件整体抑或局部是否做得太深？

* 帮助系统有效吗？
(3) 一致性

* 用户的使用习惯性强，希望一个程序的操作方式能够带到另一个程序中。在审查软件一致性时要考虑一下术语：

* 快捷键和菜单选项

* 术语和命名

* 听众

* 诸如OK和Cancel按钮的位置

(4) 灵活性

* 灵活性表现在：用户喜欢选择不要太多，但是足以允许他们选择做什么和怎么做。

* 状态跳转

* 状态终止和跳过

* 数据输入和输出

(5) 舒适性

* 软件使用起来应该舒适，不能给用户工作制造障碍和困难。如何鉴别软件舒适性的一些好想法：

* 恰当。软件外观和感觉应该与所做的工作和使用者相符。

* 错误处理。程序应该在用户执行严重错误的操作之前提出警告，并且允许用户恢复由于错误操作导致丢失的数据。

* 性能。快不见得是好事。不少程序的错误提示信息一闪而过，无法看清。如果操作缓慢，应该让用户得到相应的信息。

(6) 正确性

* 要测试正确性，就是测试UI是否做了该做的事。

* 市场定位偏差：有没有多余的或者遗漏的功能，或者某些功能执行了与市场宣传材料不符的操作？

* 语言和拼写：程序员常常能制造出非常有趣的用户信息。

* 不良媒体：图标是否同样大小？是否具有相同的调色板？声音是否应该有相同的格式和采样率？

* 所见即所得：保证UI所说的就是实际得到的。

(7) 实用性

* 是否实用是优秀用户界面的最后一个要素。

* 不是指软件本身是否实用，而是指具体特性是否实用。

* 在审查产品说明书、准备测试或者实际测试时，想一想看到的特性对软件是否有实际价值。它们有助于用户执行软件设计的功能吗？如果认为它们没必要，就要研究一下找出它们存在于软件中的原因。

总之，不要让易用性测试的模糊性和主观性阻碍测试工作。易用性测试的模糊和主观是固然的，即使设计用户界面的专家也会承认有的地方是这样的。

GUI常见的测试要求

窗口

* 窗口能否基于相关的输入或菜单命令适当的打开

* 窗口能否改变大小、移动和滚动

* 窗口中的数据能否用鼠标、功能键、方向箭头和键盘操作

* 当被覆盖的窗口重新调用后，所有相关功能是否可操作

* 能否使用所有窗口的相关功能，所有相关功能是否可操作

* 相关的下拉式菜单，工具条，滚动条，对话框，按钮，图标和其它控制有否？能否正常显示？完全可用？

* 显示多窗口时，窗口名能否正确显示，活动窗口是否加亮

* 使用多用户时，所有窗口是否能实时更新

* 多次或不正确按鼠标是否会产生无法预测的结果

* 窗口的声音、颜色提示和窗口的操作顺序是否符合需求

* 窗口能否正确关闭

数据项

* 字母、数据能否正确显示且输入系统

* 图象方式数据项（如滚动条）是否正常工作

* 数据输入、消失是否可以理解，能否识别非法数据

下列式菜单和鼠标操作

* 菜单条显示在合适语言环境中

* 应用程序的菜单是否显示系统相关特性

* 下拉式操作是否正确，功能是否正确

* 菜单、调色板和工具条是否能正常的工作

* 能否列出所有菜单功能和下拉式功能

* 能否通过鼠标操作所有菜单的功能，通过文本命令激活每个菜单功能

* 菜单功能随当前窗口操作加亮或变灰

* 如果要求多次点击鼠标或鼠标有多个按钮时能否正确识别

* 光标、处理指示器和识别指针能否随操作而适当改变
UI测试常见BUG

录入界面

1. 输入字段要完整，且要与列表字段相符合（参照数据库进行检查）

2. 必填项一律在后面用*表示（必填项为空在处理之前要有相关的提示信息）

3. 字段需要做校验，如果校验不对需要在处理之前要有相关的提示信息

(1) 长度校验

(2) 数字、字母、日期等等的校验

(3) 范围的校验

4. 录入字段的排序按照流程或使用习惯，字段特别多的时候需要进行分组显示

5. 下拉框不选值的时候应该提供默认值

6. 相同字段的录入方式应该统一（手动输入、点选、下拉选择、参照）

7. 录入后自动计算的字段要随着别的字段修改更新（如单价变后，金额也变）

8. 日期参照应该既能输入，又能从文本框选择

界面格式

1. 字体颜色、大小、对齐方式（根据字段的性质确定）、加粗的一致性

2. 文本框、按钮、滚动条、列表等控件的大小、对齐、位置的一致性

3. 所有新增、修改、查看页面加上页面说明（如：XXX新增、XXX编辑、XXX查看等说明字样），（弹出的）界面要有标题，标题与内容要一致

4. 不同界面显示相同字段的一致性（如列表界面和编辑界面）

5. 界面按钮显示要求（查询、新增、删除顺序）

6. 列表的顺序排列应该统一（按照某些特定条件排序）

7. 下拉框中的排列顺序需要符合使用习惯或者是按照特定的规则排定

8. 所有弹出窗口居中显示或者最大化显示

9. 信息列表中如果某个字段显示过长用“…”或者分行显示

10. 人员、时间的缺省值一般取当前登录人员和时间

11. 对于带有单位的字段，需要字段的标签后面添加如下内容：“（单位）”

功能问题

1. 按钮功能的实现（如返回按钮能否返回）

2. 信息保存提交后系统给出“保存/提交成功”提示信息，并自动更新显示

3. 所有有提交按钮的页面都要有保存按钮（每个界面风格一致）

4. 凡是点选或者下拉选择的界面，如果一旦选择完了无法回到不选择的情况，需要加上“清除选择”功能按钮

5. 没有选择记录点击删除/修改按钮要提示“请先选择记录”

6. 选择记录后点击删除按钮要提示“确实要删除吗？”

7. 需要考虑删除的关联性，即删除某一个内容需要同时删除其关联的某些内容

8. 界面只读的时候（查询、统计、导入）等，应该不能编辑

查询问题

1. 查询条件缺少一些可以查询的字段

2. 有些查询条件需要支持模糊查询

3. 需要考虑有些查询条件本身的关联性（即某个查询条件的取值范围是依赖于其它查询条件的取值）

4. 查询条件名称与信息列表及信息编辑页面相应的字段名称完全统一

5. 不同模块相同字段的查询方式应该统一（手动输入、点选、下拉选择）

6. 出报表的时候，查询条件需要显示在报表标题的下面，这样看报表的时候知道数据的依据是什么

7. 对于范围的查询采用全闭的形式

相关话题：可用性测试源地址：http://rdc.taobao.com/blog/qa/?p=5790

可用性竞品分析

quicksand7117@gmail.com(quicksand) — 2009-09-29 17:04:42

关于产品可用性的竞品分析，前端时间做了下整理，放出来跟大伙探讨吧！---太久没有更新博客了，人变懒了。。。

分析目的：
竞品分析的目的就是要展示站点（产品）的一致性，从而树立好的，最佳的或者反面的行业实践；或者为了展示站点（产品）间的显著差异，确定其杰出之处。这种不一致之处就意味着，某一独特的站点（产品）为了一个普通的问题发明了一种全新的解决方案，或者说明业界并没有拘泥于单一的方法

分析时机：
初期的竞品分析大多倾向于关注战略层的问题，而在项目后期的竞品分析大抵是为某些具体的设计问题寻求更好的解决思路

受众对象：
不同的受众将会影响到分析数据的呈现形式。
对外（没有直接参与项目的人员）：需要建立一个独立而完整的文档，描述项目背景和评测标准、解释分析原因、对结论进行概述等等。
对内：不需要过多的上下文背景或描述性语言，这样能加快交付速度。

评测标准：
对比站点（产品）的评测标准有很多，它们可以像主导航分类这样宽泛，也可以像网站某处的按钮标签这样精准。

评测方法：
“是/否”评估法：
网站（产品）是否具有某一功能特征的对比，该方法对于功能特征的比较最见效。
评分法：
相对“是/否”评估法更言之有物。使用该方法时，必须定义出每一方面怎样做才算好。
描述法：
详细描述了各竞品是如何达到各项评测标准的，描述法可以使你对各竞品间的较量更加清楚，此方法最常用。

分析框架模板：
笔录要点

“是/否”评估法

评分法

描述法

套帧小图法

可用性竞品分析

这是我的一个可用性竞品分析的实际案例，关键文字信息隐掉了，格式大家可以参考。

相关话题：可用性测试源地址：http://www.uesand.com/article/37.htm

可用性问题的严重性评级

徽徽 — 2009-05-25 22:14:31

原文作者：Jakob Nielsen
原文链接：Severity Ratings for Usability Problems
译者：徽徽

可用性问题的严重性评级

Jakob Nielsen

对可用性问题进行严重性评估，可以把大多数资源分配到最严重的可用性问题上去，并且可以对这些问题是否需要额外的可用性努力进行粗略的估计。如果在一个界面中，严重性评估表明，存在着几个灾难性的可用性问题，那么，放过它们显然是不合适的。但是如果一个系统，仅仅存在一些本质上可以被认为是装点门面的几个可用性问题时，我们通常会让其发布。

一个可用性问题的严重性是以下三个因素的组合：

频率（Frequency）：这个问题发生的频率如何，它是通常发生的还是很少发生的？

影响（Impact）：如果这个问题发生，它对用户带来了什么样的影响。用户克服它是困难还是容易？

持续性（Persistence）：这个问题的持续性如何？这是否是一个一次性的问题？也就是说，一个用户一旦理解之后，就会克服它。还是说，这个问题非常难以理解，持续的给用户带来不便（bother，用户心理上感到不便）？

最后，我们当然需要去评估这个可用性问题的市场影响（Market Impact），因为某些可用性问题可以对一个产品的流行产生毁灭性的影响，即使它客观上来说是非常容易克服的。尽管严重性有着几个因素，通常情况下，需要把严重性的多个特征分数整合成一个单一的严重性分数，作为这个可用性问题的总的严重性，以便区分出优先级并进行决策。

以下0-4的等级量表可以用来评定可用性问题的严重性：

0- 我根本不认为这是一个可用性问题

1- 这仅仅是一个装饰门面的可用性问题：并不需要特别的处理，除非这个项目有额外的时间

2- 次要的（Minor）可用性问题：解决这个问题的优先级较低

3- 主要的（Major）可用性问题：解决这个问题是很重要的，优先级很高

4- 可用性灾难（Catastrophe）：解决这个问题是非常必要而且紧急的（Imperative），必须在产品发布之前解决它。

启发式评估中的严重性评级

在启发式评估过程中，当评估者更多的是在关注发现新的可用性问题时，要获得一个较好的严重性评估是比较困难的。同样的，每一个评估者仅仅会发现少量的可用性问题。因此，评估者仅仅只对他发现的可用性问题进行严重性评级是不够的。事实上，我们需要在每一个评估者独立发现可用性问题之后，然后将这些问题汇总，对每一个问题都需要进行合理的，详尽的描述，并配有相应的屏幕截图来进行说明，并用一个完整的列表列出所有的评估者发现的可用性问题，最后将这个完整的列表发给每一个评估者，并附上一个问卷，要求他们对每一个问题进行严重性评级。对一个可用性问题的描述，可以由一个评估观察员（Evaluation Observer）在发现这个问题的评估者（一个或多个）对这个可用性问题的原始评论的基础上合成。或者，如果采用书面的评估报告的话，对汇总列表上的某个可用性问题的描述可以由发现了这个可用性问题的评估者的评估报告中，对这个问题描述合成而来。即使评估者在其独立的严重性评估过程中，没有发现某些可用性问题，这些对可用性问题的描述也可以方便每个评估者较容易的对各种问题进行评定。一般来说，评估者仅需要花30分钟的时间来完成其严重性评级。需要注意的是，每一个评估者必须独立的完成成他们的严重性评级。

大多数情况下，当评估者在考虑多种可用性问题的严重性时，他们并不允许实际接触系统。评估者通过再次访问部分实际的界面，而不是依靠他们的记忆或者对可用性问题的书面描述，很可能会获得一些额外的领悟。同时，毫无疑问的，如果评估者被允许进一步的与系统交互，他们进行严重性评级的速度就会减慢。同样的，如果特定的计算机资源需要去运行一个原型系统，或者因为机密性的考虑，软件分配有限的话，排期问题也很难让每一个人在方便的时间与计算机进行交互。

我的经验告诉我，来自单一评估者的严重性评级太不可靠而难以被信任。当更多的评估者一起评估可用性问题的严重性时，严重性评级的平均数的质量快速上升。在大多数实际使用中，采用3个评估者的严重性评级的平均数，就已经令人满意了。

相关话题：可用性测试源地址：http://www.yeeyan.com/articles/view/41443/42679

可用性测试的一些心得

Raymond — 2009-05-05 22:58:04

通过UCDChina和blueidea以及jobdiggs几个窗口，有幸认识到了许多对用研工作感兴趣的同学，因最近太忙未能及时和每一位热心的同学进行联系和回复，请诸位多多谅解。

MSN爆了，有意全职用研的同学还是将简历直接发到 quan.zhou@kunlun-inc.com …

牺牲了3天的五一休假，我和Superdragon终于结束了为期十天的第一阶段用研工作，这十天从白忙到黑，趁着脑子还清醒，总结一下经验和心得：

1. 先培训，再上岗，先了解游戏，再进行用研，专业知识结合游戏经验，才能和参与者更好的沟通。
2. 避免专业术语，尽量让对方感到亲切：“一说黑话就知道是道上的人”，这一点同样适用于跨部门沟通。
3. 做测试前，一定要团队人员填饱肚子，可用性测试是一件非常消耗体力和脑力的事情。
4. 现场手忙脚乱往往是一些细节事先没有做好，杯子，座位位置，屋内的光线，往往有时一点点疏忽，堆积起来就会给对方带来很多压力。
5. 总会有一些突发事件，应变能力很重要。
6. 不要以为有了录屏，就可以忽略纸笔，良好的标注会让你看录屏时更有选择性，节约时间。
7. 看录屏时，需要结合语境分析对方的潜台词。
8. 对于“表达型”和“内向型”两种参与者，要及时引导，把握好节奏。
9. 把参与者当做朋友，而不是小白鼠，尊重别人，对方才会积极配合你。
10. 当对方想放弃的时候是不会主动告诉你的,但也不能老问“你想放弃么？”
11. 不要问一些引导性很强的问题。
12. 当用户的回答自相矛盾的时，一定要追问清楚。
13. 及时总结经验，测试-整理-测试……这个过程是渐渐完善的。

之前信息输入的太多了，最近在对信息输出时，感觉很头大：

1. 试图采集完一批数据后一次性集中整理的结果是：海量的数据把你逼疯；
2. 输出的时候，要学会舍弃。每个参与者贡献的信息都很有价值，但不一定都要在报告中体现。
3. 没有意义的数据尽量不要输出，每一个数据都要有依据且能说明问题。

我认为用研最最困难的是是输出，你的输出物将直接决定你之前的工作是功劳还是苦劳。
在改进产品设计时，高质量的用研输出将提供强有力的支持，交互设计与工作接口人(PM/策划/开发)的交流和PK成本便会降低。

一切都通过用户说话，交互设计是矛，用研是后盾。

专家评估：超越启发式评估

Junge — 2009-04-22 22:02:38

Usability Expert Reviews: Beyond Heuristic Evaluation
很多人用Nielsen的十个可用性原则来进行专家评估。这10个原则很多都是common sense，没有经过研究进行验证过的。国际可用性标准，BS EN-ISO 9241-110,建议另外一套评估原则，包含七个guidelines。这些guidelines得到国际一致的认可，并且可以用到任何的交互系统上。
原文：http://www.userfocus.co.uk/articles/expertreviews.html

什么是可用性专家评估(usability expert review)？
专家评估，是由评估人员使用产品或者网站，根据一些列设计原则来评估其可用性。专家评估之所以流行是因为迅速，便宜，相比可用性测试而言。
Nielsen的10个评估原则，相信大家都很熟悉了。
1. 系统状态可见性 Visibility of system status

透过在合理时间内的合适回馈，系统应该让用户了解正在发生的事情

2. 系统与真实世界的关联性 Match between system and the real world

该系统应该以使用者熟悉的语言、文字、词汇与概念来呈现，而不是使用系统导向。遵行现实世界的转换，将可以让资讯以自然与具有逻辑的方式呈现

3. 使用者的控制度与自由度 User control and freedom

使用者时常以尝试错误来选择系统功能，而且他们需要一个明显的「离开系统」来离开使用者不需要的状态。并且支援復原步骤与重复步骤。

4. 一致性和标準 Consistency and standards

使用者不应该猜测同一种动作是否使用不同的字汇、状态或动作。还要考虑到瀏览器的相容性。

5. 预防错误 Error prevention

这是比错误讯息还要亲切的设计，预防是发生问题最先要考虑的事情。不管是移除容易出错的的条件，或是让使用者确认他们接下来要做的行动皆是。

6. 让使用者去认识系统，而非去回顾 Recognition rather than recall

尽量减少使用者需要记忆的事情、行动以及可见的选项。使用者不应该记忆太多步骤。系统使用说明应该在适合的地方表现的显眼且可轻易使用。

7. 灵活性与使用效率 Flexibility and efficiency of use

专家使用者通常可以使用加速器来提昇他们的使用速度，像是满足没有经验与有经验的使用者。允许使用者设定常做的动作。

8. 美术与简化设计 Aesthetic and minimalist design

对话框不应该包含无关紧要或很少用到的讯息。对话框的每一个额外的部份都会相对地降低主要资讯的显眼曾度。

9. 帮助用户认识、侦错并从错误中恢復 Help users recognize, diagnose, and recover from errors

错误讯息应该以叙述文字呈现，而不是错误代码，并且精确地指出问题以及提出建设性的解决方案。

10. 帮助与说明文件 Help and documentation

即使是最好的系统也不能没有说明文件，系统也需要提供帮助与说明文件。这类型的资讯应该很容易被找到，著重在使用者的工作上。

Nielsen可用性原则的限制
虽然简捷，但缺乏可实施的精确度。“这些广泛使用的原则并没有被有效验证。没有证据标明在设计和用户界面的开发中如果使用这些原则就会提高界面的可用性。”

那还有其它的可用性原则么？ISO 9241关于人机交互系统的工效学，110部分关于对话设计的原则。这些原则基于研究得到国际一直的认可。(这里的对话似乎翻译成交互更好，只是原文用了"dialogue")

这些原则，标准的定义如下：

1.对话符合用户当前的任务和技能水平吗？(Suitability for the task)
2.对话对用户下一步要做什么描述清楚吗？ (Self-descriptiveness)
3.对话一致吗? (Conformity with user expectations)
4.对话支持学习吗？(Suitability for learning)
5.用户能控制的交互的步伐和顺序吗？(Controllability)
6.对话允许错误的操作吗？(Error tolerance)
7.对话可以个性化以适合用户的个性需求吗？ (Suitability for individualisation)

（详细的请看下边的E文）
1. Is the dialogue suitable for the user’s task and skill level? (Suitability for the task)
“A dialogue is suitable for a task when it supports the user in the effective and efficient completion of the task. In a dialogue which is suitable for the task, the user is enabled to focus on the task itself rather than the technology chosen to perform that task.”

2. Does the dialogue make it clear what the user should do next? (Self-descriptiveness)
“A dialogue is self-descriptive to the extent that at any time it is obvious to the users which dialogue they are in, where they are within the dialogue, which actions can be taken and how they can be performed.”

3. Is the dialogue consistent? (Conformity with user expectations)
“A dialogue conforms with user expectations if it corresponds to predictable contextual needs of the user and to commonly accepted conventions.”

4. Does the dialogue support learning? (Suitability for learning)
“A dialogue is suitable for learning when it supports and guides the user in learning to use the system.”

5. Can the user control the pace and sequence of the interaction? (Controllability)
“A dialogue is controllable when the user is able to initiate and control the direction and pace of the interaction until the point at which the goal has been met.”

6. Is the dialogue forgiving? (Error tolerance)
“A dialogue is error-tolerant if, despite evident errors in input, the intended result may be achieved with either no or minimal corrective action by the user. Error tolerance is achieved by means of damage control, error correction, or error management to cope with errors that occur.”

7. Can the dialogue be customised to suit the user? (Suitability for individualisation)
“A dialogue is capable of individualization when users can modify interaction and presentation of information to suit their individual capabilities and needs.”

如果根据国际标准来指出设计中的问题，而不是个人意见的话，更容易被设计师所接受。下一次，你也可以试着用这七个原则进行评估，也行这个并不像Nielsen的10个可用性原则那样广为人知，但是却有国际标准的权威和可信度。

中国的设计师，不同行业不同领域的应该通过自己的用户体验研究部门，经过长期用户研究的结果，建立属于自己的高用户体验的设计原则。

相关话题：可用性测试源地址：http://www.userfree.cn/?p=840

可用性实验室是有害的

yusen — 2009-04-07 07:18:23

我现在在上一门叫做软件体验设计（Software Experience Design）的课。这门课是由Stanford d.school开的。

这个课一个牛逼的地方就在于Hasso Plattner，SAP的cofounder和chairman，从目前来看每节课都会过来和我们一起上课。当然，d.school就是这哥们冠名的（Hasso Plattner Institute of Design）。看到他每每都让我陷入沉思，什么时候中国这种超牛逼企业的高管也能这么重视用户体验呢？

今天我们照例围成一圈讲用户需求收集（Needfinding），我已经忘记是怎么开始的了，Hasso Plattner突然发飙鸟。“Usability Lab is bad.”他说。“It’s making users lab rats.”

是啊，不要说用户，当我在Google China的可用性实验室里面坐着的时候都觉得不舒服，一个硕大的单面镜，摄像头，录音设备，自己不熟悉的环境，不熟悉的电脑，等等。有次一个用户硬是不会输入中文了。

在可用性实验室里面，我们经常关掉其他程序，把我们想测试的软件最大化，把任务规定好流程。而实际上呢？用户可能同时有20个程序在运行，而我们的软件只是一个小窗口；用户可能用到一半，打开浏览器查个资料，接个电话，站起来伸个懒腰，喝口水，回条MSN信息，然后再继续之前的工作。没有人盯着我们，没有人记录我们的一举一动。

作为一个受过多年正规科研训练并且做了一大堆实验的研究僧，我却经常很不愿意相信“研究”和“实验”出来的结果。为什么？当你越了解这个过程，你往往越觉得什么统计显著啊很少有靠谱的，实验设计和引导对实验的结果，有着重要的影响。而且最关键的是，当用户被丢进实验室，他就不是自己了。想想科学家还能提高智力呢，何况是来到一个完全不一样的环境？

相对来说，我更加相信ethnography研究的结果。我相信只有深入到用户的环境（context）中进行观察和访谈，所得到的结果才更加有说服力。观察用户和周围环境的互动而不仅仅是目标软件本身，用户创造的物体（artifact study），用户出乎预料的行为和捷径（workaround），都对用户研究有着重要意义。

SAP的Executive VP今天在课上说：当你合上你的笔记本，准备跟用户结束这次访谈的时候，千万不要关掉你的录音器材，很多时候整个访谈中最重要的insight就是这时候用户一放松说出来的。就跟Big Bang Theory里面那印度哥们对着女人就说不出话来一样，很多人一听到访谈两个字，立马连说都不会话了，在脑子里拼命地自圆其说（sense making），怎么可能有真实的表现呢？

当然，饭要一口一口吃，在中国说可用性实验室有害无疑是不切合实际：那么多公司包括全球最大中文搜索引擎公司还没有呢……某种程度上，可用性实验室是UE在公司资源的一种体现，实验室研究结果，也是说服各种stakeholder的好武器，只是，大家都别太当真就好了，特别是所谓的统计显著……

相关话题：可用性测试源地址：http://www.lanrenux.com/?p=200

UE实践笔记：假用户crossover真砖家

helicopter621 — 2009-03-30 16:04:46

摘要：本文尝试论述一种结合了“认知过程走查”及“启发式评审”这两种可用性检视法、并予以简化的UI评估框架。Part1将略为讲述形成这个框架的源起、思考花絮。Part2是详细的讲述。由于原PPT使用的皆为内部案例，故在此会略去例子部分。Part3是后记。本文较长，请选择性阅读。

Part1：源起

作为用户研究人员，如何向设计师提建议是我们小组经常思考的问题。设计师可能会质疑你在交互或视觉设计方面的专业性，但实践中发现，的确有些问题是无需通过用户测试验证便能识别的。那如何能较有效地传达测试前发现的问题呢？恰好看到这篇论述UI评审的文章，受到一定启发。但那篇文章更像是规范检视，于是取其理念重新规划和代入更多内容，形成了雏形在小组内部分享了一下。之后因准备参与整个UED的分享，对其反复思考，并开始头大。初衷是形成一个相对简单易用的评估框架，但也因此涉及到全面性、结构性的问题，需要考虑一众概念的分与合、层次结构等。

花了一个周末，一边刷贴吧，一边颠来倒去地调整（多累多精分啊！）。这个评估框架的名字也改了几回，最后演变成最简练的——假用户crossover真砖家。

————————————————————————————————————————————

Part2：假用户crossover真砖家

一。简介

即结合了“认知过程走查”及“启发式评审”这两种可用性检视法、并予以简化的UI评估方法。理论基础见附录1。

冗长、学术的名字无需刻意去记，记住假用户、真砖家即可。

为何名曰“砖”家？原因有三：

1.真正名副其实的专家，需在业内有长期（至少6-10年？）的沉淀和经验积累

2.降低门槛，让不是专家的人也能做积极、有建设性的评估

3.这个动辄“专家说”的年头，专家还真不如有实力的砖家！

二.

每个产品都是设计师的心血结晶，找茬者也应用客观的态度来找问题。本方法最重要的目标就是提供着手分析一个UI的评估框架或思路。

相对而言，这是成本最低、最快捷的可用性研究方法，能有效、迅速地发现问题。

此外，不少问题可在用户测试前被解决掉，无需用户来验证。

三.

为什么要代入角色？
代入用户这个角色时，可更直观地体验真实用户有可能如何使用一个UI，避免因专业性过强而对一些基本问题的麻木与无视，也可获得更宏观的感受；

代入砖家这个角色时，则是理性、详尽地对一个UI进行分析，要有一定的系统性和理据，才能以理服人，并探索解决之道。所以作为砖家的时候不能空手套白狼，要借助可用性经验准则（即一些设计理念、原则，见附录2）、要对产品本身有所了解，还要具备专业的知识。

不是说降低门槛吗？那搞视觉的没有交互的知识怎么办？（或反之）
知识不应是扮演砖家的门槛，毕竟快速获取知识的资源很丰富，而且，作为用户体验设计者，各个方面的知识都应该略为具备

四.

何时评估？越早越好！迭代进行！
怎样操作？

在评估他人的UI时，两种角色皆宜代入！

自己较难投入地做自己产品的用户，但自查、自拍有助“健康”！主动邀请他人来拍你就更“健康”！

五.

当邀请他人来做你的产品的用户时，可根据产品目标（即主要功能点）安排一些基本任务；

如果是自发想去拍人家，就自己给自己安排吧！

目的是为了更自然、更投入地去使用这个UI，而非从一开始便带着职业的眼光去挑问题。

列出的四个点，可以当作一些“信号”。在使用过程中，如果你感觉到了这些问题（也许只是隐隐约约），那么在第二阶段的分析过程中可找出相应的切入点。

六.

严谨来说，该分析结构的第一大点应为——功能：产品逻辑是否合理

但是以本司情况来看，到了原型阶段，（理论上来说）产品需求、逻辑应该是没问题的。因此不纳入本次讨论中。

七.

交互的评估可针对交互控件与交互过程两部分。

控件是各个零散的元素，将控件组织起来，引起交互行为，形成交互事件。

八. 交互
1. 交互控件：是否正确选择并使用？
正确= 1）符合控件使用规范 2）符合使用情景 3）开发性价比高
在YAHOO的设计模式库中，对每个模式都详细说明了该何时使用（Use When）、如何使用才能发挥其设计意义（Maintaining the Metaphor），以及相应的理由（Rationale）。科学、严谨。

2. 交互过程

2.1 Bug：此乃硬伤式错误

2.2 导航：

是否提示任务进度、状态？
是否良好支持前进、返回？（是否大量对后退键的依赖？）
当前交互过程结束后的引导

导航可以十分宏观（网站整体级别的），也可以细微到一个特定的交互过程中。在评估导航时可以关注以上列举的三个部分。
值得一提的是第三点：当前交互过程结束后的导航。举例来讲，一个注册流程，是否到注册成功就结束呢？尤其对于新用户，很多数据（好友、交易……）皆为空时。也许设计师的职责只是设计注册这一个流程，但是流程结束后，不应把用户悬置，还应进一步考虑下一步该把他们导向何处，或引导他们去做什么事情（如加好友、逛逛……etc）。

2.3 交互事件（引导用户完成任务的交互行为）：

可以从以上四个方面评估交互事件。这四个方面是递进的。可用性是基础，效率是在保证了可用性之后的进一步要求，而反馈、一致性则能更好地提升用户满意度。

必须指出的是，可用性问题往往在用户测试中曝露出来。原因后面会论述。
而砖家的价值就在于对后三方面的评估，因为这往往是普通用户在测试中较难直接指出的。

可用性：任务是否能完成？
效率：
（1）认知负担是否繁重？即用户是否需要思考良久才进行操作，或操作过程中停顿下来反复思考？
（2）鼠标操作、视线追踪是否迂回曲折？当用户思考完成，开始操作时，操作流是否流畅呢？可通过画出可能的操作流程箭头图来进行评估。
（3）是否容易造成误操作？考虑完操作流的复杂程度后，需进一步考虑操作流是否易导致误操作
（4）是否已考虑极端使用情景？要考虑数据量极大时对效率的影响，以及是否提供相应的检索工具（搜索、排序、筛选等）

反馈：
（1）反馈的时机：是否需要反馈？反馈何时出现？
（2）反馈的强度：视觉、文案是否有效传达系统信息？
一致性：对于某个具体的产品中，一些相似交互事件的交互过程也应有一定的一致性。否则会在一定程度上造成用户的不安。

九.

视觉评估本是较为主观、并需要一定美学素养的，但在这个评估体系中，对视觉的评估并非针对美学元素，而是尝试以格式塔原理为基础，对视觉进行一些客观的分析

亲密性
（1）相关元素是否组织在一起？
（2）不相关元素是否存在可能误导用户的亲密性?
（3）是否有太多孤立的元素？
对比：对比是否畏缩？
对齐：
（1）元素是否整齐有序？
（2）对齐是否统一、有条理？
重复：元素是否有一致性？

十.

用词
(1)是否一致？
(2)是否有错字？

行文
(1)是否使用用户的语言？
(2)是否清晰无歧义？
(3)是否存在冗余信息？

关于文案，请期待襄襄的大作。我只将文案作为这个框架的一部分收入其中，不作具体讲解了。

十一.

十二

作为经常接触互联网产品的设计师，操作水平、发现力等都较强。而用户更多是普通甚至初级的互联网用户。

对产品或网站整体的深入了解，也会影响我们对基础问题的判断。

以本司网站为例，用户群体各异。除了基本的买卖家之分，买卖家群体本身也有不同类型的细分。同时，用户的操作水平、教育水平等也是各异的。作为设计师，很难一一了解目标用户如何使用我们的产品

十三

十四

————————————————————————————————————————————

Part3：后记

很困，今晚的剧情让我很不爽，滚去睡觉，明天再说。

相关话题：可用性测试源地址：http://piglili.blogbus.com/logs/37270770.html

《Zen of Palm》读书笔记－7. 设计验证

丁宇（Felix Ding） — 2009-03-17 07:29:22

说完了“设计实践”，这次讨论“设计验证”，还是从一个漫画谜语开始：

这次的谜语挺逗，叫“铁匠如何打造出完美的马蹄铁”？本篇的主题是“设计验证”，所以答案自然同用户研究和可用性测试有关。

基本的可用性测试原则

《Zen of Palm》列出了一些基本的原则，都很简单：

尽早测试。越早发现问题，改正的成本越小；
使用合适的东西测试。这里的原话是“test with simulations”，我没有翻译成“模拟”或“可交互的原型”一类的文字，因为纸上原型一样能用来测试，并且效果还不赖；
有选择性的测试。这指的是如果你没钱没时间做完整的测试，就挑最重要的功能测试；
找对人并用对方法。你找同一个项目组内的同事基本上得不到太多有用的东西，所以要找局外人（原文是“outsiders”）；此外要注意方法的合理选择；
迭代。频繁的测试，频繁的改进，产品就会变得越来越好用；
不要用术语。

其它1：注意访谈技巧

谈话谁都会，但访谈的目的去挖掘用户的想法和测试产品，不是去和用户唠嗑，所以一些访谈技巧还是要有的。

其它2：设计师还是别去做测试了－如果没有较强自控力的话

有多少人能忍受别人没完没了地质疑和批评自己的设计？我昨天就见到一个客户的设计师在做测试时急得脸色都变了，后来索性把她拉倒一边，我来问，她只管记录。虽然访谈时我们没有说话，但从时而的眼神交流中不难发现她对于结果的惊讶。

所以，设计师还是尽可能把测试交给别的不相关的人去做，自己只管研究和设计好了。

谜语3的谜底

这篇笔记很短，原文也不长，而个中精华则只有付诸行动才能真正领会。

下篇“设计完善”将是本连载的最后一篇，敬请期待。

用户体验与测试

云齐 — 2009-03-09 13:07:12

          用户体验，简单的说就是用户使用方便，用户使用方便说起来容易，但作为测试怎么样才能衡量“用户使用方便”，你提出来的用户体验问题如何才能说服开发或者 UED去修改呢?很多做过测试的人在测试的过程中多多少少都会遇到一些这样的问题。可能大家平时遇到一个功能就是用的不爽但也说不出个所以然来，像这样公说公有理婆说婆有理，最后问题得不到好的解决。导致上线后出现一系列问题，伤害用户伤害公司伤害自己。
         很多时候我们可能都是通过主观意识来做事情，尤其对待用户这块。大家平时都在说要站在用户的角度去思考问题，去做事情。平时我们提出的所谓用户体验的问题，也都这样说“我是站在用户的角度来考虑的”，但是这些语言总是显得苍白无力。为什么？我一直在思考这个问题。静下心想想，我们真的是站在用户的角度吗？我们真的了解用户吗？我们的依据是什么？其实不光我们测试，任何人都需要思考这些问题。
        单就测试这边而言我觉得我们可以在测试准备阶段加上用户数据和用户行为的收集，采集这一环节。作为测试过程中我们测试工程师用户体验测试一个强有力的依据。让我们真正代表用户去提出问题，解决问题。最终达到用户和公司都满意！
        说归说大家可能在想我们后续如何去收集数据？什么人去收集？收集哪些数据？收集完数据如何利用好这些数据？是否每个项目都适用？用完是否真的对我们的用户体验有所帮助？投入与产出是否成正比？
        针对以上问题我拿一个某功能模块改造项目为例来尝试回答以上问题。项目立项之后由需求人员对该改造的项目的用户类型以及每种用户的行为进行分析，并从数据分析部门（上一个项目发布后会对数据分析部提出这样数据采集的需求，等到下个项目来临就可以轻松获得数据，形成一个循环）收集相应的数据产出一份用户数据报告。测试人员（其他人员可能也会利用到这份报告，我这里单讲测试人员如何利用这样的数据）拿到这份数据报告，在测试准备阶段，根据这份报告产出相应的用户体验测试用例以及用户体验实体数据，这些数据可以自己造，当然必要的情况下也可以找DBA协助。准备工作完毕后在集成测试执行阶段进行到各功能模块基本稳定就可以执行我们的用户体验测试用例啦。当然根据实际情况用户体验测试也可以提前一点来做。执行完毕并产出用户体验执行报告。等到项目达到发布条件就可以发布啦。
         项目发布后我们就可以对我们的用户体验测试的效果进行评估了。需求人员跟踪用户反馈问题结合我们产出的用户体验执行报告进行综合评估，看看我们测试所做的用户体验测试是否真正对用户有帮助。通过过程中采集相应的用户体验的工作量与我们测试出来的用户体验问题带到线上的代价预估最终得出投入与产出比。还可以对项目之间进行横向的对比，看看哪些项目适合这么做，哪些不适合这么做。
         以上仅为个人的一点想法和一些不成熟的实施方案，仅供参考，呵呵！

相关话题：可用性测试源地址：http://rdc.taobao.com/blog/qa/?p=793

可用性测试过程中需要关注的一些细节

jason — 2009-03-04 08:48:07

原则：

1. 我们测试的是产品可用性，不是使用者的个人能力

2. 尽量不要打断用户的操作

3. 尽量让用户独立完成

4. 测试环境和场景任务应当尽量符合用户使用产品的真实环境

5. 要让测试用户感觉到自己是被充分尊重的，尽量使其心情平和放松

其他：

1. 每次用户测试前先要把测试用电脑的缓存和历史记录清除。

2. 测试前一定要做预测试，把发现的问题记录下来，并在测试前把问题解决。

3. 用户到体验室后，不要马上开始，先和用户聊聊天，拉拉家常。让他放松，告诉用户先休息几分钟，过会我们正式开始，再向您介绍本次测试的主题等等。考虑准备一些和用户的沟通的东西。

4. 要和用户说明本次测试的产品、测试的目的、和测试大致的步骤以及可能花费的时间。

5. 注意和用户沟通的语气，语速要慢。如果担心用户对自己表达的内容没有完全理解，可以说“我把我的意思表达清楚了吗” 和用户说话时要尽力看着用户，保持微笑。

6. 过程中请尽量不要打断用户。

7. 用户碰到问题情绪记得事先安抚用户。如“这个问题很多用户都碰到了”或“这个问题不是很重要，我们先放放。”

8. 用户碰到问题时，可以提醒用户，不要代替用户操作，更不要说“您只要点一下这里就可以了”和不需要那样做等等，会让用户觉得他很无知。可以换种说话如：您可以试着这样操作看看

9. 不要问用户“你为什么要这样做。。。”可以换钟方式如“我刚才看到您是这样操作的，能和我们说说你的理由”或“当时您是怎么想的”

10. 如果用户操作的流程中并不是我们关注的流程，而用户由碰到了问题，这时候我们可以主动帮助用户。

11. 当我们决定介入用户操作时，先询问用户是否需要帮助，用户现在想做什么，碰上什么问题。

12. 引导员和观察记录员的电脑最好不让用户使用。

13. 如果用户不是在关键任务上出现问题我们可以主动提供帮助，

14. 如果在用户操作出现错误并遇见到他不能通过自身能力解决时应当主动帮助解决。

15. 不要说“你有没有听懂”，要说“我有没有说明白”

16. 当用户犯错误时要安慰他说“不只是您一个人有过这样的问题，很多用户也出现过类似的问题”

17. 不要把体验问题归结到谁的身上，无需给用户解释原因，不要承诺什么，只需记下问题反馈给相关人员

18. 不要问用户你为什么这样操作，要说“能告诉我你是怎么考虑的吗？”

相关话题：可用性测试源地址：http://ued.alipay.com/?p=918

用户研究方法—用户测试法

臭鱼 — 2009-01-07 12:58:05

“这是什么啊，用不明白，体验太差了！”、“在哪里登录？找不到啊！”、“谁知道这是个按钮可以点啊，像个图片！”在产品体验中，我们经常会听到这样那样有关产品体验的声音。而主动并客观地去发现这些问题（可用性问题）的方法之一，就是我们今天要介绍的用户研究方法之一——用户测试法。

什么是用户测试？通俗地讲，用户测试就是通过给用户制定任务，在用户执行任务的过程中，发现产品设计的不足，并为产品优化提供依据的一种方法。

通常情况下，根据目的不同，用户测试可以是定性地发现问题、也可以是定量地比较两个竞品的优劣。根据测试产品特点不同，可以采用边做边说的用户测试、也可以采用回顾式用户测试、甚至可以采用协同式用户测试等。用户测试可以用于产品设计阶段测试产品低保真原型、也可以用于产品测试阶段在发布前发现重大的可以优化的可用性问题、还可以用于产品发布以后，为下一个版本的优化提供依据。

一般情况下，根据ISD产品特点、时间等条件的限制，在产品测试阶段或者产品发布以后以发现可用性问题为主的边做边说用户测试较为常见。下面将以迷你屋用户测试为例，来说明如何进行一场简单的以发现问题为主的边说边做法用户测试。

迷你屋用户测试主要经历了测试前的准备、进行测试、测试后总结三个阶段：

第一阶段：测试前的准备
1.编写测试脚本
测试脚本主要指用户测试的一个提纲。测试脚本最基本的就是制定测试任务。任务的制定一般由简至难，或者根据场景来制定。

迷你屋中，基于用户场景制定了以下三个任务：
● 装扮一个迷你屋
● 在迷你屋中冒泡
● 让好友的QQ秀形象展现在自己的迷你屋中

2.用户招募+体验室的预定
用户是必不可少的，进行一场用户测试一般需要6~8人，根据具体情况可以逐情增减。用户要选择目标用户，也就是产品的最终使用者或者是潜在使用者：如年龄要符合产品的目标年龄层、男女比例要符合产品目标用户比例，并且将来会使用或者是很可能使用该产品的目标用户。根据测试目的不同，也要根据需要，选择新手用户、普通用户或者高级用户。在用户招募困难或者时间紧等情况下，如果只是简单的为了发现产品中存在哪些可用性问题，降低用户标准也是一种可行的方式：如公司内部员工充当用户等。

正规的情况下用户测试需要在体验室进行，不仅需要录音，录屏，还需要观察人员观察用户的具体操作，并做详细的记录，因此，在用户测试前需要进行体验室的预定。在非正式的情况下，一台笔记本电脑，一间会议室，也可以进行用户测试，这种测试虽然简单，但是足以完成对基本可用性问题的发现。

迷你屋用户测试的目的就是为了发现问题。公司内部员工（非互联网业务系统人员）对迷你屋产品设计始终了解甚少，完全可以作为目标用户参与测试。因此，选择用户时，选择了2名公司内部员工+2名学生用户，其中2名有旧版迷你屋使用经验，2名无旧版迷你屋使用经验。这4名用户发现的问题重叠率高，且发现的问题基本处于收敛状态（没有新问题的发现），因此，4名用户足以说明问题。

用户情况如下表：

第二阶段：进行测试
一切准备就绪，就可以开始进行用户测试了。测试时需要一名主持人在测试间主持测试，1~2名观察人员在观察间进行观察记录。测试过程需要录音、录屏，以备后期分析。测试时，尽量不对用户做太多的引导，以免影响测试效果。

迷你屋用户测试由1名主持人（snow）主持和一名观察人员（西贝）进行观察记录。主要经历了以下过程：
1、向用户介绍测试目的、测试时间、测试流程及测试规则。
2、用户签署保密协议+用户基本信息表。
3、让用户执行任务：给用户营造一种氛围，让用户假定在真实的环境下使用迷你屋。并让用户在执行任务的过程中，尽可能地边做边说，说出自己操作时的想法和感受。
举例：
假设你现在在家里上网，听你的好朋友说，迷你屋有新版本了，并且告诉你迷你屋新商城的网站是home.qq.com，您很好奇，于是敲入网址，打算装扮一个属于自己的迷你屋。
4、用户反馈收集。基于用户执行过程中的疑惑进行用户访谈，收集原因。
5、致谢！

第三阶段：测试后总结
测试后需要进行测试报告的撰写并开会将测试结果与相关人员进行分享。
主持人与观察人员要进行即时的沟通，确定致命的可用性问题与一般的可用性问题，并汇总简要的测试报告，以抛出问题为主，不做过多的建议。报告确认后，召开会议，将测试结果与产品经理、交互设计、页面制作、开发、测试人员进行分享。确定在产品发布前需要进行优化的具体问题，并将对应的问题分类，确定解决问题的关键人。（如交互设计可能需要重新设计的具体问题、产品开发人员直接在原有基础上修改等）

下例为迷你屋简要测试报告的一部分：

迷你屋经过用户测试后，将登录、“装扮迷你屋”按钮、QQ空间入口、QQ空间到迷你屋商城入口等一系列问题进行了优化。

以下为测试前后设计优化对比示例：

迷你屋装扮入口

迷你屋暂存：

小结
用户测试是一种反复迭代的过程，在进行完新一轮的设计优化后，可能还会产生新的可用性问题。因此，将新一轮的设计进行迭代的用户测试，是未来的一种发展方向。

相关话题：可用性测试源地址：http://webteam.tencent.com/?p=135

设计质量的要素

mocha — 2008-11-08 01:15:20

概述： 一项对51个网站的可用性评分显示，这些网站的导航、内容与功能特性的质量之间具有某些联系，但与其它可用性领域没有关联。

我们都知道一些用户界面设计得很不错，一些很糟糕。但为何这些设计在可用性方面有差别呢？

简单地回答，是因为一些团队有好的设计师，他们听取可用性专家的意见，并且遵从那些成文的准则；而另一些团队的设计师很差，他们没有做任何可用性工作或者干脆对那些研究成果视而不见，采用他们自己杜撰的准则去指导实践。

但是这个简单的回答却引出另一个问题：为什么一些团队比其它团队更加注重用户体验的质量呢？我想通过最近统计的一套数据来分析这个问题。

我们几乎找不到统计那些集中于同一问题的大量设计项目的可用性成果的数据。即便是为前来咨询的客户做可用性研究以提高其竞争力的时侯，我们也只测试3—4个同行竞争对手的网站，因为那些就包含了我们所需的所有可用性战略意见。测试更多的网站只会导致回报严重变少，这笔钱还不如花在对公司本身设计的反复调试上。

Pew Charitable Trusts提供的研究对来自全部50个州以及华盛顿哥伦比亚特区的选民信息网站进行了可用性评测。这项研究产生了我们这份对51个相似网站的可用性评分。

由于各州的选举法有所区别，这些网站在字面上也不尽相同。但是它们的相似度已足够高，可以进行比较。例如，各州对于申请缺席选举人投票的截止日期不同，但是所有州都必须公告包括相关截止日期在内的关于申请缺席选举人投票的规则，同时给选民提供申请的途径。

可用性得分分布

下面的柱状图显示了这51个选民信息网站的可用性得分分布。可用性分数范围为0%到100%，分数越高，可用性越强。

注意，满分并不意味着该网站具有完美的可用性。100%的分数只能说明，该站点在我们现有技术条件下所有的可用性评测项中拿到满分。实际上，在我们的研究中得分最高的网站也只得到77%，选民信息网站离最好的商业网站还有很大一段距离（电子商务网站通常有较好的可用性，因为如果人们不能在那购物它们就得关门了。尽管政府网站同样关注可用性，但这并不关系到组织存亡）。

51个选民信息网站可用性得分柱状图。

这个柱状图显示了一个较为正常的可用性得分分布：大部分网站的可用性位于中等水平。有3个网站的得分超过70%，其可用性令人满意。然而可用性差的网站更多，有8个网站得分低于40%。但至少还没有哪个网站的可用性差得一塌糊涂。最低的得分是29%（已经很差了），但即便是这样一个网站，最有毅力和最熟练的用户也依然能够完成任务。

可用性的核心要素

你可能认为，如果一个设计团队在可用性的某个方面表现得很好，那么它在其他方面也会同样出色。事实并非如此。

我们的数据显示，针对不同的问题，所能达到的可用性质量水平之间没有什么联系。若用相关性来统计它们之间的相关程度，则很多相关性都接近于0，完全微不足道。

也就是说，如果一个设计团队在可用性的某一个方面表现得好，它在其他方面表现优劣则完全未知——也许不错，也许很糟。

调查结果有两个例外：

导航和信息架构的质量与内容可用性的质量之间有0.54的正相关性。
导航和信息架构的质量与建站工具的质量之间有0.40的正相关性。

（注意：相关性范围为从-1至+1。相关性为0代表两个变量之间没有关系。正相关是指一个变量随着另一个变量增加（减小）而增加（减小），这种关系越强烈，二者相关性越接近于1。相反的，负相关表示两个变量的变化方向相反，一个变量增大时，另一个变量减小。）

下面的散点图显示了导航质量和内容质量之间的关系：

在上面的图表中，每个点代表一个网站。（一些网站在可用性的这两方面得分相同，则两个点的位置相同，故而显示为一个点。这就是这个图里看起来少于51个点的原因。不过我计算了所有51个点形成的趋势线，不管它们能不能被看到。）

导航质量和内容质量之间的相关性值p<0.001，这一点相当重要。（同样，导航质量和建站工具质量之间的相关性值p<0.01。此处不再展示第二个散点图。）

这个结果表明，确实有网站在尝试完善可用性的核心要素：用户如何使用网站，他们会找到哪些内容，以及所能提供的功能特性。这个现象很好，因为这些确实都是很重要的问题。一些团队对可用性的核心领域了解很多，而另一些团队则好像就拿Dreamweaver胡乱拼凑一通了事，构建一些组织随意、信息量少的无用网站。

然而，即便是可用性的核心要素，它们之间的关系也并不那么强烈：0.5左右的相关性表示某一要素被另一要素影响的程度只有1/4，剩下的3/4被随机决定。因此在某一方面出色仍不代表其它核心方面的大部分问题已被解决。

被忽视的可用性要素

根据我们的统计分析，很多可用性要素与可用性核心要素完全无关。这些要素包括：

首页可用性
搜索
可访问性
网站出镜率（即用户如何从别处知道并进入这个网站，也即”更大范围的可用性”）

这些重要的质量要素之间的相关性很低（有时甚至呈负相关），而且它们与可用性核心要素的相关性也很低。

例如，首页可用性与可访问性的相关度r=-0.1。

负相关并不意味着可访问性与好的首页设计势不两立。记住：我们评估的是首页的可用性，而不是首页是否有华丽的外表或功能复杂的Flash动画。（后者经常使可用性和可访问性降低，因为网站往往错误地使用了它们。）

相反，负相关表明设计师并没有把可访问性当作用户体验质量的组成部分。更可能的是，政府机构将精力更多地集中于使网站符合法律对于可访问性的规定，而不是让网站更方便残障人士使用。

对于低相关性或负相关性，我的解释是，许多重要的可用性要素在设计项目中未被优先考虑。一个网站的可用性非核心要素的最终结果的好坏是随机的。

说它“随机”，并不意味着设计好坏由掷硬币决定。我指的是当设计团队中恰好有一个人了解可用性非核心要素的高质量用户体验的重要原则，这种情况只是一个巧合。

一个在可用性基本要素上做得很好的网站可能因此完全忽略许多其它的Web可用性要素。相反，一个在可用性基本要素上做得很糟的网站也许足够走运，如果他们恰巧有一个了解其它可用性要素并且擅长在那一领域建站的设计师。

从下面的柱状图可以看出，相对于刚刚看到的整个网站的可用性分布图(这篇文章的第一个图)，51个网站的首页质量分布更为分散。一些网站的首页糟糕透了，但是其他一些接近达到当前所有最佳实践。

51个选民信息网站的首页得分柱状图。

这些相关性显示，首页得分的高低与这个网站在其它方面的质量无关。这就是为什么整体可用性等级主要集中在中间水平的原因：它们包括了各种可用性要素或高或低的分数。

因此，大部分网站都是既有做得好的地方，也有让用户崩溃的地方。客观地说，平均起来大部分网站的可用性通常位于中等水平。但是对用户来说，好的设计和差的设计混杂在同一个网站，通常让人觉得太过随意，像是没有尽全力提供服务。

好的用户体验需要整体观念

“完全用户体验”这个概念是指包含用户碰到的所有情况，其产生是有原因的。用户界面设计某个部分很好是远远不够的。比如，好的导航当然是好的用户体验必需的，但不是用户体验的全部。如果首页很差，用户可能在使用导航之前就离开网站了。

我们可以把网站的用户体验比作个一条链子，整个链条的强度取决于最弱的那一环。任何一个可用性要素做得不好都将导致整个用户体验崩溃，丢失大量用户。

如何保证完全用户体验的质量呢？你需要站在用户角度的可用性整体视角，而且你需要以用户为中心的设计为原则建设网站。

经常有预期客户要求我们对他们的网站或内联网的某一要素提供帮助。例如，他们通常想改善其信息架构（IA）。这确实是有价值的要求，而且对网站帮助也很大。但它是导致商业价值链条断裂的最弱那一环吗？也许会也许不会。寻求答案的唯一方法是从最初的原则入手提升整体用户体验。

不要过于纠缠用户体验的某一方面，不管它多么重要。我们需要的是整体视角，别让重要的要素受到冷落。

精简版可用性测试：尽信书不如无书

笑炊 — 2008-11-11 23:24:45

译者：UCD翻译小组，笑炊
原文链接：http://www.uie.com/articles/usabilitytesting_dc/

人们经常对我说，"我想在公司里做可用性测试，但是没有足够的时间按照您书中描述的正规步骤来执行。所以，既然我们不能把它"做正确"，干脆就一点也没做"，接下来他们通常会说明这种情况是多么令人沮丧。他们很困惑。
他们提到的那本书是《可用性测试手册》第二版，由我和Jeff Rubin协作完成，威莱出版社2008年4月出版。正如你预想地，这是本关于怎样计划，设计，执行有效的可用性测试的操作指南，有350多页。
同样地，就像每一位高中代数老师所做的，Jeff和我先是让读者"走了很长的路"。这个观念是，在学习了标准的方法以后，他们能找出对他们有用的捷径和变通方法，并且得出了同样"正确"的结果。我们期待，在学习了标准的方法以后，他们能够因地制宜地简化和变通这个流程，并且获得"正确"的结果。只要可用性测试只要能够帮助改进他们的设计，就足够了。
不用照搬书上的流程，你也能得到有用的数据，但是这样得到的数据和正统的方法得到的数据是不同的。你必须选择一个折衷的方案。你一定要清楚这些数据从何而来，意味着什么。你可以进行快捷，廉价的可用性测试，获得关于你的用户和你能处理的设计的所有认知。
因此，我建议我的读者摆脱这本书（在他们购买，并读完之后），做适合他们自身情况的相应水平的可用性测试。我刚刚提到了折衷方案，下面我们来看看下面三种方案各有什么取舍：不做测试，照搬书本做测试，和恰到好处的测试。

不做测试：意见纷争

当我听到有团队不做可用性测试时，就很好奇他们做设计的基础是什么。而当我去询问时，常常得到一大堆混乱的答案，从"CEO希望这样"到"市场调研告诉我们"到"我们在团队会议上头脑风暴过"，他们给我的感觉是：他们是在猜测答案。多数的市场调研过程中，一些团队可能在并没有客户数据，当然也没有网页分析数据的情况下，开发出了新产品。新兴小公司开发新产品常常走这样的路子。就我对新兴小公司的了解，他们的设计决定通常取决于谁拥有最强有力的观点，最大的影响力，或者这两者的结合体。
一些团队可能做了市场调研。另一些也可能有可用的用户访问记录，也许还有些网页分析数据。我遇见过这样的一些团队，他们的设计依赖于首席工程师或者产品经理的孩子，母亲，叔叔，上一任老板，竞争对手的眼光。
如果一个团队设计的产品只是给产品经理的叔叔的上一任老板用的，没问题，他们凭这个来做设计就够了。但是，就算刚刚说的数据（市场调研，用户访问记录，网页分析-数据和大叔大伯们的观点）都凑在一起，也不够他们弄清楚一个真正的用户如何在真正的环境中解决真正的问题。
如何解决互相矛盾的观点，并弥合差距？去观察用户如何使用你的设计！

照搬书本做测试：详细数据来自于缜密的研究

为了远离意见纷争与猜测，最好的团队使用数据作为设计的基础。一种可行方法是通过标准的可用性测试进行彻底而缜密的调查。
现在你想象有这样一间实验室，到处是录像装置，一个类似实验的测试稳定产品的环境，研究员机械地执行任务并收集数据。其实，就算是真正严谨的可用性测试也不会是这样。
Jeff和我使可用性测试看上去就像在我们书里进行，而事实也是如此。在某些背景下，为了更广泛的发现需求，满足管理期望，同时确保可靠性，执行这些步骤是必要的，你可能也在想，我根本没有时间去做那些。我们还要交付产品！那么先听下这一点：你没必要完全按书里讲的流程来做。

恰到好处的测试：快速洞察力

即使是团队不做标准的可用性测试，他们仍然需要为做出设计决定进行观察。进行简单的可用性测试的秘诀是，你可以遵照最基本的方法进行，只是有些不太正式。姑且叫精简版可用性测试：坐在某些人旁边，观察他们如何使用你的设计。
这样做测试的团队并不需要实验室。他们通常也不记录任何东西。但是他们保证团队里每位成员都在场，而且在每段时间里，至少有一位成员和用户交谈。他们把场景选在咖啡馆，商场，展览会，街道集市，甚至他们自己的接待区----用户可能在的任何一个地方----尝试在几分钟令人愉快的询问过程中，获取新鲜的东西。
这是快捷的，廉价的，和富有洞察力的时间。因为这些聪明的团队能够在几天，而不是几星期内获得一定的观察结果，只要在能力范围之内他们就会进行新一轮测试。他们重复这些步骤直到发现某些问题的苗头，然后在这些问题再次或多次出现时做出修改决定。

关于最好的团队的思考是，有了一些观点总不会比一无所有要糟糕吧？至少他们走出了办公室，也许还对设计中的小问题进行了实地检查，并
开始坚持和用户保持更多的联系。对我来说，这听起来要比意见纷争好地多。

相关话题：可用性测试 UCD翻译小组源地址：http://ucdchina.com/post/1080

10个提高可用性的救命方法

mocha — 2008-12-16 21:54:41

你工作数月并向客户交付了产品。最初的反馈还不错，但是当他们研究了几日后，却又提出要求：“你能再让这个设计对用户更友好一些吗？”天哪！这时候再重组结构有些为时已晚。但当然，你肯定可以做点什么！这篇文章就给你提供10个提高可用性的方法，在你觉得为时已晚的时候可以派上用场。

80/20法则 (The 80/20 Rule)

80/20法则众所周知并被广泛应用——在这个例子中则是这样的：

80%的时间花在了20%的功能特性上
80%的错误是由20%的交互活动引起的

所以，你要做的第一件事就是找出用户最关心或者最可能引发问题的那20%的特性。有很多种方法：直接问用户（我知道这很疯狂！）、观察他们使用产品的过程、或者你可以把日志功能加到应用程序中（这也许是最可信的方法——用户认为他们想要的往往和他们真正想要的相去甚远）。

当你找到这些特性，就可以专注于改善它们了：

如果这些特性使用频率很高，试试看如何让它们更容易被用到。比如使它们的图标更醒目、添加快捷键等。
如果一个用户在某处被卡住了，试着确定一下原因；这里是不是有晦涩的术语？下一步的提醒是不是太过模糊？

把注意力集中在20%的特性和问题上，整体上可被感知的可用性会极大的提高，因为你把注意力放在了最重要的地方。

Open Office工具条显示了最常用的命令，可以方便快捷地使用对应的功能

增加可用性效果的美感 (Aesthetic Usability Effect)

让你的应用程序漂亮一些。当你的用户要求提高可用性时，也许他们背地里叫喊的是让它不要那么丑！

有一个很著名的现象，吸引人的应用或产品被认为比丑陋的那些更好用也更友好。所以可以向设计师寻求帮助，整理下CSS，你会惊讶的发现你的应用程序变得更加友好了——让它更漂亮些吧！

加入限制 (Constraints)

加入一些限制，阻止他们以你不推荐的方式使用应用程序，确保他们只输入有效的数据。这可以减少错误而且使交互更直观。有很多种方法：

如果数据库的某一列仅允许输入有限的字母——阻止用户超过限制。阻止他们犯错比直接扔出一句“错误”好得多，更糟糕的做法是截短用户的数据。
如果某字段仅接受数字，最开始就不要让它接受字母！不要等到验证输入时再告诉用户他们做错了！
如果让用户输入一个被分隔的字段（比如MAC地址、序列号或者信用卡号），不要让用户去猜在哪里输空格、冒号或者连字符等等——每一部分分配一个字段，并在之间加入不可编辑的分隔符。

Windows XP产品序列号的对话框解除了是否需要输入破折号的疑问

你不应让用户输入“1”、“0”或者“真”、“假”来表示布尔值；你应该使用复选框！所以，使用其它控件如滑动条或者拨号盘来输入数据，使用户无法输入无效的值。
如果某一空间当前不可使用，把它变灰或者直接移除。不要让用户点他们不能点的按钮。

遵守CRAP准则 (Make it CRAP)

这其实包括4件事情，但将它们的首字母缩写词作为10个方法里面的一条。CRAP是图形设计领域的四个准则的首字母缩写词：对比、重复、对齐和近似。我写了一篇深入研究CARP以提高用户体验的文章：《如何让你的用户界面符合CRAP》。这些原则应用起来很简单，并且不费什么力气就可以带来巨大的改变。

减轻用户负担 (Lighten the load)

处理大量信息增加了用户的认知负担，并且也使你的应用程序难以使用。认知负担是完成某一任务时大脑活动的总和，包括记忆、感知、思考/理解等等。你可以减轻用户负担而使应用程序更加友好，步骤如下：

尽可能少问问题。过长的表格，问过多的问题都会吓到用户。用户对于填表的态度是能不填就不填。在用户可以将来再填详细信息的地方，让用户填尽可能少的内容以帮助他们继续下去。

在Base Camp上创建一个新项目。仅需填名称和参与人员两条。其他都可以以后再填。

当你需要很多信息并且不可以放到将来再填时，把表格切分成几页，然后让用户一页一页来。确保向用户标示出了进度，让他们知道已经完成了多少。
删除不必要的信息。显示的每一处信息都是有助于理解，而不是让整个界面凌乱不堪。如果没有相关或者附加价值那就删除它。
如果可以的话，在某一字段的附近增加必要的解释，这样用户不用思考它的含义了。当处理技术术语和首字母缩略词时这一点尤为重要——如果用户以前没听说过这些词，必要的解释可以降低用户的挫折感！上面Base Camp的截图就是个好例子，它给“Name the Project”的意思加了解释。

使用更少的文字 (Use less words)

用户很少看文字，少到让你惊讶的程度。你的应用程序并不算新鲜事——如果它有很多描述性文档，用户是不会阅读的，而且大量的文档会吓到用户并让他们觉得你的应用程序非常复杂，难以使用。大部人只会点击“确定”或“下一步”，并期待得到最好的结果。如果这样做错了他们会感到很愤怒。

如果你需要鼓励用户；那就使用积极的词语。不需要太礼貌，那样不够精炼。比如不要给某字段加这样的标签“请输入您的全名：”，直接写“全名：”。用户不需要这么礼貌的语气来告诉他们输入，没有这个必要——用户不会理那些花哨的描述，即便他们可以——你的标签是不是已经阻止他们填这一项了？如果有太多内容根本读不过来，那就存在重要信息被忽略的风险。

折线之上 (Above the fold)

“折线”(fold)是报纸版面设计的术语。按字面理解是指报纸被对半折起来的折痕。折叠之上的信息更加醒目，因为人们不用展开报纸就能浏览。这个术语在界面设计领域也有相同的意思，是指不需要移动浏览器的滚动条就可以显示出来的区域底部。

考虑重新布置页面，让用户不需滚动鼠标就能看到最重要的信息。如果干脆去除滚动条是不是更好？
一些应用程序把出现的错误统一显示在页面最底端。从用户的角度考虑，他们点了“提交”，但是同样的页面又显示出来。当他们想到把页面滚动到最底端之前，他们已经觉得你的产品有问题而不是他们的操作有问题。所以，把错误信息放在页面靠上方的位置（更理想的是，放在错误出现的附近，但确保页面滚动到那一位置，这样才能被看到）。

排序与分组 (Sorting and Grouping)

组织信息的方式极大程度地影响着可用性。分组的应用范围很广——从你的菜单项目顺序到你提供的工具列表。

5 Hat Racks原理描述了5种组织信息的方法：

按字母顺序排列：简单的按字母顺序排列。当信息不能以更有意义的方式组织或者用户需要迅速找到某一信息时，这种方法很有效。可定制排序的菜单经常包括这一排序方式。
按位置排列：根据信息的物理位置排序。如果你的信息和真实世界关联，那可以采用这种方法，用图来显示它的物理背景信息。
按时间排列：以时间顺序排列。当你的信息与日期或时间关联时，就要采用这种排序方式，确保用户可以以时间顺序浏览信息。
按类别排列：根据信息之间的共同属性把它们分类。分类标准可能是包括“它们是什么”（比如是书籍、DVD等等）、“用途”（比如感冒药、洗发护发产品等）、“颜色”、“气味”等等。分类法非常适用于从用户角度分组的菜单，比如把财务信息分成预算、订单、发票几类。
按连续性排列：把信息排列成连续的一系列。顺序可能是从好到坏、从高到低、从流行到不流行等等。如果有衡量的标准，就提供这种分类方式。

看看你是如何展现列表和菜单的，想想信息的作用和用户会通过什么方式找到它。用户获取信息的方式会随着他们当时想做什么而改变。如果你的应用可以根据用户当前的目标而改变信息组织方式，那将会获得用户的高度评价。

包容 (Forgiveness)

提高应用程序用户友好程度的一个好方法就是使它更加包容。包容是指提供多种途径，以减少用户犯错的机率，或者在用户犯错时降低其不良影响。

撤销：当用户不喜欢某一操作所带来的影响时，允许用户改变主意。在开发的后期，这也许很难进行改造，但它确实是使你的应用程序更加包容的最佳方法中的一种。

当你在Gmail里删除一封邮件时它并不会让你确认，但它会让你可以轻松改变主意。

确认：把操作变为两步，提示用户对他们请求的操作进行确认。确认这一操作如果被用得太多，会让界面失调，让用户厌烦。如果操作很容易被撤消，那么你并不需要确认这一步（例如Windows XP中的“你确定要删除该文件吗？”对话框并无必要，因为文件可以轻松地从回收站里找回）。你不需要那些只包含“确定/取消”按钮的对话框来增加确认这一步操作，这只会成为类似于“预备/射击”这种感觉的额外操作。我写过一篇文章，论述Gmail对确认操作的创造性用法，原谅用户，哪怕他喝醉了！
警告：显示警告以提示用户操作的影响。这是最没有侵入性的提高包容程度的措施，你可以在页面环境中增加信息以解释当前被选中的选项。

Feedburner在确认按钮附近显示警告以警示你操作的影响而不打断你的操作过程

帮助：最后，你可以把帮助和说明放入你的应用程序以增加其包容程度！在你发现设计中一个不可逆转的错误，需要解释程序如何运转，以及这跟它应有的样子有何区别时，这个方法尤其重要！至少在你解决问题之前！

空状态 (The Empty State)

这是被许多软件忽略的一点，却是改善你的应用程序的一种真正简单的方法。当你测试或展示你的应用程序时，它充满了测试数据。然而，当一个新客户第一次使用的时候，它是空的！你知道那块缺失的区域会填入一些信息，底部的大列表会包含不确定信息(doobery) ，以解释这是什么，但你的用户不知道！如果用户不知道一个东西是什么或者应该是什么，他们就会疑惑。你可以通过以下方法帮助他们：

不要在没有数据的情况下什么都不显示，使用一些用来占位的东西，如“没有可显示的不确定信息(doobery)”。
如果这是用户第一次来，告诉他们这个区域将要显示的内容的特征。

Basecamp显示的最后的空状态。它是空的，但包含了很多信息，所以你确切地知道下面会有什么！

使用示例数据给用户提供一个预先填好的选项。如果数据准确且对用户有意义，那么这还真是一个好方法。它可以让用户看到一些实际使用中的具体数据。不过，当用户对程序有一些感觉之后，要确保用户可以轻松地除去这些测试数据，当他们一条一条地手工删除可不会让他们对你产生任何好感！

结论 (Conclusion)

如果可用性在整个开发过程中都被充分考虑，那么产品只会越来越好。然而，总会有其它一些压力，而且当你发现自己遇到上述种种情形，知道这些压力并不能为你帮上什么忙。我们希望，这些技巧可以让你在觉得提高可用性为时已晚的时候，为你提供一些进行简单调整和重组以改善程序可用性！

你曾经遇到过这些情形吗？你如何改善你的应用程序的可用性呢？