以用户为中心的设计

如今，软件的用户界面正日渐成为是否具有竞争优势的重要条件，倍受关注和重视。随着产品功能的多样化和复杂程度的增加，用户把界面作为解决方案并以此激发消费者购买软件产品的动机。如果一个产品的界面引起了用户的注意，并且易学、易用、具有合适的价格和功能，那么这个产品就会有很强的竞争性。如果突出宣传低额的培训费用和生产利润的透明性，必然会提高产品的竞争优势。

要取得产品竞争上的有利条件和优势，不是用命令、技巧或玩弄花招能够得到的。尽管有许多技术可提高取得大致目标和产品成功的可能性，但在在方法和工具的选用无一定之规。对管理和技术人员进行相关的、系统的辛勤工作是非常必要的。一个产品的设计和开发过程包括很多步骤：计划、需求、设计、实现、评测、过程迭代和需求满意情况下的部署。

这些步骤如同技术精湛的厨师“烹制”美味佳肴一样。在成分和实现的细节上略微变化，这些基本的步骤可产生很多不同的“菜谱”。并不是所有菜谱都是好的，一个技术精湛的厨师知道哪些菜谱应该保留并推荐给顾客，哪些菜谱应该抛弃。

本章对用户界面的计划、设计和开发过程进行整体描述、诚实、勤奋和持之以恒地对待工作，可获得丰富的用户界面“菜谱”。对这个主题有必要进行广泛的探讨，但是对关键部分的概述将与参考书目一同提供，以便读者深入探索。每个步骤的过程将在随后各章深入剖析。

本章包括以下内容：

◆ 以用户为中心的关键原则

◆ 用户角度

◆ 开发人员角度

◆ 系统角度

◆ 返回项目主题

1、以用户为中心的关键原则

很多读者知道：在某些情况下，项目将以用户为中心展开。对于以用户为中心的项目，非常有必要遵守下列原则：

◆ 理解用户的任务需求

包括在整个产品生命周期中各方面的需求

◆ 设定量化的目标。建立基于用户或基于业务的标准

◆ 设计一个完备的用户体验过程

一个用户对一个产品的完备的体验过程包括包装、销售、培训、硬拷贝文档、设置、安装、屏幕、图形、帮助、其他性能支持、升级和卸载

◆ 评测

让用户参与测试，借些判断是否达到了目标或是否存在问题

◆ 迭代

如果没有达到目标或存在问题，就要进行修改，并使之重新生效。第一次不可能做得很完美，认识到这一点是非常重要的

经验法则：

事先要知道需求可能会扩展和延伸到产品的设计和实现阶段。

设计和开发的实践与技术有很多，结合使用以用户为中心的设计原则时，在软件产品开发上取得的成功对赢得用户和实现业务目标也会有很大帮助。

2、用户角度

一般说来，对于基于图形用户界面的操作系统和应用软件，最终用户很容易被其多样化的功能征服。尽管30分钟内就可轻松学会基本的用户界面功能，但是研究和开发一种用户界面的所有功能和使用这个应用程序仍然具有一定难度。最初学习网页风格的用户界面（WUI）和手持设备用户界面（HUI）时，可能也觉得可怕，但会因为系统的限制无须更多东西。

手持（handset）详解：1.(电话)听筒, 手持送受话机,2.手机, 包装式电话机(手提式)步话机3.手持的小型装置。解于金山词霸。

用户认识到，在现实环境中，作为工具的计算系统能够支持并轻松完成计算任务。最终用户的目的以完成任务为导向，并把现实世界范围内的对象概念化（参见图2.1）。然后，最终用户再决定如何用计算系统成功完成任务。

经验法则：

可用性差或复杂的系统会成为实际工作中的障碍。

对于用户界面风格，仅仅提供一种基本元素尚不足以保证软件产品易学易用。例如，使用图形用户界面风格不能保证基于图形用户界面的使用性。同样，使用网页风格的用户界面或使用手持设备风格的用户界面也不能保证能够实现软件的使用性。

在实际工作过程中，最终用户需要各种不同类型的应用软件与系统时，将会出现非常复杂的问题。传统的用户界面风格和比较现代的软件界面风格有差别。除了常见的硬件、操作系统（OS）和应用软件的不同，在单一用户界面风格上也会有很多不同，最流行的几个图形用户界面风格象Apple OS/7、Windows和开放软件基金会（Open Software Foundation，简称OSF）的 Motif便是最好的证明。在这些例子中，用户界面的目标是通过计算系统，使不需要的功能特征变得一目了然，并且尽量保持协调。

3、开发人员角度

