构建用例场景的交互界面设计方法研究

王伟

交互界面是人和机器进行信息交换的通道，用户通过交互界面进行操作，机器则通过界面反馈各类信息。传统的界面设计方法已经无法满足这种复杂的设计要求，难点在于如何保证界面在交互状态下其设计的合理性和科学性。这就需要探索一种全新的方法来解决交互界面的复杂性、可靠性和有效性的问题。本文试图采用软件工程的思维方式来解决交互界面设计的合理性问题。

长期以来，设计界一直存在两种设计思维方式的争论，一种是以系统为中心的设计思维方式，一种是以用户为中心的设计思维方式。以系统为中心的设计方法经历了科学发现、工业应用、用户适应三个阶段。这三个阶段非常漫长，有数据表明，汽车进入25%的美国家庭花了55年的时间，录像机花了34年，手机则花了13年。［1］这种方法设计的焦点主要集中在系统本身，设计思维方式更偏向于系统的功能和目标实现，但是，人机交互因素的提升加速了技术的普及和推广。随着工业技术和信息技术向纵深发展，这种以工程师为主导的产品设计文化正逐步过渡到以用户需求为重心的设计文化，人和机器之间的视觉对话机制--人机交互界面使系统更具吸引力。无论是微软的win系列还是苹果公司的麦金托什系列，以及后来发展而来的ipod、ipad 、iphone，都让人机交互界面成为一个重要的研究对象。我们看到了人机交互界面在产品上的成功，同时也看到了人机交互界面在产品上的失败。如果说微软win系列采用的人机交互界面策略是成功的话，从win95到win7系统还为桌面用户保留了一致性的场景。但是，win8改变了用户的使用场景，试图改变用户从桌面到移动端消费，结果导致win8在pc端销售严重不畅，距离消费者越来越远，以致不得不调整人机交互界面设计策略。

20纪90 年代中后期，诺曼博士明确提出以用户为中心的设计思想。1998年，以用户为中心的设计正式写入ISO 9241-210 人机工效(Ergonomics of human-system interaction)标准指导文件中，强调用户和产品之间的交互质量，包括有效性，效率和满意度。［2］然而，以用户为中心的设计思想仅仅作为一种设计理想化指引,实际在产品设计和开发中，如何无限接近这一目标，这是一个难题。以致诺曼博士在后来提出要把关注点从用户的个体转移到用户的活动和为了这个活动所采取的任务上。［3］如何实现这种目标，诺曼博士没有直接给出答案。本文试图通过构建用户用例场景分析，从用户的场景活动出发来解决以用户为中心的交互界面设计问题。

1 关于场景

场景设计的概念最早来自电影或者动画工业，设计者基于某种假设、想象或者事实，通过图画兼简短文字来描绘故事中的人物、场景和故事情节，通过连续性图画来表达一连串发生的人物行为和状态。1967年，IvarJacobson博士在定义爱立信AXE系统的构架时候开始使用场景书写方法来解决复杂的人机关系问题。Jacobson发明了对整个软件工业都产生深远影响的工具—用例。［4］这种方法不仅将以用户为中心的设计意图清晰地表达出来，并在平衡用户、系统、环境三者之间的关系中发挥着重要的作用。1995年，Jacobson先生加盟Rational，与Grady Booch和James Rumbaugh三人一起创造了意义深远的统一建模语言（Unif i ed Modeling Language ，简称UML）。市场根据UML开发了很多工具，包括有名的Rational Rose，Enterprise Atchitect（简称EA）工具，用例工具是其中重要工具之一，并大量应用于构建业务场景建模和系统建模过程中,这种方法促使交互界面的设计向更有效的方向发展。

场景用来记录有关人及其活动的故事。场景描述的优点在于其不仅可以清晰定义用户及其行为，还能够清晰定义用户所处的环境信息及其相互之间的交互关系。用户通过触发某个事件来完成任务，事件触发的情景便构成了一个场景，不同的触发顺序和处理结果就形成事件流。这种分析和设计方法同时还被引入到产品测试中，通过用例测试，快速迭代，可以促使设计无限满足用户的需求，提高交互界面的质量，提高了交互界面的有效性、效率和满意度。

2 用例场景设计

在最新的UML文档中指出：“用例图描述了环境中的演员通过使用主题系统来实现某个目标，那就是实现了主题系统为演员提供的一组服务。用例也可以被视为通过主体和演员之间的交互实现相应的功能或者能力。用例图包含相互关联的用例和参与者，以及它们之间的通信。演员代表可能对应于用户的外部系统、系统、或其他环境实体的分类器角色。他们可能会直接或间接与系统发生相互作用。演员往往代表专业用户类型或外部系统。”[6]根据定义，用例图可以理解为包含了用户（Actor）、用例（Use Case）、系统边界、关联描述（如箭头等）等要素，用于描述用户和系统功能之间的关系，但并不描述系统内部工作的细节。例如，当用户到银行取款，我们为此场景创建一个用例。用文字可以这样描述：“银行客户某某在ATM机上取款...”但并不描述ATM系统内部的工作细节。

