我们可能已经论证过我们生产肥件(fat ware)的能力，但不是我们生产出更有价值产品的能力。我们在项目重压之下作出的很多好的程序代码也许会因为大多数用户今后仅使用我们费尽心思做出的产品的极小一部份而宣告浪费。奇怪的是很多这样的功能在一堆控件，菜单，对话框之中根本不可能找得到。我们结束对那些将来没有用的特性的咒骂，并且留下有用的部分。我们也由于将简单的任务复杂化而遭到谩骂。
我们的一些为改进这种状况的所作的努力可能仅仅是使事情更糟。我们急切的使用最新的3D直观模型，却只得到不领情的用户的埋怨。他们读不懂我们的一个个灰色的对话框。我们用密密麻麻的带图标的工具条来告诉他们这里有很多功能，但是他们觉得这很难理解。可能当我们在第一步做了一个简单的界面之后我们会设计出改进了的界面向导来使复杂的界面易于使用。
一个不漂亮的事实是可用性并不是基于这些吸引人的图形、改进了的可视化控件或是活动的Agent(译注：可能是指MS- Office里的Agent)之上。你不能从3D直观图，彩色图标或是浮动工具条中获取可用性。这不仅仅涉及你使用了什么窗体控件，还包括你如何使用这些控件，以及这些控件如何整合在一起工作。
最终，可用性来自于用户界面的体系结构迎合了用户所希望的实现。这意味着你不得不通过了解用户的工作来使你的软件迎合要求。这也意味着你必须设计出整个用户界面的体系结构。这包括了用于支持这个工作的所有的结构细节以及动态行为。
为了做到这些，为了在软件中设计可用性，你需要工具。你需要工具来弄清用户需要做什么和他们需要什么来支持他们工作的进行，你还需要工具来组织复杂的用户界面的体系结构而不遗漏掉任何细枝末节。或者说，你正准备好去竭尽全力制作出一起被提交的程序，你需要能够集中你的注意力，有效的利用你的时间，因为当用户抱怨时，老板会逼着你在规定期限内交付新程序。所以，你也需要一个简单的灵活的工具来组织你的工作。
这篇文章介绍了一些用于制作更好的（用户用的）工具的工具――简单的用于制作出能很好的满足用户需要的小而简单的系统的方法。这当然不可能是一个完整的故事，也不能使你变成一个可用性的专家。但是这可以给你一些比较前卫的想法而使你的下一个项目有真正的改观，帮助你一开始就能制定出可用性而不是中途应要求突然改变或是最后的时候再将它加进去。
围绕可用性的设计
用户和用户界面的问题并不总是发生在现在。在一开始，并不存在用户，只有操作员以及只是疯狂操作电脑的 程序员，他们反复操作开关并观察着操作台上的灯，并不存在给用户的真实界面。有打孔卡片，打孔带，还有打印机。你把卡片或带打上孔并不断送至读卡机，并将打印机里打印的每一页存储起来，终端用户就获得有一行行记录的报告。其中的一些内容被格式化，还被排列成多少有点可读性的序列。
技术人员更注重的是技术而不是人，因此程序常在发觉用户的存在之前就形成用户界面。这样注意力被集中在技术问题上，如屏幕的绘制和域长，数据确认以及退出键的设计。偶尔也曾意识到用户，就是真正的人，正坐在系统另一端注视着屏幕，而且敲击着功能键。也许轻视和忽视用户的症状由来已久，专业通行了一种有友好的用户界面，却有平淡无味的交互的主流，往往就形成了覆盖在同样陈旧的狭隘和顽固的编程方式上的一层薄纱。
文章来源于领测软件测试网 https://www.ltesting.net/