如今，硬件、操作系统、用户界面技术和开发工具的特色和数量足以征服大多数应用软件开发团队。根据文档、只读光盘和磁盘、大量的规格说明和数不清的程序指令的长度，很容易测量一个编程任务的复杂程度。

软件的开发非常复杂，它需要在多个抽象和转化层次上关注很多琐碎细节（参见图2.2）开发一个应用软件团队而言，在多种系统下执行任务时，需要面临更复杂的问题。

当一个应用软件需要移植到其他环境或系统平台之间，用户界面的开发任务会变得更加复杂。试着实现系统服务、显示控件与窗口组件、字体与图形支持等应用层软件时，会有数不清的诸多系统的不同点。对于基于图形用户界面的软件，尽管所拥有可移植语言和工具也不能创建同样的窗口、图标、菜单和鼠标指针，不过开发人员很快就能学会。

对于软件开发团队，其他的复杂因素是硬件、操作系统、编程语言、应用领域、相关技术和用户界面风格与技术的快速变化。例如，正当图形用户界面在桌面系统上占支配地位的时候，基于网页和基于个人数字助理的软件和用户界面风格会变得非常流行，并一定非常适用。

4、系统角度

一个系统及软件既使用一种能够描述视觉和听觉信息的描述用户交流，也使用非语言方式如回应时间、可靠性、性能和其他人为因素来交互（参见图2.3）。

用户使用键盘、鼠标、听得见或摸得着的信息等行为实现与系统及其软件的交互。系统及其软件有时会对用户某些限制，如必须在确定的时间段内输入（回应时间）、丰富的错误信息（可靠性）和使其正常运转的使用方法（性能）。

采用描述和行为方式进行信息交流的语言是由语义（意义）、语法（结构）和物理映射组成的。对计算机和用户部分的设计和理解，还需要很多高级技巧。

5、返加项目主题

您刚和项目领导以及同级团队的领导参加了一个无用户界面的软件启动会议。会议期间，向您分配了任务：与项目领导讨论项目开发的过程、方法和技术。那就根据本章介绍的知识，校正您对于计划、需求分析、设计、开发和测试等方法的最初想法，校正日常用于项目用户界面和可用性有关进度、活动和资源需求等手段。

项目领导希望第二天召开会议，您只有2小时确定主要过程中要考虑的主要因素。

此时，着手分析调研信息或许是个好主意。例如，找出其中有关以用户为中心的设计、可用性工作、图形用户界面、网页用户界面和手持设备用户界面补充信息的参考书目。所需要的其他信息与一个讲究高速度的软件开发过程的演化和迭代有关（对于较慢的开发过程，当然没有必要查找参考信息）。

经验法则：

养成一个好习惯：在网上使用与项目相关的关键字查找信息。尽管搜索结果中会出现大量信息，但适当的分类也不复杂。

6、对过程的总体看法

常规设计过程的方法是各种种样的（参见图2.4）。与开发过程相关的主要变量包括由外到内或由内到外、一次尝试（没有迭代）还是多次尝试（多次迭代）和大爆炸（也就是所有或没有）或改进的数量。

由内到外法重点在于系统内部，由外到内法的重点则在于用户界面和最终用户和产品的可视化功能。取决于项目的复杂性的所拥有的技术，最好能使用一种综合方法从内部和外部同时展开工作。

迭代法指的是所计划的产品中工程（特别是用户界面工程）的数量。迭代法的重点是构造用户面，并且用户界面的主要可用性因素被认为是软件开发的最佳实践。选择这样的方法能杜绝或排除开发团队在非用户界面工作中使用相同方法或在产品中使用其他技术的风险。

改进法的重点在于：对一个产品，使用一种逐步增加和逐步细化的方法构造整个项目。分阶段式的设计和实现各个层次的特色功能。大爆炸（即big bang）法是一种全部开发或全部没有的突发性开发方法—所有软件的设计和开发均同时进行。

经验法则：

可供采用的最佳方法是迭代法、改进法和由外到内法。

A.典型步骤

现代的设计和开发过程，本质上被描绘成迭代和应用快速原型开发的技术。这种项目成功的本质在于用户的参与。然而，依靠开发团队的经验、所使用的技术方法和选用的工具，迭代的数量会非常少而且无法加快原型的开发。

图2.5所描绘的设计过程没有表现出任何特定的用户界面风格，但它支持图形用户界面、非图形用户界面、网页、个人数字助理、面向对象或交互式程序风格。

◆ 该过程类似于开发的瀑布模型。

但它实际上是一个逆流而上的过程—随着时间的流逝，过个过程会越来越困难，它更像逆流而上，而不是顺流而下

◆ 随着时间的流逝，工作量和工作的复杂程度都会增加

