Question

从以上对失误的研究中，我们可以得到两个方面的设计经验二第一，采取措施，防止失误发生；第二，失误发生后，要能够察觉到问题所在并加以纠正。通常情况下，我们可以从前文对六种失误的分析中，直接找到对应的解决方案。例如，要想避免功能状态失误，就应当尽量减少产品的功能状态，或是将功能状态在产品上显示出来。

在汽车设计中我们可以找到很多有关设计与失误这两者之间关系的例子。汽车的发动机部位需要几种不同的液体：发动机油、转速油、刹车油、挡风玻璃清洁剂、散热器冷却液、蓄电池补充液。万一把液体灌错了，就会损坏机器，甚至会造成事故。汽车制造商试图降低这些失误(描述性失误和功能状态失误)的发生率，设计出了大小不一、形状各异的容器来装这些液体，并在液体中添加不同的颜色以示区别。这样的设计在一定程度上防止了失误的发生，但遗憾的是，有些设计者却似乎更偏爱那些容易导致失误发生的设计方案。

有一次我在得克萨斯州的奥斯汀市坐出租车，看到司机座前有很多新设备。老式的无线电早已不见踪影，取代它的是一个计算机显示屏，车辆调度员发出的信息可在屏幕上显示出来。司机兴高采烈地向我演示新设备的所有功能，我注意到收音机部分有一排四个外形完全相同的按钮。

“噢，这个收音机有四个不同的频道。”我说。

“不，”他回答道，“只有三个频道。重新设置频道时才会用到第四个按钮。我得花上半个小时才能把这三个频道重新调试好。”

“嗯，”我说道，“我敢肯定你一不小心就会按下这个按钮。”

“的确如此。”他回答说。

为了避免失误，计算机系统通常在执行某一指令之前，要求用户对该指令进行确认，尤其针对那些能够破坏文件的指令。但是这二要求出现的时机不对，它往往是在用户发出一项指令后就立即显示在屏幕上，然而用户在这时还并未意识到自己的操作失误。下面是一段标准的人机对话：

用户：删除“我最重要的工作”这个文件。

计算机：你真的要把“我最重要的工作”这个文件删除吗？

用户：是的。

计算机：你确信？

用户：当然。

计算机：文件“我最重要的工作”已经被删除。

用户：哎呀，真糟糕！

用户让计算机删除了一个本该保留的文件，而计算机提出的确认要求不太可能防止这一失误，因为计算机让用户确认的只是一项操作，而不是文件名。比较恰当的做法是避免设计出不可逆转的操作。比如说在上例中，计算机可以把刚刚删除的文件暂时存放在某个地方，用户一旦发现自己误删了某个文件，还可以将其恢复。

在我曾经管理过的一个实验室，人们经常把文件或记录扔掉，第二天才发现被扔的东西还有用，于是后悔莫及。为了解决这个问题，我们准备了七个废纸篓，在每个纸篓上面写上星期几，也就是说，标有星期三的废纸篓只在星期三使用，到了星期三晚上就将这个废纸篓稳妥地存放起来，直到下个星期二才将里面的废纸倒掉。

后来发现，人们桌上的书和文件要比以前少多了，他们常会毫不犹豫地扔掉自认为是无用的材料，反正现在扔东西很安全，即使出了错，也还有足够的时间把它拣回来。

然而，每种设计都有其利弊。多出的六个废纸篓不仅占地方，还使我们与清洁工之间无休止地争执着，因为他们总习惯在每天晚上把所有的垃圾都清除掉。计算机中心的用户也开始对这些废纸篓产生依赖心理，把一些本该保存一段时间的文件不假思索地扔掉。万一清洁工或是我们自己在处理这些废纸篓时出现差错，麻烦可就大了。因此，在设计一个能够承受失误的系统时，最好将该项性能设计得可靠一些。