可用性的维度（5E）

可用性的维度

当我检查可用性文献时，我发现可用软件包含如用户友好、易学、可发现性、质量、有用的和阻止错误。在可用性工程中， Jakob Nielsen给出一个产品的五个属性：易学性、效率、可记忆性、容错（低错误，容易恢复）和满意度。从个人观点，我认为有：

• 有效性（Effective）
• 效率（Efficient）
• 吸引的（Engaging）
• 容错（Error tolerant）
• 易学（Easy to learn）

首先，使用首位字母都是E的词刚开始看作是一个游戏，但我一样想寻找一个方法来使可用性的维度方便记忆，因而5E诞生了。

有效性

有效性是第一个E。主要代表软件是可用的，并且帮助用户准确地实现他们的目标。若是用户不能实际完成他们准备作的事情（或作了没必要要的事情），不管体验的长短都失去了意义。最后用户没有完成任务或达到他们的目标。若是设计者可以测量有效性，就能够理解人们如何定义成功或有用。

效率

效率是所作工做的速度（与精确性要求相关）。效率能够被详细地定义。例如，在一个呼叫中心，衡量客服人员一天能处理的呼叫数量。或者它是一个主观的判断，当一个任务执行“太长“或须要“太多的点击“。

吸引

关于吸引的简单定义就是一个界面的愉快、满意或兴趣程度。全部的软件都会给用户带来情绪上的影响，但这个维度的重要性随着程序的类型会发生变化。在一个办公软件中，一个吸引人的界面可使人投入工做，帮助他在工做中创建信心，或在表达信息方式上特别容易阅读。这个可视的表示和风格或交互的质量都会使软件更加吸引人。

容错

容错包含产品防止错误的程度和帮助用户从错误中恢复。轻触鼠标就会点击一下。若是你错读了一个链接，须要按原路返回，或输入相关内容。实际测试是在错误产生时了解软件如何进行帮助的。

易学

易学和产品如何支持初次使用和更深度的学习相关。一个产品可使用一次，或一下子，或一天。它能够完成一个容易的或复杂的任务，用户多是一个专家或新手。但每一次使用，界面必须可以记忆或从新学习，并且使用一段时间后可以发掘更多的功能。

平衡的问题

若是在每一个产品中，对于每一个用户，可用性的每一个要素都是同等重要的，那么就会出现图1中的情景，但实际状况显然不是这样的。并且这个提供了一个机会来能够更好地理解一个产品的可用性需求。在5E中的平衡能够肯定界面设计的方向。换句话说，能够理解可用性依赖哪些内容。在表1中，咱们能够看到一个利润管理业务的两类用户一个雇员和一个利润专家——他们有不一样的须要。对于两个用户，都必须具备有效性，但利润专家的需求更多地放在效率上。对于雇员，效率与易学、容错和软件吸引人的程度相比，要被放在一个次要的地位上。
经过可用性进行思考带来的价值要比简单理解用户的利益走得更远。它能够做为项目管理的一个工具，帮助选择项目过程当中用于用户研究和可用性评估的技术。它能够在必要时进行平衡，给出设计方法和辨别方向。

一个以用户为中心的步骤

大多数UCD过程都符合ISO13407的通用纲要：在交互系统中以人为中心的设计过程。以一个发现过程开始，而后在研究——设计/原型——评估步骤中循环直到项目完成。整个项目建立出一个设计步骤，而且测试确保任务的结构和组织是正确的。而后，用一样的迭代进行分析、设计和评估每个功能与设计，直到全部的功能都被集成到整个设计架构。最后经过可用性测试完成对软件发布前的检查。在整个生命周期均可以应用这些过程，将可用性和交互设计工做嵌入到过程的全部阶段，从最初的产品概念一直到整个开发周期（见图2）。

固然，UCD工做的强度是不同的——在设计阶段高，在实现阶段低。在每个阶段，团队必须决定哪些UCD活动能够最好地支持产品。

依表进行设想

设计者不是在每个新项目中都是一张白纸。不管项目是一个已有程序的新版本，仍是彻底是一个新产品，团队都会在工业或商业领域中工做过。团队有过成功的经历，固然也有问题（或彻底直接的失败），并且他们都会有设想，也会把过去经验的带到新项目中。制做一个表格采集这个信息。并且由于团队须要给出愿景，因此构建了一个用户和可用性需求的蓝图。
表1不一样的用户，不一样的可用性需求

雇员
利润呼叫中心专家

