2000年7月，一群同行召集起来就以使用为中心的（usage-centered）设计的现状和未来开了个会。这次会议不仅作为一个论坛来回顾和巩固在以使用为中心方面累积的经验，它更是一个研讨会，用来精炼和改进这种方法，特别强调和其他设计开发过程与模型的交叉渗透。那次讨论衍生出许多概念上和实践上的突破，其中之一是抽象原型，很引人注目的一种改进形式。它基于任务模型，简化并加速了高质量用户界面设计的生产。
抽象原型是以使用为中心设计的一个强有力工具（Constantine, 1998; Constantine & Lockwood, 1999），允许设计者描述一个用户界面的内容和全局组织，而无需详细说明其外观或行为。因此，它是待设计用户界面结构的模型。我们和我们的客户发现，抽象原型是一座有效的桥梁，它沟通了基于任务案例（本质用例）的任务模型和实际原型形式的最终设计。在文章和在软件中都是这样。尤其通过集中关注内容、组织和功能，而非布局、外观和行为，我们一再认识到，抽象原型有助于可靠的体系结构和创造性的变革（Constantine, 1998）。如果有恰当的任务模型作驱动，抽象原型能帮助设计者作出实用而新颖的用户界面解决方案（Constantine, 2000）。
在进行以使用为中心的设计时，内容模型和导航图构成了抽象原型最常见的组成部分。内容模型包含一系列由抽象组件组装成的视图（交互语境），抽象组件亦即用户完成每个视图支持任务所需的工具和原料。导航图对内容模型进行补充，它表现用户界面里所有视图（交互语境）相互连接时可能的路径和转换。
常规的内容模型中，最典型的是贴纸形式，每个视图通常由一张单独的标签纸表示，纸上粘贴着抽象组件。简单图示符（小图标）用来区分原料和工具，原料给用户提供感兴趣的容器和信息，工具则为用户操作这些原料或执行其他的动作。
其他抽象原型的变体形式包括“线框（wire-frame）”模型和抽象布局图表。如图2所示，线框模型描绘可见用户界面元素的相对大小和位置。区域的色彩编码也可以用来说明元素对应的类型，或者信息、功能的相对重要性或优先权。这种变体形式在基于web应用的图形设计者中有一定程度的流行。
如图3所示，抽象布局图表是一种“低保真度”的原型形式。它显示了用户界面元素的相对大小和位置，但没有确切的外观。
各式各样形式的纸上（图表）原型可以按照从最抽象到最具体或者说最实际作如下排列：
1.常规的（完全抽象）内容模型；
2.线框（wire-frame）模型
3.抽象布局图表
4.低保真度纸上模型（粗略的草图）
5.高保真度纸上模型（真实的细节设计）
抽象时的难题
尽管已经证明抽象原型作为设计工具很有效，但也证实对某些设计者是块绊脚石，尤其那些相对缺乏经验或对以使用为中心的设计还在入门阶段的设计者。最常见的问题包括：
● 用抽象术语命名或描述组件的困难
● 区别工具和原料的困难
● 将抽象组件转化为物理组件的困难
● 通过抽象视图布置屏幕和其他用户界面上下文的困难
在命名组件用以支持任务案例的时候，经常发现缺少经验的设计者在抽象条件下思考是困难的。他们常常竭力去设计近似的不承担义务的抽象名字。应该叫做“Employee
Record”，还是“Employee Record Holder”，或是“Employee Description Holder”，抑或别的什么名字？如果没有对术语进行仔细的选择，设计者可能在实现真正的用户界面时，不经意地混淆想象中的假定和组件应该具有的最终形式。比如说，一个名为“Employee
Data Grid”的组件，可能意味着特别的用户界面数据控制。
因此，以使用为中心的设计不赞成用过于特殊或一体化的技术名词或行话来做抽象组件的名称。比如，相对于用“Search Criteria Entry
Field”，是否用“Sought-Person Description Holder”更值得鼓励。然而不幸的是，即使这种习惯在所有特定执行中都作为义务遵守，如果严格地遵循，会在后期把抽象原型转化为执行模型时带来自身的问题。如果由于抽象的影响，应用领域的精确术语，例如实际域的类或方法的引用在上下文模型中被弃用，那么，模型——尽管如预料中那样直接得自任务模型——也可能和其他设计模型以及项目其它部分已制定的词汇表脱离。
遵循推荐的抽象组件命名协议（比如，"Name Holder"、"Constraint Stuff Getter"，诸如此类），设计者最终能得到的不但和最终物理设计脱离，而且和其他模型脱离的模型。这些脱离的联系最后必须在设计里恢复和重建以完成和建造设计。（比如，在一个项目里，设计组常常必须在设计可视原型前回顾每个视图中哪个域对象相互关联。）
高度抽象组件组成的内容模型也难以和外行或开发组的其他部分共享：基本上，如果开发的时候你不在场，那么它们对你而言没有什么意义。
刚起步的设计者还为这样的问题所折磨：要满足任务模型的某个特定要求，到底应该用主动组件还是用被动组件？也就是说，该用抽象工具还是抽象原料？可进行编辑的显示项是主动工具还是被动原料？争论还在持续！
沟通语义隔阂的桥梁
暂且不考虑上述困难，对于多数设计者，一旦他们有过一些实践，就会发现自任务案例派生的初始内容模型通常较为直接。基本上，所要做的就是一步一步完成任务案例解说，确定用户界面所需的工具和原料来完成每个步骤。如图4的例子可以看到，立足于建模的角度，任务模型和内容模型之间的语义隔阂相当小。从各个步骤到抽象工具和原料之间存在着映射，映射即使不是完美的一一对应，也是相对简单的。
相反，充分抽象的内容模型和好的最终设计之间的语义隔阂通常可能非常巨大。实际的纸上模型看起来和内容模型毫无相似之处。在用户界面的抽象模型和实际模型之间存在着许多决策和困难的权衡。必须选择或设计实际的用户界面组件，必须决定屏幕布局，还必须解决其它外观和行为等方面的问题。非常熟练能干的设计者往往有能力较为轻松地跃过这类隔阂，尤其是在对以使用为中心的设计有过实践之后。而入门者和呆板的设计者通常会在这点上被绊倒。其结果可能是混乱不堪。
尽管最初发明抽象内容模型是用来帮助将任务模型转换为实际原型，但经验表明，它太过接近任务模型，又太过远离完成一个可视化交互设计的目标。相对于其收益，最初构思的抽象原型常常被证明太难于开发。
对一系列项目经验的回顾凸显了抽象原型法的许多缺点，但也让我们确信，任务模型和最终用户界面设计或实现模型之间的模型中介有整体上的优势。对于初学者，比起典型没有使用原型而达成的初始设计，抽象原型看来能通往实质上更好的设计。对于高级的成熟设计者，抽象原型促进创造性思考，导向更为创新的解决方案。
需要一个抽象原型的变体，它位于更接近最终设计的位置，用以充当任务模型和实现模型之间更优秀的翻译者。这样一个模型的修正形式要求：
（1）在开始更容易、更自然地开发；
（2）更容易转化成实际的可视交互设计；
（3）通过域模型更有效和模型的其余部分连接。
关于（3），一个显而易见的解决方法是，保证抽象组件的描述和名字使用领域和用户的词汇表，如同以使用为中心的设计中的其它所有模型。
要达到目标（1）和（2），我们认为用一组标准的抽象组件来构造抽象布局图表的形式能最好地构建抽象原型。对于经验较少的设计者，标准的抽象工具和原料能简化并引导抽象原型的构建，还能压缩最终设计的选择。比如，可以有一个设计者能够进行选择的列表，里面是抽象选择器可能的实现。对于更为高级的设计者，一组简单、标准化的抽象组件可以加速和简化建模过程，让设计者专注于细致的问题和创造性的解决方案。标准化抽象组件还应该能够让认可和描述某些模式更容易，这些模式支持特殊的可视、交互设计方案。尽管我们不相信描述抽象问题的标准方法能称心如意地把用户设计过程变成依葫芦画瓢，但它也许可以帮助设计组对某些标准问题作出好的解决方案来。
如同图形用户界面提供一套标准的实际组件工具包给设计者选择，规范抽象组件提供了一套标准的抽象组件"工具包"用于抽象原型构建。这套建议的规范抽象组件是经过多次持续求精和反复的尝试性应用之后才作出的。当前版本决不是一个理论最小集或无懈可击的，但我们相信它是实用有效的，它覆盖了在以使用为中心的用户界面设计中出现的所有公共案例。
表1概要地说明了这套规范抽象组件。规范抽象组件用名字和简单图表或图示符作标识，后者给高级设计者作为图形速记符号，并帮助抽象原型的可视化识别和判读。（我们敏锐地意识到，要让这样一种速记成为真正的捷径，适当的工具是必须的。）新的符号分别来源于两套已经用于表示工具和原料符号的主题和变种。尽管不是所有的符号第一眼看上去都能显得合乎直觉，但我们已经竭力使其在初次看到时就能充当有效的提示。
如表1所概述，建议的规范抽象组件包括：
（a）普通或通用抽象组件
（b）一套核心的附加基本抽象组件和
（c）少数辅助的专用组件，也就是那些即使理论上不需要但实践的观点公认经常是需要的。（可选的组件在表 1中用灰色高亮突出。）所有原料是一般容器的有效特殊化，而所有工具则是一般操作/动作的特殊化，所以一般组件总是可以用于任何目的。
原料
有三种基本的抽象原料：
● 容器（普通的）
● 元素
● 集合
加上一种辅助组件
● 通知
抽象原料建议的命名约定是完全使用内容的名字，亦即对象、类、数据元素，或类似的表示。如果阐明了模型的话，添加诸如"持有者"或"容器"之类术语也是可接受的，但不是必需的（例如，"当前机器配置"或"被翻译语言持有者"）。对于集合的约定是，或者使用复数来暗示是多个内容（例如，"特殊符号"），或者描述集合的种类或类型（"地址列表"），以此达到适当和必需的明确性。
无论是在纸上，还是在CASE工具里，或预打印表格中，抽象组件可以用图表单独标记，也可以用图表加上跟随用户提供名字的组件类型。例如：
● 集合：个人地址列表
● 个人地址列表
事实上，公告是一个消息容器或指示器，应该由表达的消息、条件和事件来命名（例如："太多条目"或"机器不同步"或"开启"）。
工具
操作和动作是两类截然不同的抽象工具。操作是在原料上进行作业的抽象工具，动作则是导致或触发某些行为的抽象工具。类属于动作/操作，有八种基本抽象工具。
1.动作：
1)启动 开始
2)终止 退出
2. 操作
1)选择
2)创建
3)删除
4)修改
5)移动
6)复制
3.辅助工具
1)接受
2)转向 连接
对于建模，接受工具可以当作一个主动原料使用，即一个容器从用户处取得输入；也可以当作一个操作容器的工具使用。对于一切实践上的目的，最一般的工具是启动/开始。
命名抽象工具建议的约定仅仅是说明动作。对于一般的动作，前缀"做"或"开始"是可选的（例如，"做符号检查"或"打印符号表"）。对于模型预定目的的结果清晰的地方，可以使用图形符号或只用名字。假设图形符号和动作名称在多数情况下可以互相替代。因此下边是对同一组件的三种不同描述方法：
● 关闭配置
● 配置
● 关闭：配置
在需要清晰的地方，操作原料的工具（操作）应该给原料命名。抽象原型里，操作只能放置在操作的原料上或一起放置在任何这样便于用图表表示和有意义的地方。
这在实践上整个看起来像什么？我们现在相信，对于多数的用户界面设计，最有用的抽象原型形式是抽象布局图表，其抽象组件的大小和相对位置是有意义的。
图5是一个使用规范组件的抽象布局的例子。它只是特意用作说明，并不是可仿效或值得仿效的。如例子所示，有时候其它组件内的抽象组件嵌套既是必要的又是有利的。
正如已经讨论过的，不同的抽象原型形式有不同程度的抽象。另外一种有价值，尤其对基于Web工程或非常大型的设计问题很有用的变体是基于文本的非图形形式，它仅仅列出视图和它们的内容。如下例子所示（基于图5的简单翻译），不管有没有图形符号，使用抽象规范组件改善了可读性，有助于阐述基于文本的内容模型。（注意抽象组件的嵌套。）
actions:
initiate/start
terminate/quit
operations
.select
.create
.delete
.modify
.move
.duplicate
auxiliary tools:
.accept
.go/link
无论对于经验丰富的、成熟的设计者，还是经验与才能都一般的设计者，在抽象原型里使用一套规范组件总是提供了潜在的好处。从规范原型到实际原型或最终原型的转化包括了两个并发而且相互依赖的关联动作：可视化设计和交互设计。
可视化设计包括：
（a）可视化组件的选择或设计，以实现每个规范组件能够结合
（b）界面上这些可视化组件在视图或上下文里的布局。
交互设计包括：
（a）交互习惯用语的选择或设计
（b）描述界面和底层系统必要的行为，
（c）组织视图或上下文之间及内部的交互工作流或次序。
对于常规设计，每个规范组件只需要用一个或多个标准用户界面窗口小部件实现。要达到最佳效果，设计者应该对每个抽象组件在各式各样可选实现做出决定。构造纸上原型的实验布局是基于这些方案的初始选择。典型地，实际用户界面组件的选择蕴含着许多交互设计，而布局则决定了工作流。为有效支持任务案例，应该相对于被支持的精炼任务案例，和组件选择与布局一起，检查作为结果的交互设计。
在以高性能或突破性设计为目标的地方，规范模型为创造性设计提供额外指导。使用规范组件使得有经验的设计者更易于辨认和区分模式或隐含了某种问题或解决方案的公共状况。比如，对以往设计工作的回顾表明，确定配置的成熟时机往往是发现新的用户界面控制--既能高效使用又能更好利用屏幕真实状态。例如在高级设计组的手里，容器、集合或内含（嵌套）工具元素之间的嵌套结合常常可以变成有效的非标准用户界面控制。
概括地说，基于规范原型的创新设计的过程是这样进行的：首先，记录联系紧密或成组的抽象组件，尤其是嵌套的联合。对于每一个这样的组或联合：
1.识别常规/例程实现和创新的部分；
2.选择有希望的联合；
3.合成并精炼。
作为一个简化的例子，考虑图6显示的抽象原型部分。其中，条目的集合可以被用户任意按新的顺序重排。许多可视设计的近似途径是可能的，除了其他的以外，还包括：
● 一个可编辑的顺序数字列表
● 一个列表，有up和down按钮，可以在表内移动选中的项
● 一个临时储存列表，允许在主列表内移去和重新插入项
每一个近似途径中包括了略微不同的可视化组件和布局发布。
交互设计包括识别可能的界面行为以及解决这个问题的交互习惯用语。包括：
● 点击选择源点和目标
● 拖放
● 编辑顺序数字
● 点击移上或移下按钮
一个有前途的、同时支持新手和更高级使用模式的联合应该既支持在列表内用上-下按钮移动，又支持用拖放移动。初始设计可能类似于图7（a），它凸显了几个问题。如果将上-下按钮和滚动条按钮放在他们通常的位置上，很容易造成混淆。如果只是简单地移到左边，则它们可能容易被忽略，并且它们的功能可能不清晰。
这样的问题可以用适当的可视交互设计来解决。如图7（b）所示，通过把上-下按钮移到左边，改变它们的形状，以及用彩色图示符突出它们，可以增强它们的独立性。如果一开始屏蔽（变灰）了上-下按钮，然后，当选了列表中的条目时，激活并用彩色高亮，那就能通过这种逐步启动的方式使界面带有启发性。可以在列表内拖放条目是一个值得采用的功能，尤其对高级用户而言，但这种功能是一种没有给用户合适反馈的隐式行为。只要列表中的条目被选中，在鼠标向下时把光标变成上-下移动的形式，可以移动的信息就能够传达给用户。
使用规范抽象组件的抽象布局图表提供了一个令人兴奋的新工具，它可以平滑和加速以使用为中心的设计过程。如本文所描述的，这些“规范原型”。
● 由特殊的抽象组件构造，它们从用标准符号描述的一小套标准组件中选择
● 显示布局，包括相对大小，位置和组件的嵌套或覆盖
● 和整个项目中其它所有模型使用相同的用户与应用领域标准词汇表
因此，抽象原型能简单而直接地从任务案例构造，并且比先前的抽象原型形式更接近最终设计。规范原型允许设计者轻易地对特殊的用户界面内容建模，以及试验大概的布局而无需提交外观或图形设计的细节。设计者拥有一整套标准但抽象的组件，并从中进行选择，用来表达用户界面设计的内容和大概布局。由于作为结果的模型在忽略细节的时候更为接近实际用户界面，规范原型促进了最终设计，而不至于失去创造性或非标准实现的可能性。
未来的研究可以进一步提高规范原型的价值。对于任何特殊的执行环境，可以预先对每一个不同的规范组件把不同的有用实现编成目录。特别对于新手，这样的指导相当有用。对于更高级的设计者，可以根据规范组件的联合和构造来组织和描述用户界面设计模式。
术语表
