以用户为中心的设计

主题

• 为什么使用以用户为中心的设计？
  • 满足用户的需要
  • 用户界面设计
  • 法规和标准
• 什么是以用户为中心的设计？
  • 关注用户
  • 集成化设计
  • 初期用户测试
  • 迭代式设计
• RUP 中以用户为中心的设计
  • 使用环境
  • 场景、用例和核心用例
  • Rational Unified Process 中的核心用例

为什么使用以用户为中心的设计？

满足用户的需要

一个成功的交互系统必须能够满足用户的需要。这意味着不仅要能够识别各种用户群，而且还可辨别各个用户所掌握的技能、经验以及他们的偏好。

虽然开发人员和管理人员很容易自认为他们了解用户需要，但实际情况常常不是这样。人们往往关注于用户应该如何执行任务，而不是用户偏好如何执行。多数情况下，偏好问题不仅仅是简单地认为已掌握了用户需要，尽管这本身就很值得研究。偏好还要由经验、能力和使用环境决定。这些问题对于设计过程相当重要，因而才会出台 ISO 13407 国际标准，标题为 human-centred design processes for interactive systems。下文中将从一般意义上对这些标准及其相关问题进行讨论。

用户界面设计

通过系统的用户界面，用户可以了解系统并与系统进行交互。界面中介绍的概念、图像和术语必须适合用户的需要。例如，允许客户自助订票的系统将与售票员专用的系统迥然不同。关键差异不在于需求，甚至也不于在详细用例，而在于用户的特征和各系统运行所在的环境。

用户界面还必须至少从两个维度迎合潜在的广泛经验，这两个维度指的是计算机经验和领域经验，如下图 １ 所示。计算机经验不仅包括对计算机的一般性了解，还包括对尚待开发的系统的经验。在计算机领域和问题领域都经验不足的用户（如图左前方所示）所需的用户界面与专家用户（如图右后方所示）的界面将区别很大。

图 1：计算机和领域经验对易于学习和易于使用的影响

一条仍然适用结论需要引起我们的注意：经验不足的用户经过一段时间也会成为专家。有几条因素可能会阻碍用户成为专家，例如：低使用频率、缺乏积极性或高复杂性。相反，有些系统的主要用户可能经验相当丰富。那么培训、高使用频率或积极性（与日常工作息息相关）则可能是影响他们的因素。表 1 显示了其中一些问题及其对用户界面设计的影响。

表1，影响用户界面设计的一些因素

交互系统必须设计为能够适合一定范围内的用户经验和用户环境，或者必须采取步骤限制设计领域。例如，通过培训可以减少复杂系统内部对易于学习的需求。或者，可以缩小系统规模，以便更好地满足用户的核心需求（这是 Alan Cooper 在他的著作 The Inmates Are Running the Asylum COO99 中提出的建议）。

法规和标准

用户的技能及其生理特征是我们在以用户为中心的设计中应该考虑的问题。这类问题已越来越多地体现在法规中。这主要是为满足残疾用户的需要。但是，人们普遍认为让系统适用于更大多数人将对用户群这个整体大有好处。

下表显示了世界各地的相关法规和资源：

 表 2a，各国家、地区或团体有关残疾方面的法规

如下所示，除了法规之外，以用户为中心的设计和用户界面设计正日益成为标准化设计的主题。

 表 2b，ANSI 和 ISO 用户界面和以用户为中心的设计标准

什么是以用户为中心的设计？

关于以用户为中心的设计的构成内容尚未达成明确的共识。但是 John Gould 和他在 IBM 的同事于 20 世纪 80 年代开发了一种称为 Design for Usability (GOU88) 的方法，它包括了最为普遍接受的定义。它从若干交互系统的实践中发展而来，其中最著名的系统是 IBM 公司的 1984 Olympic Messaging System (GOU87)。  该方法由四个主要部分组成，如下所述。

关注用户

Gould 提出：开发人员应决定用户的组成，并让用户尽可能早地涉入。他提出了几种熟悉用户、他们的任务以及需求的方法：

 在 RUP几个关键阶段中都有研讨班，但要使理解更为精确，则还须补充 Gould 所描述的种种活动。（这样做的部分原因在于：人们描述他们做什么和他们实际怎样做之间往往大相径庭。他们常常遗忘或省略一些例行任务或表面上无足轻重的细节，诸如工作布局或令人费解的纸片等，因为这些并非“正式”属于当前流程的一部分。）

集成化设计