◆ 一个小的需求会演变为大的用户界面屏幕、帮助和培训

◆ 用户界面屏幕和帮助被转换成与系统底部基础结构、网络和基础数据交互的设计实现

◆ 设计的实现很容易就转化成以数十或上百，甚至上千行少见的、过分讲究的编程语言、数据库语言和通信语言以及数据结构来完成的程序指令（代码）

◆ 这些代码将被测试，用以证明其可靠性、性能；质量以及是否满足功能需求、用户界面需求和可用性需求

◆ 随着时间的流逝，参与开发的人数会增加。不幸的是，人员的增多并不能减少每人的工作量

实际上，对于过程的很多方面，并没有固定的标准。最典型的是在构造阶段，校正需求、构造上的缺陷时，设计也在持续进行。项目的很多阶段一般都有交叠，例如，在整个项目生命周期中计划（风险管理）和需求（控制）会同时进行。

这里没有描述迭代，但它是成功退出每个过程阶段必需的过程，因为它会进行很多尝试跳过后续的瀑布阶段。迭代的、改进的过程模型是基本瀑布模型的变体。两者的主要区别是经验丰富的迭代早于软件部署。

过程的关键部分是构造阶段。产品的实现和测试是在开发过程中的这个阶段进行的，并且即使计划和管理非常理想、恰当，这一阶段仍然会占整个项目进度的50％。

经验法则：

为了确保满足应用软件的用户界面、可用性和其他需求，迭代和继承的细化可能最为必要。产品的其他关键因素（如临界回应时间）同样也需要。

这个过程一定是非线性和不确定的。即使是特定模块的子任务，也不可能是正交的。记住，实现成功取得所需结果的承诺必不可少。这个承诺需要进行多次反复，才能表现出满足最终用户需求的决心。所采取的迭代行为不单单是为了迭代，而是为了成功实现用户的需求目标。

B.更好的方法

对大多数开始来说，一种较优秀的、并具有战略意义的备用过程模型便是以用户为中心的设计（User-Centered Design，简称UCD）。产品的开发仍然按顺流而下的方式进行。但会提供简化的方法和技术，消除过程中的关键临界因素。开发功能、用户界面、信息和其他特色性，可利用基于技术（如迭代、改进和分阶段法）的方法来确定已满足所有需求。

经验法则：

对过程数量的重视并不能保证项目成功。成功满足需求的承诺，离不开努力工作。

C.以用户为中心的广度

以用户为中心的设计（UCD）的概念，因为多年来成功项目的增多而改变了它的地位。如果大多数软件公司都实践了UCD，并证明了其重要性，为什么还会有如些多糟糕的产品呢？

部分原因是用于界面的UCD太拘泥于以设计为导向。UCD的结论超出了初步设计和早期设计范围；并且应用于很多难度较大的阶段（如实现阶段）和随后活动中的详细设计，实现设计和设计完整性的归档文件。软件开发较为乏味的阶段，必须坚持UCD，而且必须明确且方便使用。

以用户为中心的产品开发—一个软件的开发过程包括多种学科，是迭代的，其重点是实现用户界面、可用性经及整个产品生命周期中的其他可度量产品目标。

以用户为中心的产品开发过程如图2.6所示。以用户为中心的主要概念融合在这个图中—计划的迭代已嵌入开发过程、学科多样化的产品团队、有意义的用户参与及满足需求而进行的评价和演变过程。

这个过程是对UCD的扩展。UCD着重强调为实现软件、用户界面、使用性和其他目标而要求产品团队必须完成的任务。尽管每个开发里程碑只描绘了一次迭代过程，但是在每个开发阶段都可以有多个迭代过程。关键在于一直进行迭代，直至满足需求。

D.计划

面临特定的、难度较大的任务时，清楚地制定一个计划是最合理的第一步（如图2.7所示）。

以一种可度量的方法，把重点放在用户界面和可用性过程要素上，有助于发现一些含有较大风险的非过程因素。为了取得成功，须注意以下几点：

◆ 产品计划需要特别说明过程中的每个步骤、用户界面及可用性成果，包括依赖性、假设和技术方法等进度里程碑

◆ 产品计划会标识并提出主要的风险因素

◆ 一个产品计划应尽可能具体描述有利手项目效率的技术（如降低风险的方法和保证满足需求的方法）

◆ 产品计划的执行需要说明并跟踪用户界面和可用性等与计划相关的成果的质量

◆ 管理方法是对前期参与的详细说明。和其他管理任务一样，尤其重要的是要建立一支具有相应技能的适当团队。多样化团队的思想理念是：成员都具有所需能力

◆ 分配责任和义务

◆ 确信已建立了产品用户界面和可用性目标和标准