公司的全部雇员，必须在他们的我的信息或利益选择中使用利润管理业务。他们并不常用这个应用。在这个业务应用以前，他们一般要经过访问HR部门和在利润专家填写的模板基础上进行一些修改。他们常常不肯定一些选项，并且担忧作错什么会破坏他们的信用。他们须要：

• 好的指令，以替代我的访问（帮助，体现易学）
• 确认不只他们的数据更新，并且和这些变动的相关利益（容错）
• 确保整个过程当中和在他们的入口中是精确的（吸引人的和有效的）。

这个公司有一个呼叫中心，利润专家能够在此处支持有困难的雇员。他们也完成一些雇员本身完成不了的一些过程。他们在业务中心天天工做，常常重复回答一样的问题，并且大多数呼叫都使用同一个界面。他们须要：

• 快速完成平常工做（效率）
• 在一个简单界面中看到雇员，这样能够集中在会话中，而不是界面（吸引人的/效率）
• 在完成以前，能够确认和雇员相关的全部变动（有效性）

从用户中得到用户的知识

有不少技术用于得到用户的知识，不一样的方法能够发现用户体验的不一样方面。若是关注效率，将使用一个技术可使咱们看到真实的人们在实际的环境中完成实际任务；对于容错，可使用关键事件的日志与报告或记录的实际错误相比较。使用可用性的不一样方面做为选择研究技术的一个工具，能够帮助得到了问题的答案，有助于作出好的设计选择。
当用户研究和分析完成时，有一个机会让咱们来比较最初的观点和用户的新理解。这是一个更新蓝图和修正不正确假设的机会。
可用性文献充满了因为用户形象变化从而致使产品革新的例子。例如，我曾经工做在一个关于雇员管理程序的小业务。当开始设计时，客户告知咱们典型用户会与不少不一样的程序工做，对微软办公软件很熟悉，按期使用email，并且喜欢学习使用程序以改进他们的业务。产品开发团队建议用户最关注的可用性需求是效率，这样他们能够更快地处理他们的业务；有效性或精确性，能够做为第二重要的需求。
当开始和用户工做时，很快就会发现，这个描述是多么的不许确。这些典型用户只与一个或两个程序工做，常用行业内的专业软件。不多使用通用办公软件，并且工做中不用email。最重要的是，他们只感兴趣获取足够的学习内容；他们想完成他们的工资账目，不想改变他们业务的方式。在这个项目中，咱们开始作用户研究，关注速度和精确性，并试图了解用户如何完成建立工资账目的特定任务，但咱们发现这是个错误的方法。反而，咱们更改咱们的技术，关注易学性和容错。咱们想知道在工资账目中，须要培训软件中的哪些内容，哪些困难会常常致使错误。

建立可用性目标和需求

5E中的每个均可以做为可用性目标的依据。一个用户的表述如“我怎么知道每一个人是否会收到他们支票的正确利息”，能够引出一个需求：用户应该能看到，并在最后阶段以前确认全部的选择。对一个有许多不经常使用任务的程序能够肯定一个可用性目标：对于一个（典型、培训过的）用户能够在没有额外培训或使用帮助手册的状况下完成指定的任务。
不管这个表述能够变成一个功能需求仍是一个可用性目标，将它们和可用性维度联系起来，使最初会话的表述和从中产生的共享愿景联系起来。例如，一个经理能够关注高效地完成工做，关注一个任务的时间；同时，工人却把它看做是一个容错问题，以及他们工做时业务支持的程度。

造成一个设计方法

仅仅关注可用性的错误方面是不正确的。所以，设计方法应当适应于可用性需求。例如，用户须要快捷键来一次处理一个以上的数据记录吗？或不常用产品的用户须要内置的帮助来提醒他们如何使用产品吗？5E提示了一些可能的设计需求（见表2）
表2：5E和可能的设计方法

维度
用户需求
可能的设计方法

有效性
精确性

• 提供全部关键活动的反馈
• 消除错误机会
• 为用户决策提供充足的信息

效率
操做速度

• 为理想的工做流设计导航，也同时兼容替代方案
• 提供快捷键
• 经过交互风格和设计图标提高速度
• 将界面中的无关元素最小化

吸引
被吸引住

• 使用清晰的语言和适当的术语
• 经过适合用户的会话水平设定一个帮助声音
• 功能结构化以匹配用户任务

容错
有效和确认

• 将错误转化成替代路径
• 使用控件有助于准确选择
• 确信活动容易回溯

易学
及时的信息