图1

用例是软件系统工程里的一个重要概念，用例是对一组动作序列抽象的描述，系统执行这些动作序列，产生相应的结果。这些结果可能反馈给用户，也可能作为其他用例的参数。通过用例的方法来描述动作序列的场景，应用于产品设计和开发中，可以清晰地记录出用户的需求，［5］更重要的是通过用例图可以发现其中的问题。用例可以采用自然语言的描述方式，如文本法；也可以采用形式化语言的表达方式，如活动图、序列图、交互图。文本法就是讲故事的方法，这种方法通常应用在项目早期阶段，但不够直观，也不易操作。对于复杂的产品来说，很难把用户和系统关系陈述清楚。活动图就是将用户的行为用图表的形式表达出来，其缺点在于很难捕捉到用户的行为目的，也很难应付复杂的场景。序列图克服了文本法和活动图的缺点，能够清晰描述用户和系统之间的交互关系，这种表述方式最大的优势在于明晰了交互关系以及用户动作所产生的后果。因此，用例图、活动图、序列图并辅以简短的文字描述方法简洁、直观，逻辑性强，强调用户行为驱动的事件流，能够清晰有效地建立用户和系统之间的交互关系，准确捕获到用户的实际需求和潜在需求。

在设计用例之前，首先要选择用户（Actor）。从UML文档可以看出，用户是指存在于被定义系统外部并与该系统发生交互的人或其他系统，他们代表的是系统的使用者或使用环境。这里的用户是人也可能是其他对象，如系统时钟。不同的用户对产品会执行不同的行为或类似的行为。因此，对用户进行画像分类，建立用户模型是非常必要的工作。一般根据用户本身的性别、年龄、教育程度、收入等数据进行分类画像，也可以根据用户的主要活动、工具、工作环境等等来进行分类画像，建立人物原型实例。“VB之父”Alan Cooper曾建议不要为超过三个以上的用户画像，这容易造成需求冲突。

其次，建立用例（Use Case）。用例用于表示系统所提供的服务，它定义了用户如何使用这个系统，描述了该系统所提供的某一完整功能以及用户与系统之间发生的交互关系，用例的描述通常采用动宾表达形式，表示用户发出的一个动作。例如：添加账户、删除账户等。（图1）

再次，选择通讯关联（Communication Association）。通讯关联用于表示用户之间或用例之间的对应关系，它表示用户使用了系统中的哪些服务（用例），或者说系统所提供的服务（用例）是被哪些用户所使用的。关联通常用泛化（Generalization）、包含(Include)、扩展(Extend)来表示。关联能够有效界定用例的边界。

泛化通常指用户之间或用例之间的继承关系，例如，ATM机用户可以分为银行客户和管理员。用户和两者就构成了继承关系。银行客户和管理员使用系统的目标完全不同，因此，泛化强调子用例之间的互斥性关系。

包含描述了用例和用例之间的关系，可以将一个复杂的用例分解成比较小的步骤。例如，银行持卡在线用户可以通过手机来维护个人账户，维护账户可以分解成添加账户、修改账户、删除账户、查询账户。维护账户就和四个用例构成了包含关系。用例之间的包含关系还描述了在执行基本用例的实例中插入了一个行为段。基本用例可控制与包含用例的关系，并可依赖于执行包含用例所得的结果。例如，当用户进行商品在线交易时，购物、交易、退款或者转账时都需要识别客户，至于采用何种方式识别并不重要。

扩展关系通常指基本用例功能之外的延伸。例如，网上购买商品后需要“查询账单”，这是个基本用例，但是，客户可能需要“打印账单”。打印账单和查询账单之间就构成了扩展关系。扩展强调行为的偶发性，在查询账单时并不一定需要执行打印行为。

在用例设计过程中，用例必须是由一个角色触发而产生的活动。如果存在角色不产生交互行为的用例时，要考虑将其并入到其他用例中，或者检查该用例的用户有没有被遗漏的可能。如果发现有任何用例与不相关联的用户存在，就应该考虑该用户是如何与系统发生对话的。

除了用户作为用例的用户之外，还有一个特殊的系统用户—系统时钟。在很多情况下，我们需要在系统内部定时执行一些操作，如检测系统使用状况、供电情况、内存情况、给用户发送消息 等等。从表象上看，这些操作并不是由用户触发的动作。但是，我们把定时器抽象出来作为一个特殊用户，利用该用户来触发某些定时操作。例如：当学生将在线课程加入到选课计划里的时候，课程将在某个时点开始，我们需要将时钟用户加入进来，当临近这个时间点的时候，系统会自动向用户发送上课提醒信息。

单纯描述用例是分析界面交互设计的第一步。在哪些环节需要界面，哪些环节不需要，这就必须要清晰描述用户和系统之间的交互关系，选择序列图来描述是个非常有效的方法，从可视化的行为逻辑中容易暴露出潜在的问题。序列图（图2）为交互和可视化界面设计提供详尽的信息。没有这些内容，交互和可视化界面设计就缺乏坚实的逻辑基础。