第8章将深入讨论如何制定产品计划。

E.需求

对最终用户来说，界面、可用性、一致性和集成性等方面的需求是特别细致的，但缺乏特点。与功能特色相比，对用户界面和可用性上的需求有很大的想象空间。因为缺乏计划且思路不清晰，导致了很多非常虚幻的用户界面和可用性结果。需求阶段特别需要做的任务包括：

◆ 描述用户，参见第3章和第10章

◆ 用户任务，参见第10章

◆ 当前的可用性，参见第14章

◆ 用户界面特色，参见第5章

◆ 发展趋势，参见第20章

◆ 对用户界面、可用性和一致性等方面的需求，参见第9章.

F.概念设计

通常，计划和概念设计不会在过程中清楚论述，但它会被认为是用户界面的构架。概念设计从总体上概括了高层的描述、提炼和信息，它为开发人员和最终用户提供一个关于产品、产品结构和产品界面的大蓝图。

◆ 概念是源于实例的一些抽象想法，设计是对系统元素的、深思熟虑的组织形式

◆ 概念设计如同一个描绘产品主要功能、各部件组织和未来用途的轮廓或蓝图

◆ 与产品概念设计相关的开发成果是对以用户为导向的整体介绍和描述产品功能与用户界面的文档

第11章将提供一个虚拟的目标用户模型，但其设计原则和指导方针将在第12章进行描述。

G.设计

设计是一个基础的、对实体构成元素的设计和安排。用户界面的设计实际上就是收集最终用户对一个软件的可感知功能，包括用户输入、交互和系统对用户输入及交互的回应。设计基于用户界面的应用软件，有很多方法。需要考虑的一个关键是将设计分解成很多小块的、容易理解的成果—如同打磨一颗珍珠一样。由于理解、集成和管理细节的工作量非常大，所以有必要实施迭代和分层设计。目前，为了确保用户可见的基础底层组件彼此正确集成和支持，还要执行用户界面的非用户界面的工作。

扩展性设计将在第16、17、和18章展开描述。

H.原型化

原型和模拟是对早期设计进行评估的有效工作。模拟，或是模型，是设计的实例化，但没有必要用未来的实现平台来构造。取决于具体的时间限制、设计问题、能力和可用工具的不同，素材板或素材纸的模式将是一种恰当的设计表示方式。原型是使用未来实现平台实现的一个设计实例，包括硬件、操作系统、实现语言和工具。

不同类型的模拟和原型呈现了用户界面或系统功能表现方法、用户界面表现的逼真度和介质构造等有深度和广度的问题。因为原型的概念涉及到很多方面，所以被赋予了不同的名字：用户界面、功能、低精度（即粗略）、高精度（即细化）、轻量级等。详细定义工具及其限制总是好的。如何构造原形，将在第13章详细讨论。

I.规格说明

用户界面的规格说明就是指以文档方式对产品设计的实例化。它描述用户行为、软件外观和特殊情况的状态。即使是简单的应用软件，也可能有非常复杂的规格说明。有关规格说明的详情，请阅读第17章

J.构造（编码在单元测试）

用户界面软件是设计的最终实例化，它经过了很多阶段的演化；例如模拟、原型、构造和文档。同样地，没有用户界面的软件也有很多阶段用于构造和编写文档。过去有句名言说道“软件需要写3遍才能保证正确”，做原型对进入部署环境就取得成功大有帮助。有关构造的详情，请阅读第19章

K.评估

所有的评估技术都要涉及到产品的潜在用户。为了确保需求得到满足，尽量在早期频繁使用这个技术，这是非常必要的。一种最佳实践的方法是在计划、设计、构造、评估和部署等阶段都有实际用户的参与。这样的方法称为参与法。

评估技术贯穿于产品的整个生命周期，但发生于较细的、有用户参与的开发周期中的一些离散的点。有关可用性评估方法的详情，请阅读第14章

L.迭代

为了实现用户界面的既定目标，所有标准都必须清楚，便于管理者和开发人员理解和接受。整个产品团队必须达成真正的个人承诺上的一致，而不是口头上的接受。一旦开始开发用户界面的设计，就可以会为了达到目标而多次迭代。如果达不到目标，整个设计可能会被抛弃。有关迭代的详情，请阅读第15章

M.部署

当然，产品一旦满足了需求和用户的需要，就会开始为最终的使用进行部署。此时，还有一部分跟踪活动，如评估未参与开发过程的用户以及指导和进行的先期测试。软件也是有设计和开发阶段没有测试或预见、但又执行了用户任务。此外，业务变更也可能产生有新的产品需求。为最终用户完成部署后，再随着基本功能的进展而展开测试是最合适的。

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号