基本原则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帧/秒)。
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 测试有两个目的:信息目的和社会目的
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
原文地址:http://blog.csdn.net/sanqima/article/details/45602855