实践发现，通过用例图的方法来构建场景是交互界面设计的有效方法，这种场景可以有效地将设计从系统转移到用户和系统环境的研究上来，引导出相关的交互界面，也更贴近以用户为中心的设计目标。这种方法还带来一个好处，即能够有效地控制系统功能的细分粒度，既不会设计多余的功能，也不会因为缺少某些功能而导致系统无法满足用户的需要。

图2 序列图（登录案例）

3 书写用例规约

为了进一步细化用例表述的信息，需要书写用例规约（表1）。书写用例规约通常包括以下几个方面：

1.简要说明 (Brief Description) ，简要说明此用例的目的和作用

2.用例场景 (Use-Case Scenario) ，包括能够完成预期目标的场景以及完成目标失败的场景，场景主要由两个流组成，包括基本流和备选流。也就是说，为用户提供多种完成任务的过程描述，确保用户能够在实现目标任务的过程中完成任务或者能够正确退出任务。

3.事件流 (Flow of Event) ，包括基本流和备选流。基本流是描述用户正确完成任务的过程。备选流也叫异常事件流，就是用户在完成任务过程中可能发生的种种异常事件的描述。描述事件流可遵循一些基本方法，例如只书写“可观测到的”事件，使用主动语句，用参与者或者系统时钟作为主语等等。

4.特殊需求 (Special Requirement) ，描述与该用例相关的非功能性需求（包括性能、可靠性、可用性和可扩展性等）和设计约束（所使用的操作系统、开发工具等）。［9］

5.前置条件 (Pre-Condition) ，执行用例之前必须指定系统所处的状态，这种状态是交互事件发生的前提条件。

6.后置条件 (Post-Condition) ，用例执行结束后系统可能处于某种状态，等待下一个事件的发生。

表1 用例规约案例

单纯描述用例是分析界面交互设计的第一步。在哪些环节需要界面，哪些环节不需要，这就必须要清晰描述用户和系统之间的交互关系，选择序列图来描述是个非常有效的方法，从可视化的行为逻辑中容易暴露出潜在的问题。序列图（图2）为交互和可视化界面设计提供详尽的信息。没有这些内容，交互和可视化界面设计就缺乏坚实的逻辑基础。

实践发现，通过用例图的方法来构建场景是交互界面设计的有效方法，这种场景可以有效地将设计从系统转移到用户和系统环境的研究上来，引导出相关的交互界面，也更贴近以用户为中心的设计目标。这种方法还带来一个好处，即能够有效地控制系统功能的细分粒度，既不会设计多余的功能，也不会因为缺少某些功能而导致系统无法满足用户的需要。

用例规约为产品设计提供了丰富的信息，也为产品开发和测试提供了详尽的文本。其意义体现在一下几个方面：

· 拟真性。场景的描述记录了用户的真实行为，构建可视化场景。

· 准确性。能够准确地描述用户的每一个动作以及系统应该给予用户准确的反馈信息。

· 交互性。能够详细描述了人和系统之间交互关系。

· 可评估性。能够对用例或者事件流作出科学评估。

· 意外事件。能够准确预测用户在使用产品的过程中可能发生的意外，并采取相应的设计来避免这种意外的发生，并建议建立安全的退出机制。

· 非功能性需求。能够对非功能性需求提出明确的要求，如密码安全等级提醒。

通过描绘场景的用例的设计方法是研究和梳理人、机、环境之间的重要方法之一。当面临一个既模糊又复杂的需求场景时，通过书写用例的方法能够比较快速地准确捕获需求，能够将需求通过交互界面准确映射到人、系统和环境之间的交互关系中。用例的重要性在于在产品设计和开发过程中，通过用例捕获用户需求，通过人机交互界面来传达需求，通过用例来发现系统对象，根据用例来跟踪产品测试。

4 结语

用例工具和序列图工具是解决人机交互界面建模问题比较科学的方法。通过上述方法构建人机交互界面具备以下优点。第一，交互界面坚持了以用户需求为导向的设计思想，而不是靠设计师的主观构造。第二，实现系统交互界面设计和需求分离，重点关注用户的需求。第三，便于系统交互界面之间的跟踪测试。第四，能够灵活适应用户的需求变更，快速完成设计迭代。第五，用例图描述场景简洁、直观，表达清晰，便于项目参与人员和客户之间的沟通。第五，减少捕获需求过程中的各种资源消耗，有利于敏捷开发。［10］

用例图是用户场景建模的优秀工具。但是，也可看出用例并不擅长描述某些非功能需求， 对于系统的性能、可靠性、稳定性、健壮性无能为力，这些在交互界面表现层面又显出特别重要的意义，例如密码安全级别提示就是一种重要形式，这些有赖于用例规约的创新性设计和慎密的思考。