可用性任务应在开发的初期并行执行。这些任务包括勾画用户界面、起草用户指南或联机帮助，Gould 同时还指出可用性应当是小组的职责。  

集成化设计的一个重要特征是：详细用户界面设计的整体方法（即框架）要在初期进行开发和测试。这是以用户为中心的设计和其他单纯的递增技巧之间存在的重要差异。它确保此后各阶段中进行的递增式设计能够天衣无缝地适合框架，而且用户界面在外观、术语和概念上都能保持一致。

在 RUP 内部，可以通过领域建模来建立该框架，确保用户界面中出现的所有术语和概念都是业内的共识，尤其要让用户理解这些术语和概念。（领域模型中存在某些与特定的用户组相关的子集。应细心组织领域模型，以保证很容易地就能确定这些子集。）在需求工作流程中进行用户界面设计时，很多领域类将在接口中表示为边界类。各个边界类以及它们之间的关系应与领域模型保持一致，而且还应保持对设计中的系统所有部分在表示方式上的一致性。（这不仅对用户有所帮助，而且对用户界面构件的复用有所改进。）

初期用户测试

初期用户测试针对的是初期原型，通常指作为低精确度原型的图纸及样型。高精确度的原型将在随后的流程中出现。

样型可与用例结合使用，用来为设计之中的系统编写具体使用场景。可以采用以下形式：讲解、带图示的讲解（用样型演示）、示意板、（与用户）预排以及用户核心小组的基础。尽管很多软件开发人员不太熟悉这些方法，但是比起在实施开始后才发现设计不当或需求理解有误，这些方法显然更为成本合算。

迭代式设计

面向对象的开发已经成为迭代式流程的同义词。迭代式设计最适合于需要增进了解以及需求常变更的问题。迭代式设计是以用户为中心的设计的关键，这一点毋庸置疑。原因部分在于用户的需要会随时间有所改变，另外还在于出台可处理多种需要的设计解决方案本身就具有复杂性。

请注意：在以用户为中心的设计中，迭代式设计是在一个集成化的框架内部进行的。我们有意回避在一个统一的框架之外进行递增式开发，因为那将产生一个“拼拼凑凑”的解决方案。

RUP 中以用户为中心的设计

开发适合用户需要的系统意味着在需求分析中要付出巨大努力。在以用户为中心的设计中，重点应放在最终用户上。他们是业务建模工作流程中的业务主角（对业务外部用户而言）和业务角色的中的一部分人员。在需求工作流程下文中，他们被更详细地描述为主角。（主角、业务主角和业务角色三者之间的关系在指南：从业务模型到系统中有所讨论。）

但是，以用户为中心的设计着重强调的问题是：我们要了解充当上文工件中所描述角色的实实在在的人们的需要。特别是，我们必须避免为了方便软件系统设计而设计假想的人。描述最终用户的工件必须在和用户有切实的亲身接触之后进行编写。在以用户为中心的设计中，这种亲身接触是有时称为情景查询过程的一部分。Hugh Beyer 和 Karen Holtzblatt（在他们的著作 Contextual Design, BEY98 中）将情景查询的前提阐述如下：

“...到客户工作的地方去、观察客户如何工作、然后与客户谈论他们的工作。”

（与之有关的具体示例已列在关注用户中。）此方法不仅可以用来更好地了解系统需求，而且也可以更好地了解用户本人，了解他们的任务和环境。以上各因素都各有属性，综合在一起则称为使用环境。在 ISO 有关以用户为中心的设计的标准中有详细说明（请见下文）。

使用环境

ISO 的 Human-centred design processes for interactive systems (ISO13407) 确定了设计的第一步是要了解和细化使用环境。建议利用如下属性：

表 3：ISO 有关以用户为中心的设计标准中的使用环境

最好将用户环境按组成内容分为两个部分（用户类型和角色），然后再考虑所有四个环境的相互关系。

图 2：环境之间的关系

图 2 显示了每个任务都在由某个环境中的某个用户以某种角色来执行。这些环境对应 RUP 中的工件，如表 4 所示。

 表 4, ISO 有关以用户为中心的设计标准的环境及其 RUP 工件

每个环境都将对适当的用户界面设计产生重要的影响。因此，我们会遇到数不清的排列方式。即便是一个小型系统，也可能有 2 种环境（例如：办公地点和客户所在地）、3 种用户（销售新手、销售专家和管理人员）以及 6 种角色（电话销售助理、对外销售代表等等）。这就意味着每个任务都有多达 36 种潜在的变化形式，尽管实际合理的组合通常要少得多。

