Larry Constantine 著harvey 译
我们常被问及精简那些最简化、抽象和通用窗体用例的重要性。到底有多重要呢？在以用户为
中心的设计中，简化那些重要窗体的用例是获得成功的关键。它能够为开发者设计优秀的用户界面
助一臂之力。通过消除不必要的或技术驱动的操作步骤，设计者可以使用户界面上那些最常用或最
基本的操作变得简捷。
最近，在我们一家欧洲客户的培训课上有一个十分清晰的例子。问题涉及一个为“捶击者
(thumper)2000”设计的触摸屏控制面板，“捶击者(thumper)2000”是一种测试工业原材料的机器，
可以把被测试物件击碎（在这里我们不讨论那些无关的细节）。一个重要的用户角色被称为“标准
化测试员（standardized Test Runner）”，基本上，一个机器操作员很少了解所测试的材料和测
试本身，但是他能够机械地设置机器，初始化和监视一系列预定义的测试过程。在某些特殊的情况
下，这类操作员可能会对标准测试的规则作一些小的调整。
针对“标准化测试员”这个角色，有一个我们称为“执行预定义测试（running predefined test）”
的重要用例。对这个关键用例可能的描述如下所示(左边第三步指明了一个用户发起
（user-initiated）的可选扩展操作，这是另外定义的一个用例)。
这里所争论的是：一个标准化测试员可能会忽略其他操作或者对其他操作不感兴趣，但为什么
在开始某项操作前总是必须告诉系统是针对那一项测试？得出较复杂版本用例的小组是沿着表格
右边那条线索得到的主界面原型。这是一种十分常见的用户界面窗体：开始于一整套按钮让用户在
开始工作之前选择要执行的操作任务。与许多平庸的常规设计一样，它把额外的步骤强加给每一个
用户。
简单一些的用例反映了一个不同结构的用户界面。使用简化用例的小组，设计了一个把标准化
测试列表置于顶级主界面的原型。这样的设计源于表格左边那条线索，它允许直接执行那些最常用
的任务而不用切换屏幕。
当然，不应该天真地把这里的想法应用到每一件事情上。如果走到一个荒谬的极端，只是为了
简化用户操作步骤而把用户交互控制在一个界面显示，那将会把所有操作平铺在一个屏幕或对话框
上。任何设计都有一个权衡的问题，窍门是决定在哪里划一条界线。在这个简单的实例中，这条线
画在对最简单的使用所做的最简单用例旁边。更复杂的情况，比如定义新标准化测试（defining new standard test），隐藏在另外一个层次，这是相当合理的。
对于相对较小的设计问题，不管用例是否精简，也许一个经验丰富的开发者仍然可以开发出最
简化的操作。然而，当用例数量的增长对系统的影响越来越大时，将用例简化到最精炼程度的优点
就变得实实在在了。
