产品设计论文:可用性的维度之定义会话和推动进程
- 用户体验
- 2007-10-13
- 125热度
- 0评论
在我讨论可用性的质量的时候，我发现了一些可以加在“有效”、“效率”和“满意度”上的好的建议：用户友好、好记、快乐、可访问性、可学习性、可寻找性、高质量、有用的、对错误的反感。在《可用性工程》一书中，Jakob Nielsen曾提出一个可用的产品的五个质量：可学习性、效率、可记忆性、错误（低错误率、出现错误也容易修复）、满意度。
摘要
你有没有怀疑过你的同事或者客户是否真的理解“可用性”？在我们和同事的在商务、技术和设计讨论中谈论‘可用性’是什么时，经常充斥着一些标准和指导方针替代品。在本文中，我们通过了解可用性的五个维度，我们便能够围绕可用性目标达成一致的看法，并开始以这个可用性的定义为基础，来计划用户中心设计的工作。
设定场所
在一个会议室里，有五个或者十个项目组的成员，你们正要启动一个新的项目。有可能这是与一个新的项目组或者新的客户在一起。他们的目的就是想要得到一些他们曾听说过的“可用性”，而你正是帮助他们得到“可用性”的人。项目组的头儿说话了：
“我们想要我们的产品更好用”。你回答：“好，让我们具体谈谈你们的目标，然后我们就可以计划一下怎么达成它。”这时候，他便把这个挑战交给了你，“你是专家，你来告诉我们吧。”
也可能他们说：“你知道，我们想要我们的产品对人们来说更好用。直观。我们该做些什么呢？”这时所有的眼睛都看着你，你接下来说的话将会为你今后在项目中的工作设定场所。
这样的情景听上去是不是很熟悉呢？在这种情况下，我有两个目标：
- 第一个目标，也是最紧迫的，就是要让项目组里的其他成员在讨论“可用性”的时候把我当做专家，并且帮助他们理解我将要做的事情。
- 第二个目标，我需要利用这个信息，有时候很快，去定义进程而且采取正确的行动达成项目中的“可用性”目标。
“可用性”的维度就是我的切入点，我将从这个切入点展开这个对话。
谈谈“可用性”
我认为“可用性”这个词应当是一个可用的产品的质量或者性质，尽管这个词也用来描述 “以用户为中心的设计”的过程，或者用来描述是该过程中的一些特定的研究方法和评估技术。我们可以像在ISO9241标准中那样概括得定义“可用性”：
“一个产品可以被特定的用户在特定的使用情况中，有效、高效并且满意得达成特定目标的程度。”
但是对那些特定的用户而言，在特定的环境中使用时，有效、高效是什么意思？就像所有的标准一样，这个定义对指导设计来说，不够具体。然而，它是一个模板，是每个项目必须填写的起点。我们不能以一些无名的“特定的目标”，而应该是以详细描述和定义的目标来结束。
这个定义对于我们“推销”可用性这个概念，甚至理解这个概念的帮助很小。更重要的是，它几乎无法让项目中的关键人物展开想象并最后作出承诺。对ISO9241定义，有三个重要批评：
- 它太强调定义得很好的任务和目标，也忽略了用户体验中的比较不那么切实的元素，或者强加一些简单定义的任务（比如说，将电子商务网站的任务简化成“买东西”）。
- 强调有效和效率是产品使用中的最重要的因素，而认为产品和使用场合不那么重要，，这样便很难去讨论如何将“可用性”应用到产品上或者使用场合上。而关注愉悦、产品吸引力、或其他等难以度量的情感方面的因素，则被认为是和可用性无关的。
- “满意度”这个词在很多情况下不足以积极得涵盖所有的需求。它感觉上是“还可以”而不是“真棒”。它可能在一些企业或者工作相关的应用上是可以接受的。在消费者购物、寻找信息或者在线服务中，它对用户或者商务来说，在描述人类互动的目标时，就不够显著。
简单来说，这样我们就在与软件、网页和产品设计团体的沟通可用性的前景时失败了。谈到可用性是一个将它分解成不那么抽象的词汇的过程，这样我们就可以细致地、从各个角度或者维度去讨论。
定义维度
在我讨论可用性的质量的时候，我发现了一些可以加在“有效”、“效率”和“满意度”上的好的建议：用户友好、好记、快乐、可访问性、可学习性、可寻找性、高质量、有用的、对错误的反感。在《可用性工程》一书中，Jakob Nielsen曾提出一个可用的产品的五个质量：可学习性、效率、可记忆性、错误（低错误率、出现错误也容易修复）、满意度。
最初，用全部以E开头的单词只是个文字游戏，而我也一直在寻找可以让“可用性”的维度易于记忆的方法，所以5个E就诞生了。我决定用：
- 有效的（Effective）
- 高效的（Efficient）
- 吸引力（Engaging）
- 错误宽容度（Error Tolerant）
- 易学习的（Easy to Learn）
有效的—用户达成目标的完成度和准确度
有效的（Effective）是第一个E。如果一个用户不能完成他/她被安排去做的事，就无所谓完成得快或慢，容易或者困难。最终，他们在完成任务或达成目标的中失败了。如果我们想衡量有效性，我们必须知道人们怎么定义成功和有用，如果想要进一步或者更精细的结果。
高效的—在完成工作时的速度（和准确性）
高效可能是被定义得最细致的，比如说，在一个电话服务中心，效率就是一个操作员每天处理的电话数。如果说一项任务“太费时间”或者“需要点太多次”可能是一个主观的判断。
吸引力—使用界面时的快乐感、满意感和有趣的程度
“吸引力”取代“满意度”是在寻找一个能让界面将用户吸引到一个网站或者任务中的词汇。它也同样关注于互动中的满意度，或者用户和产品的表现、组织是怎么更好的连接在一起的。
错误宽容度—产品如何更好得防止错误，并且帮助用户应对错误
要是能够“没有错误”或者“防止错误”那是最好不过了，但是错误、意外和错误理解还是会发生。你的每次点击也是可能出错的，比如你可能会读错一个链接并且需要返回，或者打错了字。真正的测试是看在错误出现的时候，交互界面能提供多少帮助。
易学性—产品如何支持首次使用，和支持更深入的学习
有的产品可能是被用到一次，有的产品偶尔被用到一次，有的产品每天都会用到。这个产品的操作可能是一个简单或者复杂的任务，用户在这个任务中可能是专家或者初学者。但是每次界面在被使用的时候都需要被记起或者重新学习，而且产品中的一些新的领域也会随着使用时间的增长被慢慢探索到。
认识5E
认识“可用性”的意义——“可用性”的每个维度都是如何被定义的——是谈论“可用性”的好开端。不做一般性的描述，而是去探索每个产品中涉及的特定的情况和用户的角色。
这样去做的一种方式是以第一人称对“可用性”需求的每个维度做出描述。这种需求在一个典型的描述中可能是直率的或者含蓄的。做好的方法是直接引用用户调查中的语言。而且对用户当前的知识或者一些猜测的描述也可以架构起来。
这种描述应该是第一人称的，提醒项目组这是反映了用户的观点，而不是商业需要。好的描述也揭示了用户对产品或者任务的潜在态度，并且对用户的声音也有一个风格和语言学上的认识。这里有一些例子：
- “我希望这东西别再让我犯错了。”（错误宽容度）
- “它最好比打印出来填好能快点，我可不想花整天的时间在上面。”（效率）
- “我怎么才能知道它是不是给我注册了正确的课程？”（有效性）
- “我们培训过，但是我每个周只用一次这个东西，很容易会忘记。”（易学习性）
- “……我看到一个白屏，不知道接下来该做什么。它就这样死在那里了，所以我就去看别的网站了。”（吸引力）
- “我找到一些什么，但是这是唯一的答案吗？我不知道，可能还有些别的需要看。”（有效性）
- “这个网站不错，但是字太小了，很难读。”（吸引力）
当然这些维度是相互联系的，一个比较难学和难记的界面需要更长的时间去使用。一个容易被错误牵制的界面，自然不会高效。理解这其中的关系可以通过区分用户所说的一些细微差别。考虑到差别和重点（和反应速度的布置），“我不想做错”和“我希望它能做得准确。”两中表达都考虑到互动的结果，但是一个强调该产品更需要强调“错误宽容度”（并且预防错误）从而恢复用户对产品的信心。而另一种表达，建议对产品的一些反应有更确定。
平衡问题
如果“可用性”的各个维度在所有产品中都同样重要，那将是非常方便的。然而并不是这样，就像可用性需求在每个产品中都因具体的使用环境而不同一样。需要考虑一个具有重复性的任务和一个游戏之间的差别。这提供了一个用5E去理解一个产品中的可用性需求的机会。
5E中的平衡和关系为界面设计确定方向，并且帮助确定用户调查和可用性评估的具体技术。它可以为设计建议好的途径，并且认识到哪些地方可以进行必要的协商。
这里接下来有两个例子，一个是博物馆的网站，一个是注册更新的表格，两个都是为普通大众服务的。
一个博物馆网站
对于博物馆网站来说，最重要的三个维度是：
- 吸引力：“我想看看这是个什么博物馆，对其中的展览有一个印象。”
- 效率：“我想知道的是它的地址和开放时间。我得浏览多少页才能找到我要的信息？”
- 有效性：“上次我用这个网站计划参观博物馆的行程，但是时间错了，所以我根本没进去看展览。”
一个注册信息更新表格
形成对比的是，在注册信息更新表格的页面中，用户说：
- 错误宽容度：“如果我做错了什么会怎么样？我能改正确吗？”
- 易学性：“别告诉我为了更新这个东西我还得去读手册。他们不能做得更容易理解一些吗？”
- 效率：“在线做这些事情比我打电话寻求技术支持更花时间。”
让5E贯穿整个过程
在针对某个项目选择维度的时候，我也在发掘和理解该项目的一些特性，这些特性会对界面设计有建设性的帮助，并且为可以为该项目制订量体裁衣的“以用户为中心的设计”过程。如我们所见，5E在项目中的每个阶段都同样有效。
虽然是以谈论“可用性”作为起点的，但是给可用性下定义这项工作，的确在整个“以用户为中心的设计”过程中是非常有价值的。
5E也可以作为一种宣传和倡导的工具。为每个维度建立具体的用户描述，可以帮助项目组展现那些他们所不了解用户的领域，这样做，强有力弥补了那些知识的空缺。一个参与者在会议阶段曾经评论说，很多人对从未见过面的人很难说出一些话，他在未做过之前没有意识到他知道的有多么的少。
最初的设想和在对话中探索
在一个项目组进行第一次讨论时，根据参与者在其中的角色不同，他们的“可用性”经验不同，他们对于用户的知识的深度不同，有几种不同的技巧。总得来说这个过程很简单：
- 讨论5E中的每一个E的意思，确定每个人都理解了这些E，以及该项目中有可能如何理解这些E。
- 找出（或者创造出）一些能够反应用户针对每个E的态度的典型的用户评论。可以列出一个角色(Persona)的、几个角色的、或一个用户群的。
- 讨论在项目中，每个维度相关于取得成功的重要性（并且还有全部的可用性），记录排列5E优先顺序的原因。
在这个环节中应该选择一些对这个小组来说比较恰当的方式和形式。Scott McDaniel和一些同事曾经用游戏来设置优先级。在这个途径中，项目组有100美元分摊到5个E商。他们在每个维度都化一些钱，但是一些会比其他的更有价值（并且花费更多）。用游戏来做如此重要的决定看上去好象太轻佻了一些，但是在一些项目组中，它的确是完美的“破冰者”。重要的是让组员们谈论可用性，并且思考我们所说的可用性在他们的项目中是什么意思。
策划用户分析
什么样的用户分析，对揭示在每个维度更深入的需求有帮助？举例来说，你需要知道一个任务需要多长时间（效率）来完成吗？，用户怎么逐步建立起他们对使用该产品的知识（易学性）？这其中每一个都在用户研究中，提出不同的重点和技术。
当用户研究和分析结束之后，你就有机会去了解用户研究的结果是否与最初的设想不同，或者是比最初的设想还有所延伸。和项目中关键人物一起来进行这些最初的工作，不仅仅帮助可用性专家了解他们的观点，并且也可能会揭露一些不正确的设想。
建立可用性目标和需求
每个用户对于5E的描述都可以作为可用性的目标的基础。在那些含蓄的描述中，什么才是一个产品必须去满足的需求？一个像“我怎么才能知道它是不是给我注册了正确的课程？”这样的用户描述，可能会引出一个“用户需要在做出最后的行动时对一切进行确认”这样的需求。或者一个程序有一些罕见的任务可能有需要典型的、经过训练的用户去完成的可用性目标，而不需要其他的训练和额外的手册。
无论用户描述是否提及到功能性的需求或者可用性目标，都应该在最初的对话中将它们与其中一个可用性维度联系起来。
这也可以表明需求的区别——或者强调的重点。例如，项目经理可能更关注工作的效率，并且认为是花在任务上的时间问题，而一个工人可能认为是一个错误宽容度的问题，并且认为是这个应用如何更好得支持他们工作的问题。
建立设计概念
怎样才能使设计方法更着重于可用性的最重要的尺度？什么样的设计元素能够帮助制作出针对用户需求的界面？会不会有一些用户偶尔需要某些快捷方式或者方法来处理超过一个“项目”，或者少数用户需要一个嵌入式的帮助来“提醒”他们如何使用界面？
每个5E都会建议一些方法：
维度：有效性
用户需求：准确性
可能的设计需求：
- 为所有的动作提供反馈信息;
- 排除错误的可能性|
维度：效率
用户需求：操作的速度
可能的设计需求：
- 设计完美的工作流程，也留下改变的可能性;
- 提供快捷方式;
- 用互动风格和设计的小装饰支持速度问题;
- 把屏幕上无关的元素减到最少
维度：吸引力
用户需求：被吸引其中
可能的设计需求：
- 将“品牌承诺”结合到设计中;
- 运用适当的词汇和术语;
- 设置恰当的、有帮助的语气
维度：错误宽容度
用户需求：确认和批准
可能的设计需求：
- 将“错误”转化成其他途径;
- 运用可以帮助正确选择的控制;
- 确认动作都是可逆的;
维度：易学性
用户需求：时间信息
可能的设计需求：
- 让界面在最少的提示和操作说明下更有帮助
- 为难度大的和罕见的任务创造有指导性的界面
策划可用性测试
什么样的可用性评估能确保设计可以实现可用性目标？什么样的原型才能得到可用的结果？试例，如果一个应用软件要支持一个有效的运转工作，那就需要用高精度的原型或者程序初期的文本进行测试，需要最初的训练和一整套现实的工作来匹配典型的工作环境。一个产品可能需要用最初的概念原型进行测试，用以所定人群。
维度：有效性
可能的评估技术：
- 为有困难的和不明确的任务创造演示场景
- 根据任务被完成的准确性如何，和任务产生的不易被察觉的错误来评估一个任务
维度：效率
可能的评估技术：
- 用足够的具有典型任务的副本架够测试，去创建现实的工作节奏
- 运用工作软件或者高度仿真的产品原型
- 收集时间数据，同时也访问参与者，看他们对程序的主观印象
维度：吸引力
可能的评估技术：
- 运用满意度访问问题或者调查作为评估的一部分
- 对设计表现做有对比的偏爱测试
- 架构一个参与者可以选择放弃产品的测试
维度：错误宽容度
可能的评估技术：
- 为可能出现的错误或者其他问题设置演示场景
- 观察用户在遇到错误时，能不能简单、准确地修复错误
维度：易学性
可能的评估技术：
- 控制需要给参与者多少操作说明，或者招募不同层次和知识水平的参与者
- 将最常用的任务和不太常用到的任务或者场景混在一起
结论
对于每个项目或者个人来说，在项目的整个生命周期中，贯穿运用可用性维度将进程和设计决策联系起来，这是一种很有效的方法，它可以将所有“以用户为中的设计”的元素结合在一起；对可用性在特定环境下的理解，也可以让工作集中一致。5E可以作为新的可用性研究技术的基础，帮助“推销”可用性及其力量，并指导设计项目走向成功。
参考文献
- Nielsen, J., (1993). Usability Engineering, San Diego: Academic Press.
- Quesenbery, W. (2001). “What Does Usability Mean: Looking Beyond Ease of Use.” Proceedings of STC2001 (available on http://www.WQusability.com/presentations/)
- Quesenbery, W. (2002) “Dimensions of Usability” in Albers, M. and Mazur B. Eds, Content and Complexity, Erlbaum