基本原则7: 传递信息，而不仅仅是数据
基本原则8: 设计应满足响应需求
基本原则9: 通过用户试用发现错误，然后修复它
7) 原则7: 传递信息，而不仅仅是数据
计算机承诺了一种信息来源。但是它们主要传递的是大量的数据……绝大部分都是无用数据。数据不是信息。人们需要从数据中提取信息。
软件应用程序通常把数据当作信息。它们把数据都扔给你，让你自己查明它们意味着什么。软件应当将用户的注意力集中到重要的数据上，并帮助他们从中提取信息。
7.1 认真设计显示，获取专业帮助
基木原则2提到: “首先考虑功能。然后才是表示”，但是在任何软件开发工作中，我们有时必须在考虑如何表示软件的控件和状态的同时，也考虑用户的数据。在这种情况下，设计人员应当非常慎重且认真地考虑屏幕设计。我们的目标是:
- 视觉顺序和用户焦点: 成功用户界面设计并不只是简单的表示。它将用户的注意 力转向重要的内容上。
- 易于浏览: 计算机用户很少仔细阅读屏幕；他们通常快速浏览以查找符合他们目标的信息。因此,要将屏幕设计成易于浏览。不要使用大段的文本。要将信息分割为标题、要点、列表和表格。在可能的地方用图形来显示信息。链接标 签要短。
- 匹配介质: 糟糕的用户界面设计的一个特点就是设计与表示介质的局限性不匹配。设计良好的用户界面却能够很好地匹配它们所使用的介质。
- 注意细节: 成功在于细节。这一点在信息表示的设计中尤为正确。雇佣用户界面 和图形设计人员可能看上去需要很高的费用，但他们可以注意到其他开发人员很 少会注意到的细节，这样很容易就回报了雇用他们的成本。当程序员必须在没有 设计专家支持的情况下工作时，至少要将用户界面的设计安排给注重细节的人员。 否则产品中可能犯下许多GUI缺陷或者错误。例如不一致的显示、设计不一致、难辨认的符号以及总体上不专业的外观，这可能妨碍产品的成功。
7.2 屏幕属于用户
有效的GUI原则是“屏幕属于用户”。图形用户界面建立在用户直接操作数据的基础上，这也是用户所期望的。如果软件主动改变得太多，用户就会变得混乱和烦恼。
考虑屏幕指针。移动屏幕指针是个手眼协调的过程。当用户学会使用鼠标或触摸屏之后.移动指针就变成了反射，即更多由“肌肉记忆”控制，而不是由“知觉意识”控制。用户的意识就有空去考虑他们的任务。软件自动的、单方面的移动指针破坏了”手眼”协调，引起了混乱并将用户的意识猛拉回到控制指针的工作上来。用户不能确定哪些指针移动操作是他们的行为结果，哪些是计算机的操作。
这个原则可以推广到屏幕指针、窗口和控件以外.包括桌面图标、项目列表以及人们操作的其他类型的数据。软件应当避免“帮助”用户重新布置他们的数据。它应让用户安排和管理自己的数据。
7.3 保持显示惯性
与“屏幕属于用户”这条原则紧密相关的是“显示惯性”原则。
当软件改变一个显示以显示用户操作效果时，它应当设法将它改变的内容减至最少。局部的小的数据变动应只在屏幕上生成小的、局部的改变。当用户改变屏幕上的一些东西时，应尽可能多地保持屏幕不变。
如果不能将显示中的改变限制在实际发生改变的地方。那么会令用户非常混乱。
- 培养用户对更改的认知和理解。
- 最大限度地减少对用户继续工作能力的破坏。
8) 原则8: 设计应满足响应需求
过去40年间所积累的大量证据表明，响应性(即软件应用程序跟上用户，不让他们等待的能力)是确定用户满意度的最重要因素。它不仅仅是最重要的因素之一，而是最重要的因素。
8.1 什么是响应性
响应性与性能相关，但它们是不同的。交互式软件可能有很高的响应性，但性能可能很低，它也可以具有低响应性和高性能，性能是以每单位时间的计算数量来度量的。响应性是以是否符合人的时间豁求(最终是满意度)来度量的。
8.2 设计应满足响应性
为了让用户感知响应性，交互式软件必须:
- 对用户操作即时做出应答.即使返回答案需要一定肘间。
- 让用户知道系统何时忙碌，何时空闲。
- 在等待功能完成期间允许用户执行其他操作
- 让动画的移动变得流畅清晰。
- 允许用户放弃他们不想再执行的兄长操作
- 使用户能够判断操作将花费多少时间。
- 尽可能允许用户设置他们自己的工作步调。
就像用于控制航空器的软件一样。与人打交道的软件也需要满足实时性约束。人类行为中反映的三个常t给计算机系统响应性设立了必须要达到的目标：
- 0.1秒: 这是事件的因果之间的感知界限。如果软件对用户的动作在0.1秒之内没有 做出响应，那么因果感知就被打破； 用户不再将显示出的反应看作是自己动作的 结果。因此，屏幕上的按钮有0.1秒的时间来显示它们被点击了;否则用户将再次 点击。如果用户正在拖动的某个对象滞后于光标0.1秒，用户在放里此对象时就会 有麻烦。HCI研究员Stuart Card将0.1秒的时间界限称为感知“瞬间”。它还是平滑 动画被感知的近似界限:0.063秒/帧(16帧/秒)。
- 1秒: 这是对话中近似的正常时间间隔值。当间隔超过1秒时，为了使对话继续进 行，其中一方一定要说点儿什么，即使仅仅是“嗯“或“啊哈”之类的词。类似 地，软件也有大约1秒的时间执行用户的要求，或显示需要多长时间;否则，用户 就会失去耐心。一秒钟也是人们对突发事件做出反应的近似最小响应时间，就像 司机对一个小孩突然跑到汽车前面的反应。在人机交互中.当信息突然出现在屏幕上时。用户至少需要1秒时间做出反应。
- 10秒: 在这个近似时间单位里。人们经常会放弃计划或中断对一个大任务的执行。Card和他的同事们称之为“单元任务”时间常量，在这段时间里。人们可以将精力全部集中于一个任务上。每过10秒钟左右，人们便会停下工作。重新估计一下 任务的状态和周围的环境，放松一下或是做点儿其他什么事情。10秒钟以后，用户会将一个单元任务结束，然后开始下一个。在各种各样的工作中都能观察到这 时间常量，比如在文本编辑器中完成一次编辑、向查账程序中输入一个账单、以及在飞机空战的时候执行一个战斗策略等。在人机交互中，对于文件传输或搜 索这类“繁重”的计算机操作，10秒钟差不多就是用户愿意花费在启动操作上的 时间了。如果在这段时间内任务还没有开始，用户就会失去耐心。计算结果本身 可以花费更长的时间(假定在提供了进度反馈的情况下)。
说明：平滑动画可以被感知的最大帧间隔小于0.1秒：实际是0.063秒(16帧/秒)。
驾驶时对突发事件的反应速度小于1秒：实际是0.7秒。
最后，10秒时间常量，是在5~30秒之间的几个心理时间常量的近似值。
这三个时间量是在人们的感知、运动和认知任务中观察出的大量更精确时间常量的一个近似结果。它们用于指导用户界面设计已经足够了。将它们设置为0.1秒、1秒和10秒是为了便于记忆。
9) 原则9: 通过用户试用发现错误，然后修复它
大多数计算机从业人员都曾听过“早测试、常测试”一这句话。虽然计算机软件和硬件有各种不同种类的测试。但本书主要涉及易用性浏试，即让产品或服务的目标用户进行试用，以了解他们在学习和使用过程中有哪些问题。这样的测试对于确定设计是否成功尤为重要，也就是确定该设计是否对用户的帮助大于阻碍。
9.1 测试结果甚至可能令经验丰富的设计人员大为惊讶
开发人员可能从易用性测试中得到出人意料的结果。有时这样的结果甚至会令用户界面专家大为惊讶。
我经常在软件产品或服务的UI进行用户测试之前对它们进行评审。对UI进行预先评审为我提供了很多思路。包括如何设计测试、去查找哪类问题，以及如何解释用户将会遇到的问题。然而，执行测试后几乎总是会暴露一些我未曾预料到的易用性问题。
例如，某公司开发了一种用于分析服务器集群性能的软件。此软件能够将服务器集群的性能作为并发用户数的函数来绘制图形。用户可以指定图形的类型: 条形图、线型图等。缩略图表示当前被选中的绘图类型。令人惊讶的是，易用性侧试显示，许多用户把用于表示绘图类型的缩略图当作了实际的数据图形！ 因此。测试总是有用的。我们永远不会知道将从测试中学到什么，但我们肯定会学到一些有助于改进软件质量的知识。
9.2 为纠正测试所发现的问题安排时间
当然，仅仅测试产品或服务的易用性是不够的。开发人员还必须在开发时间表中为纠正测试所发现的错误提供时间。否则测试又有什么用呢?
9.3 测试有两个目的:信息目的和社会目的
- 信息目的：易用性测试的信息目的是众所周知的: 找到导致用户困难的用户界面问题，并利用准确的问题性质来提出改善建议。信息目的可以通过广泛的测试和数据收集方法来实现。其中有些方法昂贵且费时.而有些方法则廉价且快速。
- 社会目的：a) 易用性测试的社会目的至少与信息目的同等重要。它用于使开发人员确信有一些重待纠正的设计问题。开发人员经常对修改建议有抵触情绪。部分原因是需要付出时间和工作量，还有部分原因是需要改进某项设计，意味着设计它的人员当初的工作没有做好。为了实现测试的社会目的，最有效的方法是让开发人员观看易用性测试。可以实时观看，或观看测试录像。
b) 开发人员在看到用户遇到软件使用问题时可能会情绪激动。因此，当开发人员亲自观看测试时，务必要提醒他们冷静地观看。
c) 除了使开发人员确信需要修复易用性问题以外。强调易用性测试的社会目的还有其他的好处。它还能够使开发人员更容易接受“易用性测试是一种重要的开发工具，而不是用于评估GUI开发人员的方式”这种思想。最初不愿意进行易用测试的程序员在观看了一些(痛苦的)测试后，态度往往发生了转变。在后来的项目中，他们积极地请求将易用性测试作为获得反馈的方式。
9.4 在不同时间、针对不同目的进行测试
很多计算机业内人士对于易用性测试有一种错误认识，他们认为应在软件产品或工具快要准备好移交时才进行测试。并且要使用面面俱到的测试设施和设备。事实上，易用性测试有多种方式，各有利弊。
易用性测试可以按照两个独立的维度来归类: 1)在开发中执行测试的时间点；2)测试方法的正式程度。测试可以在尚未编写任何代码之前进行、可以在只实现了部分软件时进行。也可以在软件几乎完成后进行。
测试方法可以是非正式的、准正式的或正式的。面谈、调查、自然观察和现场研究都是“非正式的”。用户执行规定任务并在测试中收集定性数据和t化数据的测试称为“准正式的”。主要度量量化数据并需要进行统计分析(通常对不同的设计进行比较)的研究则是“正式的”。各个实现阶段和正式程度可以任意组合。
GUI设计9个原则(第一篇)：
http://blog.csdn.net/sanqima/article/details/45598999
GUI设计9个原则(第二篇)：
http://blog.csdn.net/sanqima/article/details/45601815
翻译文献：Jeff Johnson. GUI Bloopers 2.0 Common User Interface Design Don’ts and Dos. 2009