热水壶的哨音和炉灶上煮菜的嘶嘶声，让我们回想起过去的时光，那时所有的物品都能看得很清楚，都会产生声音，让我们根据这些信息，形成操作这些物品的心智模式（mental model）和概念模式（conceptual model）。当无法按照原计划使用设备时，这些模式可以帮助我们找出问题的原因，知道下一步做什么，也允许我们试验各种状况。

机械式的物品比较容易一目了然。它们的活动部件都能看得见，能够观察或操作。这些物品产生的自然声音帮助我们了解机械状况，所以即使不看机器，只靠声音就能推断机械的运作状况。然而时至今日，很多像这样强有力的指标都看不见、听不到，藏在安静的电子零件里面，因此，很多设备都在静静地、高效地运转，除了偶尔听到硬盘驱动的“咔咔”声和风扇的声音，丝毫展现不出它们内部运作的状况。拜设计师所赐，我们才能得知一点设备内部的工作状况，了解设备正在进行的工作。

沟通、解释和理解，这是与聪明的共事者合作时的关键因素，不论是其他的人、动物或是机器。团队合作需要协调和沟通，再加上良好的预期，对事件发生或没有发生的原因就会有更好的了解。不管是人与人之间，技巧娴熟的骑手与马之间，还是驾驶者与汽车之间，或人与自动化设备之间的关系，这些原则同样需要。在生物界，沟通是生物遗传进化中与生俱来的部分，我们用肢体语言、姿态、脸部表情表达情绪状态。人类使用语言，而动物使用肢体语言、姿态和脸部表情。我们可以从宠物的肢体姿势，尾巴的位置和角度，耳朵竖立或下垂看出它们当时的情绪状态。有经验的骑手可以感觉出马是紧张还是放松的状态。

然而，机器是人工制造出来的，人们通常假设机器可以持续完美运作，而忽略了持续与机器沟通的重要性。如果机器完美运作时，人们难免会觉得为何有必要知道机器的运作状况。为什么？让我给你讲一个故事。

在加州圣荷西（San Jose）南边的优美山峦中，坐落着IBM艾曼登研究中心（Almaden Research Laboratories）。当时我正坐在这里的一个精美大厅里，聆听一场会议。演讲者是麻省理工学院电脑科学系的一位教授——让我在此称他为M教授，正在推广他新设计的电脑程序。简短介绍后，M教授十分高兴地开始示范他的软件。首先，他在电脑上呈现出一个网页，然后，他要用鼠标和键盘玩一些魔术。经过了几次鼠标的点击和键盘上的敲敲打打之后，一个新的按钮出现在网页上。M教授解释说：“一般的使用者都可以在他们的网页中加上新的控制指令。”（他没有解释为什么人们要这样做。）接着，他胸有成竹地说：“好，现在我给你们演示它如何使用。”他按下鼠标，等着下一步出现。我们等了又等，看了又看，但没有东西出现。

M教授非常困惑。他应该重新启动电脑程序吗？还是重新启动电脑呢？听众里面不乏硅谷最优秀的科技专才，纷纷给出建议。IBM的研究科学家们来来去去，匆忙检查电脑，甚至趴在地板上检查线路。时间一分一秒过去了，轻轻的笑声慢慢从听众席中传开。

M教授一向对他研发的科技着迷，从未考虑过万一失败该如何是好。对他来讲，程序正常运行时，未想到要反馈进展状况的信息——或者比如现在的状况，万一程序运行不正常时应当提供一些问题的线索。后来，我们发现M教授的程序其实没有问题，运行得很好，但大家无从知晓。问题在于IBM公司的内部网络安全控制，不允许他从公司内部网络连接上外面的互联网。不管怎样，没有反馈信息，没有关于程序运行状态的提示，没有人能告诉他问题出在哪里。他的电脑程序缺少简单的反馈信息，用来显示按键已经被激活，程序正在逐步运行内部指令，而且已经开始尝试进行互联网搜索，正在等待搜寻结果。没有这些信息回馈，使用者很难产生合适的概念模式。在众多的步骤中，任何一个步骤都可能出问题，但没有适当的信息反馈，就无法知道问题出在哪里。M教授开发的程序违反了一项基本的设计规则，即持续提供系统的运作状况，但不要对用户造成干扰。