• 经过最少的快捷键和说明使界面有帮助
• 针对困难或不经常使用任务建立引导界面

可用性测试计划

须要什么样的可用性评估以确信设计符合可用性目标？须要什么样的原型以得到有用的结果？与用户研究相同，答案在于咱们所感兴趣的维度（见表3）。例如，一个业务须要支持很是高效的操做，极可能须要在一些初始的培训和一套与实际任务相吻合典型工做条件下用一个高保真原型或程序的早期版本进行测试。为了测试产品在复杂任务中的吸引程度，与早期概念原型一块儿工做会帮助聚焦在整个过程，而不是特定的细节。
表3：5E和可能的评估技术

维度
可能的评估技术

有效性

• 针对困难或模糊的任务建立场景
• 评估任务的成功完成的程度和产生没有测量到的错误频率

效率

• 建立一个实际的工做任务，重复地进行测试
• 使用工做软件或高保真原型
• 在用户工做时进行观察，发现那些打断或减缓用户操做的情形
• 收集计时数据，但一样掌握用户的主观印象

吸引

• 使用满意度访谈问题或调查做为评估的一部分
• 对视觉设计作偏好的测试
• 测试使参加用户能在他们想放弃时放弃一个任务

容错

• 建立容易犯错误的场景
• 观察用户可以从所发生问题中恢复过来的容易程度或精确度

易学

• 收集测试用户的实现步骤，或招募不一样经验或知识的参加用户
• 掺入不经常使用的任务和功能

在计划中引入可用性

对可用性或以用户为中心设计的最大异议是实践问题。如何将全部的额外工做融入已经安排得很紧、有时间点约束的计划？让咱们将这个问题变换一个角度，问一个不一样的问题：可用性如何帮助那些困扰软件开发过程的问题？
不只仅是开发软件过程难以免。实际上，当你问开发人员他们工做中最恨什么？他们将告诉你：

• 需求发生了变化、变化和变化
• 客户不能理解软件能作的和不能作的
• 构建某物，结果被告知它不是用户（或市场）想要的。

有趣的是，试验报告中已经包含如下数字：34%的项目在完成以前被取消，50%是仅仅部分实现了最初设想，只有16%成功。并且在项目的最初阶段就失败存在如下失败缘由：

• 缺少用户输入（12. 8%）
• 不完整的需求和规格（12. 3%）
• 变动需求和规格（11. 8%）

从这些发现能够看到，没有提早作用户研究致使了缺陷和不可管理的项目。
使人感兴趣地，这些是可用性专家和用户界面设计者抱怨的主要问题：

• 软件不能考虑用户的实际工做、任务和环境
• 太多重点放在技术需求，而没有充分平衡用户需求
• 在他们有了任何实际影响的好久之后，设计和可用性才被加入到产品

总之，须要针对功能和用户需求的共同语言，和整个开发过程当中可用性评估反馈到实际工做中。没有这个共同的基础，就不能准确描述产品，也没法在建立产品以后时承认它。

结论

若是想建立一个能用和有用的产品，必须将用户的知识和理解融入到概念和架构中。引用一个喜欢的可用性谚语：“可用性不是某些东西如花生油同样能够在项目最后抹在上面”。在今天软件开发的混乱世界中，很容易拒绝新思想；减小了对开发过程的控制，增长了复杂性。不管如何，若是集成得很好，以用户为中心的设计不只能帮助建立更好的产品，并且能够减小劳动和重复。当产品设计和理解用户需求结合，有更多的机会来知足需求。

参考

1. ISO/IEC 9241-11 Ergonomic Requirementis for Office Work with Visual Display Terminals（VDT） – Part II Guidanc on Usability. 1998：ISO/IEC 9241-11： 1998（E）
2. Lidwell, W.,K. Holden, and J. Butler. Universal Principles of Design. Rockport Publishers, 2003
3. Nielsen, J. Usability Engineering. Academic Press, 1993
4. Standish Group. The CHAOS Report. Standish Group International, 1994
（www.standishgroup.com/sample_research/chaos_1994_1.php）

做者简介

Whitney Quesenbery是一位用户界面设计师、设计过程顾问和可用性专家。
她致力于发展产品设计中的新概念，而且开发了喝多获奖的多媒体产品，网站，以及网络和软件应用产品。
Whitney领导着本身的设计咨询公司Whitney Interactive Design，是公司的首席顾问。能够从网站www.wqusability.com了解更多信息

 

 

 

 

 

 

 

 

参考：

http://www.everyinch.net/index.php/whitney_quesenbery_5e/