显然，我们应当分别对任务进行说明，但是单单一个说明不可能适合所有排列情况。方法之一是：将用户和环境因素融入角色说明。这是 Constantine 和 Lockwood 所采用的解决方案 (CON99)。该方案涉及到为每个重要的角色、用户和环境的排列情况都单独提供一个“用户角色”，然后用描述性短语，而不是用简单的名词为这个用户角色命名。例如，比较“客户”这个角色与“临时用户”、“Web 用户”、“常规用户”和“高级用户”等用户角色。

每个用户角色说明都包括角色自身的细节外加其用户（称作角色承担者）和环境。这种方法在 RUP 中体现为选取对应用户角色的主角。

场景、用例和核心用例

场景、用例和核心用例这三个术语由于概念交叉，在一定程度上容易混淆，因而用在不同的设计方法中，代表的事务稍有不同。例如，“场景”在 RUP 内部指用例实例，即只是一个经过可能的基本流和备选流的特定“路径”。但是，在以用户为中心的设计方法和用户界面设计方法中常常将场景描述为使用经历，这实际上包含了更多的细节，而不仅局限于事件流。虽然该附加信息可能与后来的设计阶段无关，但它对于了解用户、任务和环境却必不可少。因此，场景可以在业务建模工作流程（制作示意板和角色扮演）中广泛应用，但是在需求工作流中，重点则转移到用例上。

图 3 显示了这种交叉的本质。最上一级的标尺将一系列趋向于同时变化的不同因素合并到一起。例如，当越来越以需求为目的时，结构通常变得越为正式。核心用例出现在通用用例右侧，因为用户角色使它们稍加特殊（请参见上一节），这样它们的结构也更为正式。

图 3：以用户为中心的设计中场景和用例在概念上的交叉

系统用例和核心用例之间的差异最好通过举例来说明。 表 5 显示了 Constantine and Lockwood 的 Software for Use (CON99) 中的一个用例：

表 5：从 ATM 提取现金的通用用例

该示例详述了主角与系统之间的事件发生顺序，中间隔开两栏的垂直线代表用户界面。请注意：尽管 Constantine 和 Lockwood 建议核心用例采用此样式，但这个特定用例并不属于核心用例。因为它的基础是交互操作的句法细节。即：交互是如何发生的。核心用例侧重于交互的内容（称为语义）。表 6 才是交互操作的核心内容。

表 6：从 ATM 提取现金的核心用例

此用例提炼出了提取现金交互操作的本质。“用户动作”与“系统响应”两标题分别由“用户意图”和“系统职责”取代，用以反映强调重心的转移。良好的界面设计是以用户目标和意图为中心的，这在常规用例中常常体现不出来。  

但是，核心用例自身也确实存在缺点。对表 5 中显示的如此直截了当的用例提炼本质时，肯定会大有争议。例如，插入信用卡识别的是客户还是帐户？Constantine 和 Lockwood 在此例中选择了能够识别客户，但实际上绝大多数现有的 ATM 机只能识别帐户。考虑到技术的创新，如视网膜扫描和指纹鉴定等，这可能是作者有意的选择；否则就可能是作者的疏忽。如果是前一种情况，持有多个帐户的用户还必须继续再作选择。

核心用例带来的另一个难点是：由于本质抽象，它们不适合最终用户和其他涉众复审。部分原因在于：核心用例必须转回到代表用户动作的具体形式。通过编写具体描述交互操作的脚本，得到设计模型，就可以进行这一步骤。（尽管它与用户系统交互有关，而与内部对象协作无关，但与用例实现类似）。

Rational Unified Process 中的核心用例

RUP 并未明确地引用核心用例，但在活动：用户界面建模中，以核心用例为起点，随可用性需求的不断发展和扩充，从而创建用例示意板，详情请参见指南：用例示意板。  

• 首先要阐明用例本身，而不是用户界面。首先要使用例说明不受用户界面影响，对未经研究的用例更应如此。随着对用例的理解，事件流示意板可随用户界面和可用性等方面逐步补充。[来自指南：用例示意板]

这意味着需要删除所有设计或当前实施细节，而只留下语义（交互的含义）。随着各种备选设计的完善，句法细节（交互采用的方式）作为一种实现方式添加到核心用例中。（每个备选设计实际上是同一核心用例的一种实现方式。）

这些用例示意板用作活动：用户界面原型设计的输入，用以开发用户界面原型。

© 1987 - 2001 Rational Software Corporation。版权所有。