可用性的维度（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/