Interactive Critical System And How to Build Them

Interactive Critical System And How to Build Them

论文翻译：罗淇允、吕栢霖、江锋

介绍

我们都知道许多令人沮丧的交互例子，它们通常因为没有过多的设计而让人感觉更糟。许多挫折要么是可以容忍的，要么是可以忽略的，因为对于依赖结果的用户来说，没有什么是太重要的。当用户试图做一些重要的事情时，会注意到一些困难；然后，通常情况下，正在进行的任务的紧迫性会妨碍理解挫折，当然也会妨碍为设计师反馈一些有用信息的冲动。但是，当这些任务对生活至关重要时，比如驾驶飞机或给病人放疗，使用者就更没有时间或精力去思考他们在互动中受挫的原因。具有讽刺意味的是，对于某些系统来说，用户在登录和类似的通信问题上也可能会遇到挫折，但是在成功“注册”之前，抱怨和提出错误问题是不可能的。
如果我们告诉设计师，他们的眼睛和我们的眼睛会在任何事情发生之前变得呆滞。当用户请求帮助时，他们可能已经有了很长一段令人沮丧的经历，并且在他们和他们的经验以及能够解决问题的程序员之间可能存在很大的概念鸿沟。因此，与其在挫折之后抱怨，而是需要一些法则——更高层次的方式来讨论问题——来避免挫折。
我们通常不会告诉木工把这个和那个碎片拿掉，还有这里的那个，或者这个……我没有时间告诉你这些，因为我现在就需要用桌子！相反，我们希望木工能使用避免留下碎片的方法。可能是打磨和抛光。碎片，就像bug一样，是进程出错的症状;逐个识别和固定碎片并不是最好的解决方案。我们不希望必须告诉专业木工有关碎片的事情，我们当然也不希望等到出现严重的问题时才去解决每一块碎片——仅仅说需要平滑的木材就足够了。
1992年1月20日国际航空公司里昂飞往斯特拉斯堡的ITF148飞机坠毁有多种原因。航空安全事故报告援引了机组人员工作负荷达极限，以及机组人员太晚才发现飞机下降速度过高的事实。下降速度过快的部分原因可能是飞行控制单元(FCU)未能正确进入垂直速度(VS)模式，而不是飞行路径角(FPA)模式，或者是飞行员对自己所处的模式感到困惑。飞行员以3.3度的下降角度下降33度，自动驾驶仪以每分钟3,300英尺下降，都会被显示为“−33”。由于这次事故，空中客车公司对FCU进行了一些设计改进，使数字VS模式读数为4位，FPA读数仅为2位。此外，法国BEA(航空安全网，1992年) 发布了34项安全建议。
最近市场上的一些计算器实现了一个意想不到的小数点设计功能。当用户键入数字时，键盘提供按键点击（声音反馈）以确认按键实际上已被按下。如果多次按下小数点，每次按下仍然会有一个按键点击（提供已按下小数点的确认）但是不会有任何反应：看起来，一旦有一个小数点， 进一步按小数点也什么都不会发生。
在其他计算器上，小数点作用的表现是不同的。在许多情况下，按下小数点会使小数点向右移动——因此，如果按“2.5.6”，实际输入的数字将是“25.6”。输入数字时点击小数点两次肯定是用户的错误。这些计算器无法检测此类用户错误，但它们以不同方式处理错误。如果用户注意到，他们会对实际输入的数字感到惊讶。这听起来可能不是很重要，而且在大多数情况下，这是本章开头概述的第一种挫败感的一个实例——如果没注意到这一点，就会忽视掉它。
计算器的设计及其用户界面的问题通常不是一个关键问题，尽管有人可能认为“在规模上”它们可能是至关重要，这样一个被数百万用户在日常生活中经历过的琐碎挫折，应该值得被像很少会发生的安全监测的关键那样被注意到。 然而，大规模生产的设备本身可能用于安全关键检测的情况中用户的意外行为可能不会被注意到，并且与日常情况不同的是，可能会产生严重后果（Miller，2013年，提出了在未明确设计的安全关键情况下依赖“COTS”或“商业现货”硬件和软件的危险性问题）。
这些关键问题不可能通过以用户为中心的设计来解决;设计师和用户都没有意识到这一点，或者用户忙于工作，而没有花时间去解决糟糕的设计问题。典型的以用户为中心的设计评估规模太小，时间也太短，这些问题很难被认为是“具有统计学意义的”。当然，以用户为中心的设计是重要的(Landauer, 1995)，但它显然不是全部。它可以找到一些碎片，但无法系统性地避免它们——这就像用手在木头上擦来擦去，看是否能在视线范围内捕捉到任何碎片，而不仅仅是在第一时间正确地准备好木材。

技术债务

“技术债务”的概念可以用下面的事例来说明。
我正在尝试创建一个用户帐户来向公司发送电子邮件，因为我想提出我之前遇到的问题，这已经致使我停止了我的购买流程。
你知道它是怎么回事：注册要求你提供一切。必须提供您的性别，就像它对计算机很重要一样。他们想要你的出生日期——从100多个选项的下拉菜单中选择。我尝试输入我的出生日期（恰好是1955年），菜单选择1959年(可能是从195开始的最大数字)，所以他们考虑了键盘快捷键，但却没有正确地实现它们。
我必须输入一个密码: 好吧，我有我的方法(一个字母，一个我记得的数字，和一些标点符号，以便在需要时让计算机高兴)。但一旦你开始输入密码，它就会告诉你一些复杂的东西——我想它说的是“密码必须至少有8个字符，并输入至少两个字符:数字、小写、大写、标点符号。”嘿！我在努力记住密码，而不是玩文字游戏！当然，公司的系统没有告诉我的浏览器这个字段是密码，所以浏览器不会在我以后需要的时候记住它来帮助我。
接下来我输入我的电话号码。方框中写着“电话号码(美国+1)”，所以我输入“+447525191956”，上面写着“看起来不对”！所以我意识到“(美国+1)”是一个“隐藏”下拉菜单，我发现菜单中找到英国（+44），但现在他们已经删除了我刚输入的电话号码，所以我不得不再次输入(这次没有+44)。我必须说，如果电话可以处理国际拨号，我真的不明白为什么网站无法正确使用。
最后，在填写完这张长表单上的所有内容后，我点击NEXT然后它说：“由于维护原因，该站点暂时不可用。”请稍后再试。
“返回”按钮会转到一个页面，上面写着同样的内容。我的表格不见了！我的资料不见了！我在新密码上花了很多功夫！电脑已经忘记了一切，明天我还得把整个过程再做一遍。我想我会告诉他们一些我的经历，但你需要一个帐户来联系他们，就好像他们已经仔细考虑过这一点，也许他们不想听到甚至连登录都不会的人的消息？
在这种令人遗憾又熟悉的体验中有许多明显的设计缺陷。
以用户为中心的设计可能不会有什么帮助，因为遇到问题的可能性太小而不显着(尤其是如果该公司进行了小规模的评估，并摆脱了他们认为的大问题，并且他们的客户主要是基于他们自己的国家)。他们的反馈系统(如果他们使用迭代设计)假设你甚至可以通过了第一阶段，所以这已经成功有偏见，他们只会收到能够创建帐户并登录的人的反馈。
公司可能会损失一点钱（即从我无法购买的商品和服务中获利），但他们不在意我的成本。 如果它们是理性的，那么，他们认为他们失去的比正确工作的成本要少：这就是所谓的技术债务（Allman，2012）。 为了在设计阶段节省资金，他们实际上是让用户在以后支付额外的费用。节省的设计费用由用户支付设计债务的利息来偿还。

解决问题

解决问题的第一步是意识到问题的存在，找出问题，并给它起一个名字，以便人们可以谈论它。或者，人们可以解决问题，或者甚至希望它消失，这显然是首选的方法——没有多少人会抱怨，所以它可能被认为是可以忽略而不是必须被解决的问题。
在确定了问题之后，我们必须以一种能够解决问题的方式来表达它，理想情况下，我们需要找到一种能够达成共识的方式。公司或其他组织解决他们的问题和我们认为问题已经解决是不同的观点！我们需要一种(原则上)能取得一致意见的方法。
把一个实际问题转化成数学问题是一个很好的方法。
与其争论我欠你多少钱，不如把它们写下来，把这些列加起来——这些数字的列数是什么，并且已经达成了几个世纪的协议。一旦以数学的方式表达出来，任何问题都已经超过了就其解决方案达成共识的一半。
一个着名的例子（来自Kahneman，2012）如下。 如果一个棒球棒和一个球的总成本为1.10美元，而球棒的成本比球多1美元，那么球的成本是多少？
答案是0.10美元，对吗？
错了！！(在聚会上这样做很有趣。)
让我们用数学来看,球棒的成本x和球的成本y。我们得知x + y = 1.1， x - y = 1，我们想知道球的成本y，但不幸的是，其中带有y的方程式中也有一个未知数x，所以我们需要从我们知道的一个方程中消除x；然后我们可以整理方程来告诉我们y是多少。
例如:我们知道x - y = 1，所以x = y + 1。我们可以用它来代入方程x + y = 1.1中，得到y + 1 + y = 1.1。我们化简为2y = 1。1 - 1，也就是2y = 0.1，也就是y = 0.05。所以，这个球的价格是0.05美元。几乎可以肯定，如果你得到了卡内曼问题的正确答案，你确实在头脑中做了一些非常接近数学的事情:你用数学来清晰地思考。其中一个有趣的是，把问题转化成数学给我们提供了几种解决问题的方法，如果你想的话，还有几种检查答案的方法，因为不同的人可以用不同的方法解决问题，所以它提供了达成共识和一致意见的重要方法。本章的主要观点是，计算机系统工程和设计问题比计算一个5美分的球的成本要困难得多，但是同样的应用推理原理可以得到正确的答案——并且知道它是正确的——即数学极大地帮助了我们。设计关键系统，尤其是涉及人机交互的系统，要比卡纳曼的简单问题复杂得多，也容易出错。
文明之所以发展到今天的程度，是因为我们发现了一些非常强大的技术来识别问题，并就其解决方案达成共识——主要是科学方法与数学相结合。这个标准公式还有更多的含义:一旦我们解决了问题，社会需要记住，这样我们就不必为不断重复解决问题而努力(甚至不必重复注意到有问题需要解决而努力)。技术是进步的棘轮，阻止文明倒退。好的交互式计算机系统确实做到了这一点：它们使世界变得更美好，比起一次只解决一个问题，它们使许多地方的许多人都能得到解决方案。这就是为什么基于良好的思维有好的解决方案是如此重要。
在HCI中，我们经常忘记对设计的可靠推理的需求——也就是说，做数学工作。仅仅可靠地观察世界(通常通过实验经验和统计数据来证明我们的答案不是由偶然变化引起的)不足以为关键系统开发可靠的设计原则，更不用说开发可以被开发人员理解和使用的原则了。
传统的HCI可能会发现一个用户界面与另一个用户界面有很大的不同，但这是一项罕见的研究，它试图找出背后的原理，以便下一个设计师可以从他们对项目的洞察中获益。
经验HCI的这种局限性的一个原因是，好的原则必须是通用的，并适用于新产品设计。这意味着它们通常必须有数学原理。菲茨定律就是这样一个例子。然而，HCI的研究人员，尤其是设计人员、心理学家和程序员很少去做数学并对其感到满意。事实上，正如上面真实的例子所证明的那样，忽略这些问题很容易就能把工作做得“足够好”:那为什么还要花时间学习和使用它们呢？同样，这是技术债务。
因此，用户界面似乎是优秀工程的一个例外;想想其他领域，比如手机通讯单元，当我们使用手机时，我们认为这是理所当然的。要让这些东西发挥作用是极其复杂的，但电信服务提供商雇用了有能力的工程师来设计和建造网络。并不是每个人都需要有能力，但在计算机领域，有时不称职会被当作技术债务。

HCI的关键问题是什么?

简单地说，用户的模型与工程师的模型不兼容，所以用户和计算机都“做事情”，但他们不一定从对方的角度做“正确的事情”。然后一系列的误解接踵而来，这将以用户的失望告终。
更准确地说，用户的模型具有属性，工程师的模型也具有属性，随着时间的推移，随着人和计算机的交互，适当的属性必须是并保持兼容的。
实际上，很难定义什么是“适当的属性”和“兼容的”。“人类和电脑可以学习，模型可以改变。现在我的笔记本电脑的特点是它正在消耗电源；如果电源故障，这不会改变什么，因为电池将无缝接管。据我所知，没有任何财产发生过变化。但是如果这种情况持续几个小时，我的笔记本电脑就会死机，我就什么也做不了了。
隐藏的属性会变得至关重要。
反之亦然:电脑认为我是“在场”的，但我可能会泄露秘密，而当我继续工作时，电脑已经“超时”，因为它认为我可能是另一个人。很明显，我不是(从来没有！)，但是计算机正在猜测用户是谁的属性。在这种情况下，这是错误的。
模型不匹配会导致众所周知的问题。幸运的是，大多数时候我们可以忽略、绕过或忽略这些问题；它们通常是刺激而不是灾难。
描述模型之间关系的数学方法有很多；我们将从抽象开始。当我们使用抽象时，我们谈论的是对象的属性和关系，而忽略了对象是如何工作的。如果我的笔记本电脑在工作，我就可以从电源的细节中抽身出来。不幸的是，如果抽象的实现泄漏到抽象中，抽象就会中断。我的抽象概念可能是“我的笔记本电脑工作正常，它的功能还不错。”抽象如果没有经过深思熟虑，就会变得过于复杂，不再有用。术语封装意味着抽象的实现不会泄漏并使正确的抽象过于复杂。
相反，当抽象假设、包含或公开关于如何实现的不必要的附加信息时，我们讨论实现偏差。在文献中，实现偏差以技术的方式进行了讨论，但在本章中，我们关注的是对用户的影响。下面是一些例子:

•住房和其他机构经常要求使用专有商业格式编写的文件。原则上，他们只需要文档，但是他们要求文档的特定实现，即由他们购买的专有格式提供的实现。,这是可以理解的机构购买实现所有的独特的特性,使它竞争(这无疑会升级到在市场上保持竞争力),但最终的结果是,你只能把他们“文档”,在当前的格式实现。
• 抽象地说，计算器执行算术。但是，如果我发现“2 + 3×4 = 20”，如果我假设这个不寻常的实现规则是普遍适用的，那么，当使用另一个能正确计算的计算器时，我就会犯错误，因为我偏爱在“不寻常”的计算器上不规则地实现算术。
• 考虑一个组织，它修正了自己的数据库，以跟踪员工的性别偏好，可能是为了帮助它遵守平等法。该实现提供了三个选项:男性、女性和不愿说。实现必须从这三个选项中为每个人选择一个选项作为开始，因此它迫使我的记录“宁愿不说”，而事实是我从来都不知道有人问过我；我从来没有说过我宁愿不说，我很高兴地说我是一个男性(如果有人问我)。现实未能提供该选项，用户未对此进行审查。如此糟糕的用户界面实现使得收集的数据偏向于“性别中立”。此外，一些用户可能更喜欢说一些没有实现选项的东西——有一些合理的情况既不是男性，也不是女性，也不喜欢不说。基于这些有缺陷的数据，我们可以得出什么结论?
•在过去，我们可以按照自己喜欢的方式填写纸质表格，而且速度和我们喜欢的一样慢。现在它们是由计算机实现的，通常我们不能在开始之前查看表单，因为实现不必要地要求我们在继续之前填写字段;此外，如果我们在将表单“发送”回服务器之前花了超过10分钟(或其他时间)填写字段，服务器可能超时并将丢弃所有内容，因为它拒绝保存不完整的数据。这些是抽象的“表单”本身并不需要的实现问题(就像在纸面表单中一样)。该实现增加了额外的功能，比如超时，这会使用户的感受变得更糟。
• 一个人进入银行，这需要身份证明。顾客拿出有照片的身份证，但银行说已经过期了。顾客说:“可我还是原来的我呀!”这个笑话的幽默之处就在于银行的执行偏见:对他们来说，一个正确执行的ID包括ID的日期，当然这与个人身份无关。

抽象语言表明，我们必须把很多事情视为理所当然。例如，当用户的抽象模型和计算机的抽象模型进行比较时，我们已经假设模型的某些部分以某种方式首先对齐。如果我的用户模型是一个文字处理器而电脑的模型是一个酒店预订系统，不管模型和属性是什么，事情都不会很顺利。

在心理学中，类似分块的概念也以类似的方式使用。随着人们获得技能，他们的技能变得更加抽象和分块，他们对自己技能的实现的意识变得更少，甚至根本意识不到。有趣的是，这意味着熟练的用户在设计交互式计算机系统时可能没有多大帮助——他们已经失去了一些开发人员必须明确实现的关键意识(例如错误和恢复策略)。

想象的抽象

绘制抽象及其关系的图片是有帮助的。为了帮助做到这一点，我们使用箭头。
符号“X→Y”将意味着“Y是X的抽象。”有时我们可能会非正式地说“X是Y”，不过要稍微调整一下以使英语正确，比如“X是Y”——这取决于X和Y的确切含义和措辞。
物理学家以抽象而臭名昭著:母牛→球体(或者用英语说:“考虑一只球形的母牛……”)就是一个著名的例子。
之前，我们使用抽象来解决Kahneman的问题:
球棒→x
球→y
x和y不是球棒和球，它们甚至不是球棒和球的美元成本;它们是数字的名字。(您注意到$ cost是$1.10，但是我们写了x + y = 1.1，而不是x + y = 1.10，因为我们也使用了抽象$1.10→1.1)
注意，我们可以将arrow语句转换成合理的英语，例如:“x是bat的抽象”或“一跟球棒是 x 美元”。
重点是:抽象是非常有用的，它帮助我们清晰地思考。
我们还需要清楚地考虑我们在抽象什么，以及我们使用的抽象是否正确。计算机程序被设计用来支持用户的任务，因此它们是“现实”的抽象。“我们在本章要问的问题是:这些抽象是正确的吗?我们如何确保它们是正确的，或者足够好来满足我们的需求?”
为了本章的目的，下面是一些更有用的例子:
用户→用户模型
或另一个:
计算机→屏幕显示
或者考虑这些更抽象的抽象:
计算机→许多位表示它的状态
电脑→开/关灯
我们只使用了四个抽象，上面的四个箭头显然是不同的箭头在做不同的事情。因此，箭头通常被命名为区分它们并跟踪它们。例如，上面最后一个例子中的箭头可能被称为“电源灯”。通常，箭头都是直接命名的，比如

电脑→(电源灯光)开/关
有时这个名字可能根本不带箭头:
电源灯光（电脑）→{}开，关}

这种数学符号将超出本章的需要。
箭头的优点是我们可以绘制箭头图，并且我们经常可以使用它们来提出一些有见地的问题。例如，在一些复杂的箭头图中我可能想知道我是否可以沿着箭头从A到Z，经过H，然后如果经过M，我能到达Z吗?如果经过M和经过H是一样的吗?这类问题很有意义，因为抽象箭头有一个重要的属性:如果A→B和B→C，那么A→C;或者，换句话说，如果C是B的抽象，B是A的抽象，那么C也是A的抽象(这个→的性质叫做传递性)。
稍后，我将举例说明我是如何通过用户的眼睛忘记箭头的。
我们需要讨论关键系统设计的第一个图如图1.1所示。请注意，我们如何允许箭头指向任何方便的方向，以使图表更清晰。我们还在单词周围画了一些圆圈:圆圈本身没有任何意义，但它使图表更整洁，偶尔也会让人明白圆圈里的几个单词都是关于一件事的。
注意，上面的圆圈是图中唯一“真实”的东西;其他一切都是抽象的。显然，图表本身是一个抽象概念，它还没有足够的细节来讨论我们在本章开头提到的那些关键问题。重要的一点是，我们可以开始在许多方面引入“实施偏差”;例如，如果我们是人类学家，我们会对不同的细节感兴趣，而不是我们在这里当工程师的时候。在这里，我想谈谈制造商，特别是程序员，可以做些什么来改善用户体验。

图1.1 使用箭头表示简单抽象关系。例如（右上）：计算机→计算机模型意味着计算机模型是计算机的抽象。 反过来，共享模型（底部）是用户模型和计算机模型的抽象。

计算机模型是用户看到的东西（例如通过计算机的显示器），也是用户可以通过与计算机交互来改变的东西。
图1.2，接下来，表示用户执行操作（我们不做解释，因为它是一种抽象的表达），而计算机解释它们（同样不做解释）。 结果是显示的内容。
这里的意思是“显示”而并不是700×1000像素的颜色，因为用户并不这么认为。 如果我们想让这个额外的抽象更清晰，我们可以绘制图1.3中的图表。
这更复杂，并且不一定有帮助。 将“计算机模型”定义为“计算机模型→实际像素”并因此抽象出该特定实现细节将更容易。
计算机不仅仅发生; 它们是由人类编程的。 图1.4是我们开始使用该方法之前的倒数第二个图。
用户如何在图1.4中创建输入已经被抽象掉了 - 我们可以从用户那里得到一个箭头到输入，但是我们已经将它抽象掉了（本章不讨论用户如何计算出来做什么，所以我们抽象了这个问题）。

图1.2 显示是计算机模型的抽象：它显示了计算机可以做的一些事情。用户操作描述了关于用户的一些信息，因此它们是用户的抽象。 因为对于任何箭头a→b→c我们可以知道a→c，那么我们也可以用箭头画出用户到计算机模型。

图1.3 使“显示”的概念更清晰。

图1.4右侧的两个箭头最终位于同一位置（即输出），因此图表说这些对象是相同的。
我们可以很容易地记住，我们必须拥有程序员和用户，因此我们可以将它们抽象出来以获得一个非常简单的图表（在我们的例子中，我们只有一个，但在更复杂的系统中，抽象它们可能为时过早。因为他们的社交网络和信息流可能很关键）。 图1.5显示了将它们抽象的结果。
图1.5再次显示了输出的单个对象。这意味着无论您是从用户模型还是计算机模型开始，您都可以抽象到相同的东西。 至少，如果我们相信图表（图表被认为是循环联通的，那么应该发生的事情 - 无论你走哪条路都没关系，你最终会在同一个地方找到相同的东西）。 为了使这一点更加清晰，下图（图1.6）与“命名”相同，我用数字替换了名称。 图1.6显示的，或者更确切地说，“它声称”是什么，如果你从1开始并遵循抽象路线1→2→3→4，你最终得到的东西就像你直接进入1→4一样，因为 （很明显）你已经完成了同样的事情，即4。

图1.4 HCI抽象关系图，这里表示一个在用户和程序员之间具有良好对称性的图表。

图1.5 在图1.4基础之上，将用户和程序员抽象掉。

图1.6 图1.5用数字代替名字。即使我们对数字代表的想法一无所知，我们已经从具体概念中抽象出来，以说明箭头是如何工作的。

图1.7 绘制图表不太合适的一种方法。用户模型抽象的输出，与计算机模型抽象的输出为不完全相同的东西。

实际上，这些图是理想化的。图1.7显示了经常发生的事情。
图1.7是一团糟;计算机所做的不是用户认为它应该做的。在传统的图表中，圆圈不应该像这样重叠（需要更多的箭头来划分抽象），但我喜欢输出变成维恩图的方式 - 重叠（但不是重合）的圆圈表明存在 从用户模型和计算机模型中衍生出来的抽象，并且有些东西是从它们中分别派生出来的，不会重叠。
为了比较，有趣的是绘制我们在本章前面非常成功使用的一个抽象图，如图1.8所示。
这个图表示（它“循环联通”） - 右指向箭头是“数学抽象”，向下箭头是“解决问题”抽象。 为了解决这个问题，我们同意y是（或将是！）答案。

图1.8 将Kahneman的问题绘制成循环联通图。

重要的一点——可交换性——无论你是从左上角到左下角的问题得到的，它都是相同的y。
和往常一样，我们可以使用“is”向后读取抽象箭头，因为y是0.05; 0.05是5美分; 最后，5美分就是答案。
早些时候，我们随便认为我们可以使用抽象$ 1.10→1.1，然后使用算术和代数来回到正确的美元价值——上图表明这种日常思维是可靠的，事实上它帮助我们解决了Kahneman的问题。 （数学家可能会更进一步，并为+和-等绘制图表;抽象及其属性一直向下运行，有助于摆脱分散注意力的细节。）
我们经常做这个或类似这个问题的事情，所有关于抽象的工作似乎都是显而易见的; 事实上，我们常常认为$ 1.10 = 1.10 = 1.1总是如此，但事实并非如此。
如果计算机认为1.10是1.1，但你认为它们不同，会发生什么？ 例如，假设您要将1.15输入计算机但不小心输入1.10，那么您可以点击删除，获得1.1，然后点击5，获得1.15。 不幸的是，你的计算机认为1.10 = 1.1，所以点击删除得到1.，然后你打5，你最终得到1.5，而不是1.15。 所以，有时“明显”的抽象是错误的！ 事实上，Thimbleby和Cairns（2010）表明，你可以通过纠正它们来改变这个问题。
总之，我们可以绘制抽象图。 有很多方法可以做到这一点，特别是对于像HCI这样的复杂问题。 对于像Kahneman这样明确定义的问题，图表更简单，更容易达成一致。 抽象图部分的好处是探索并找出表示问题的最佳方法。

案例研究1:数字

箭头图表是描述任何问题的符号，但如果您不熟悉它们，它们可能看起来过于武断而不是非常有用。
对于第一个案例研究，我们将使用数字——数字很有趣，因为：
我们可以看到和交互的东西（显示屏上的内容，按钮的作用），以及
它们是什么（计算器的数字，地图坐标，药物剂量，金钱）
是不同的，它们以相当有趣的方式不同。 此外，我们可以找到程序员弄错的方法，给用户带来不良后果。
数字有趣吗？ Ten等于10。怎么会这样？ “T”，“e”后跟“n”是英文单词，“1”后跟“0”是阿拉伯数字。 我们已经知道“Ten”这个词意味着我们称之为“Ten”的数字，我们已经知道阿拉伯数字“10”表示我们写的数字“10”，我们也称之为Ten，我们学得很好在很小的时候，它们似乎是一样的。 事实上，如果我们绘制数字的抽象图，我们就能看到很好的模式，箭头连接“十加一是十一”和“10 + 1 = 11”等等。 当我们说“计数”时，我们实际上在说“那是什么数字抽象？”所以••••••••••→ 10，当箭头表示“计数”时。
有用的是要记住，几个世纪以来我们非常确定X意味着10，XI 11，IX 9等等。 阿拉伯数字并不明显，它们不再是描述数字的“正确”方式，而是罗马数字或二进制数字。
问题是箭头图会变得复杂并且很容易出错。 更一般地说，构建具有损坏模型的交互式计算机系统并且没有实现它是非常容易的。 即使有一些像数字一样简单和熟悉的东西。
以手机平台上实现的计算器为例。 现在，许多计算器应用程序会有所不同，这肯定是另一个问题，为什么它们因为这样简单（并且有人会考虑标准）而有所不同，因为设计多种多样确实无法帮助用户。但是我们做这样一个假设，输入一个数字，用户按下按钮C（“清除”）几次。 用户多次按下它，因为他们过去已经知道这是明智的。 事实上，在第二次按下按钮变成AC（“All Clear”？）所以我们不妨再次按下它，现在它是别的东西。
现在，要输入一个数字（比如42），用户按下键4然后2.计算器将显示42.如果用户想删除一个数字，可能输入错误，向右滑动数字将删除最右边的数字。 到现在为止还挺好。许多其他计算器都是这样工作的，尽管可能使用专用的DELETE键。
到目前为止，我们早期用户模型图中的箭头都匹配（因为它们循环联通）。 但是一些有趣的事情尚未浮出水面以打破我们的抽象。 我们认为向右滑动会删除一个数字，但是计算器没有这样做，因为它已经将数字4然后是2转换为数字42.这些通常被认为是“相同的东西”但是一个是两位数，并且 另一个是一个值（巧合的是，我们使用相同的两位数字用传统的阿拉伯符号表示）。
为了实现“删除”，计算器基本上按42除以10并丢弃其余部分。 它做了一个数值计算，将42变为4，而用户认为“只删除数字2”。如果你删除数字4和2进一步滑动，你可以看到幕后发生了一些稍微复杂的事情。 计算器不显示任何内容（就好像它已删除了4和2）;它显示0，这是您未输入的数字。那是因为0表示什么都没有，删除4和2就什么都没有了——除了没有显示为符号0.技术上，没有→0。
有一个令人高兴的巧合，当0乘以10并且下一次点击加按键时，它将正确显示该击键。 例如，如果显示为0，并且用户点击4，则0×10 + 4 = 4，并且当用户在此之后键2时，则4×10 + 2 = 42并且计算器显示42.因此，如果显示0并且用户键入4然后键入2，然后显示屏将显示42，并且它直接执行此操作。 这当然是我们所期望的。（按下小数点后会有点复杂;我们稍后会提及。）
现在让我们尝试一些稍微复杂的事情。 让用户输入-42。 让我们假设该应用程序允许用户以多种方式输入-42。 有一个±键。 你可以输入±42,4±2,42±（我们已经有一个用户模型对齐问题：我想输入一个减号，但我只有一个±按钮）。 通常我们会从这些“小”细节中忽略，抽象出来并按下。
假设我们正在输入-42并且我们键入±4，然后是2.然后我们意外地键入另一个±。 那没关系，因为我们有一个删除：所以我们向右滑动，我们发现输入的数字不是-42但是4.发生了什么？ 我们键入了±42，在那个阶段计算器显示-42。 然后我们键入意外的±并且显示变为42.然后我们滑了一下，然后滑动删除了显示屏中的最后一个数字—2，而不是我们按下的最后一个键—即第二个±。
显示屏不显示用户键入的内容; 它显示了用户输入内容的抽象。 不幸的是，大多数用户将“删除”意味着“删除我刚刚做的事情”，而不是删除我能看到的复杂事情。 更糟糕的是，该应用程序的开发人员已经考虑到用户在任何时候键入±的“错误”，而不是要求它开始就要键入±，因此他们已经从按下±键时抽象出来。 在删除它时，计算器不知道。 虽然按下第一次±，但它将显示为 - ，进一步按下不会显示为 – 等。±键的作用是改变数字的状态，而不是它的表示方式。 因此删除不能正确使用±键。
如果我们现在考虑如何根据模型处理三次删除键的操作，我们可以在开发人员的脑海中看到这个概念错误。 如果用户输入，例如-42（它们键为±42但显示为-42）并且它们删除了三次，那么事情就会出错。 第一次删除将显示更改为-4，下一次删除更改为-0，下一次删除继续显示-NaN。
NaN表示“not a number”，这意味着模拟删除击键的应用程序失败了。 我用特定的设备解释了类似的问题并将其发布（Thimbleby，2015）。 制造商纠正了这个错误，但引入了新的错误，我们不在这里做演示。 重点是用户界面难以正确设计和实现，即使是简单，易于理解的事情，如计算器，即使指出了问题，领先的公司的领头程序员们也会觉得这很难。
总结一下：用户键数字并按下删除——用户的模型围绕数字作为具体字符串，我们通常称之为数字。 然而，在程序内部，程序员显然认为数字是数字。 对数字进行算术比编辑字符串（数字）更容易 - 除了（我想程序员认为）计算器确实显示数字不是吗？ 不幸的是，在边界处，数字和数字的行为方式不同，删除（或滑动）“打破了抽象”。
如果程序员认为他们的工作是实现用户的模型，那么显示器将显示数字，可以毫无问题地进行编辑，当用户按下+或除等等操作时，计算器将根据指示执行其算术魔术。用户界面更容易使用。
在抽象术语中，计算器实现了一个计算机模型，其中显示“用户键的任何内容”→数字。 这是一个计算器，其目的是显示数字！ 但是当用户键不是数字时，例如当他们滑动“删除”或按几个小数点时，此模型会失败。不幸的是，计算器使用数字而不是字符串来实现事物，因此没有任何修补就可以使用户模型正确。
忽略多个小数点也有另一个问题：如果用户多次按小数，他们就会犯一个计算器忽略的错误。 忽略用户错误意味着用户不会知道他们犯了错误，他们可能会遗忘。 我们的实验（Thimbleby＆Cairns，2010; Thimbleby，Oladimeji，＆Cairns，2015）表明，检测到这些错误并阻止它们可以将最终的错误率减半。
想象一下这个计算器应用程序具有相同的基础概念“数字不是字符串”，它可以在同一个手持设备上以横向和纵向模式运行。 如果手持设备转为横向，则用户可以输入很长的数字。 将手持设备转为纵向，像56585600000000这样的长数字可能会显示为5.65856e13（“e13”表示“1013 ”）。但是你没有键入显示的小数点，并且计算器上甚至没有“e”键。你键入的最后一个数字是“9”，甚至都没有以纵向显示。那么删除现在如何工作？ 显示屏将变为5.65856e12？
同样，我们看到计算器将delete实现为数字操作而不是字符串或用户界面操作。 “e”意味着“十倍的力量”，所以5.65856e13意味着56585555975599（但我们无法显示，当手持设备处于纵向状态时因为它不够宽所以不能这样做），当这个数除以10，它因此e13变为e12而不是e1。可以说，它可能已经删除了56585555975599的最后一个数字，但是用户看不到它有。
毫无疑问，用户会对这个界面感到沮丧。 但它们主要是第一种挫折——甚至可能是未被注意到 - 如果在safe-critical情况下使用，毫无疑问用户会“理智地检查”结果。 或者他们会吗？ 关于如何表示数字的错误概念模型可能使其使用比它需要的更不安全。 但我们永远不会知道多少。
那么，考虑一个计算器的设计，这个计算器是由那些知道计算可能很关键的人设计的，并且可能需要记录来仔细检查并帮助纠正错误，或者证明实际发生了正确的计算。 如果注意到，这里的错误将是第二种：烦人，浪费时间。 但是，如果将纸质日志用作证据或记录某些应该发生的实际交易，那么我们就会开始陷入第三种挫折——safe-critical问题。
我们假设这个计算器是为财务使用而设计的，所以它总是显示一个小数点，无论是否已键入。 现在，用户不小心输入一个数字和一个点“88”，并实现错误：两个小数点！ 用户按“删除”键。 但删除不能删除它，因为它“有”在那里。 因此删除会执行其他操作，在这种情况下，删除在两个小数点之前键入的数字。 它是这样做的，并且可能低于用户的意识。 用户现在已在寄存器中获得“8”。
避免这些问题要比描述它们容易得多！ 然而，这些问题看起来很神秘，请记住，他们最终会把人们赶出去，而在某些情况下，小挫折可能变成大挫折。对于大众市场设备，“小”的挫折感乘以设备拥有的庞大用户群。 每小时p的错误概率可能很小，但是多少是用户小时数N，pN是每小时错误的预期（世界上的某个地方），并且它不足以忽略。
具有讽刺意味的是，程序员的工作时间紧迫。 因此，如果他们快速完成设计，他们可以节省雇主的钱（也许可以获得奖金）。 但是，程序员在忽略用户界面设计细节的情况下节省的时间，如果他们获得了大量的市场份额，将为用户增加生命周期。 这是技术债务。

案例研究2：医疗器械指令93/42 / EEC

让我们考虑一个用在医疗环境中的平板电脑或手持设备医疗app。 我们还注意到“CE标记”，这意味着它已被欧盟批准用于此类医疗用途（符合在医疗器械指令93/42 / EEC中的相关条件）。 在这种情况下，应用程序的目的是计算已经烧伤的患者需要多少流体剂量。
该应用程序显示人体轮廓。（在PC上） 使用鼠标或（在平板电脑上）手指，身体上的烧伤区域可以勾勒出来。让我们假设，患者的脸部和左臂被烧伤，相当于体表面积的13.4％。
用户在图片上绘制患者烧伤的位置以及烧伤的范围，输入患者的年龄和体重，然后应用程序计算剂量。 帕特兰公式可用于实现这一目标，并且被被广泛认可。
由于存在小风险，应用程序可能已损坏或运行程序的平板电脑或手机已损坏，细心的设计师首先要让设备检查成千上万的计算，看他们是否都从Parkland的公式得到了正确的结果（这涉及安全并至关重要，所以这是一个很好的编程实践——所谓的完整性检查）。如果他们不这样做，那就可能出问题，应用程序会发出警报。
帕克兰的公式是一个不变因素，（对于这个程序）应该永远是可靠的或不变的。理想情况下，人们可能希望证明一个不变量是可靠的，但重点是某些东西可能不可靠，所以程序用大量的测试案例测试了不变量。
不幸的是，检查的不变量的范围只能包括计算机的表格和其中的数字，而不能覆盖到所有与用户交互的东西。例如他们输入的数字。实际上，用户对应用程序的了解可能和应用程序内部实际的情况非常不同。那些内部的抽象程序可以帮助我们思考。
例如，如果用户输入一个大数（可能是意外，按键的自动重复，在普通数字后面加上很多0，可以让这个数字变得很大。）数字显示在一个不大的框中，这个框不足以显示输入的完整数字。这就不是所见即所得。该标准没有说明要检查用户输入是否正常，所以输入可以是一个很不合理的数字（例如，患者体重大于地球的重量），如果在Parklands公式里输入了这样的数，就会生成一个错误的治疗指导。 这样的严重错误在临床环境中是显而易见的，但被忽略的可能性仍然存在。
更有趣的是，不变量的检查无助于确保用户输入的是正确的数字。不需要“新患者” 按钮，无需检查输入与阅读之间的时间间隔。因此，这些数字可能已经由之前的患者填写的，但前一个患者并没有完成这次的填写。这意味着可以输入一些前一个病人的数据，将设备放下，稍后输入新烧伤患者的一些数据，获得Parkland公式的结果，但推荐剂量是根据两个患者的混合数值计算的。检查是否仍然是同一个病人，虽然会丢失一些数据，但是总体是利大于弊的。
我们也可以想象出更微妙的用户界面问题。用户绘制烧伤患者的烧伤位置，不是让前面和后面分别绘制并显示在一起，如果让图像可以翻过来，这会让绘制更加容易和精准，所以前面和后面的烧伤分开绘制，这样还可以节省更多的屏幕空间。还要有一个数字框来输入百分比。如果临床医生知道背部的烧伤区域是45％，他们就不需要绘画，可以直接输入此框中的数字。这意味着用户可以画灼伤位置，让病人翻身，然后输入百分比，然后所有绘制的烧伤图像被删除。因为另一边的身体被遮挡，用户没有看到这件事的发生。
当然，百分比应该是烧伤面积占身体总面积的百分比，而不是和任何时刻身体被看到的面积的比值。但用户知道他们的想法与应用程序的模型不同吗？当应用程序不警告他们的时候他们怎么会知道？
从抽象的角度来看，这与我们用计算器时遇到的问题相同。用户在应用程序上输入数字（已烧伤区域的百分比，患者体重等），数字可以来自在图片上绘制灼伤的面积，或者它们可以是传统阿拉伯数字，如45。用户不知道应用程序的设计方式，即使用户界面设计允许，这两种数字输入方式也不能混合使用。
像以前一样，这些问题有点单调乏味。 本来应该的更好地防止问题而不是花时间描述它们（更糟糕的是体验他们）。他们怎么可以避免？
一个线索是使用不变量。让我们假设，遵循良好的实践并且用户需要获取认证，应用程序测试程序中的一些不变量。但是，检查这些不变量显然是不够的。
正确的不变量是用户认知模式 = 计算机模型，或更具体地说是用户的认知模式 = 计算机呈现的外部模型（用户可能不关心电脑里面发生了什么）。但目前，应用程序只是检查内部计算机模型是否和Parkland模型相同。 我们可以通过解决抽象问题找到合适的不变量。
应用程序实际检查的不变量实际上是这样的：
这个公式意味着要注入的量（几个小时之后的注入量，但这是我们在这里将忽略的细节）等于患者的质量乘他们燃烧面积的百分比的400倍（加上许多我们将在这里忽略的其他细节）。然后该应用程序用这个公式检查（从表中获得的）许多数字并检查是否正确使用了公式。请注意，如果表本身已损坏，则公示将不起作用，因此这是一个帮助发现问题的好方法。
不变量本来应该更像 V = 400 × m × A ∨ error（∨符号意思是“或”）。这个公式意味着Parkland公式正确计算或者有错误发生了。但是需要检查发生的哪种错误。首先，用户输入的百分比可能小于0或大于100，所以我们可以定义如下错误 error = A < 0 ∨ A > 100，当然如果患者的体重 m < 0，也要提醒错误，等等。然后就是一个有趣的问题：当应用程序因为用户没有明确定义它时而不知道 A（或 m 等变量）是什么。不变量需要更多检查工作：error = A未输入 ∨ M未输入 ∨ A < 0 ∨ …
现在我们开始考虑错误 error，我们可以想到去检查更重要的事情。不变量的一部分真的应该不仅仅是用户认为的数字而是实际上指代我们面前的病人的数字！所以，更好的不变量公示是：
不仅使用不变量公式是一种良好的做法，对它们的详细思考是更好的做法。现在我们发现应该改进原始的不变量公示。幸运的是，实际上很容易细化不变量公式。但是细化不变量就会产生更多需要解决的设计问题。怎样设计才能让程序知道现在是正确患者正在使用？它是如何知道错误的数字是多少？正如我们在“最终”不变量公式中所看到的那样，上面写着“还有更多”，我们现在需要开始思考 我们如何能够可靠地知道我们何时挑出了所有可能的错误并且表达在不变量共识中了！
当应用程序检查到“wrongPatient”变量时，它可能会显示一个对话框 “你确定你现在输入的数据和之前的数据是来自同一个病人吗？是 / 否？”然后应用程序可以回答 这个问题。 当然，还有其他方法可以做到这一点，比如使用患者条形码， 甚至决定“wrongPatient”变量太繁琐而无法解决。当然，不变量公式可以剔除其中许多微不足道的东西，例如，检查电池对于应用来说有点没意义，因为即使是普通电池，这个提醒都不需要。也许我们应该提醒用户要小心电池电量用光。
这些都是医疗器械指令93 /42 / EEC中涉及的重要设计问题。可以想象一组详尽的用户测试表明设备正常工作并且当输入正确时，按照规定提供正确的剂量，但不允许意外时的事件。由于人们不能预料到意外，唯一的办法是在设计过程中使用数学推理。

案例研究3：情境意识丧失

我设计并编写了一个使用颜色来帮助制作界面清晰的用户交互的程序（Thimbleby＆Gimblett，2011）。在里面，计算机编码颜色 RGB值，红色，绿色和蓝色的量。RGB值显示在屏幕的像素上，它们可以调配任何颜色。例如，红色和绿色在一起将显示为黄色。至少在我看来，编程中十六进制数字的颜色很有意思，它们代表的颜色都可以随时取用。（CSS是使用十六进制着色的另一个例子， 虽然它也允许颜色名称，如“蓝色”。）这个问题很像我们之前考虑过的数字的区别：颜色和RGB值就像是数字。RGB值是一个十六进制数字而不是十进制数字是一个幸运的巧合。
在设计这个程序的一个阶段，我已经使用了红色和绿色并需要一种新的第三种颜色，所以我选择了蓝色。所以我的RGB数值在程序内部是 x770000，x007700和x000077。
该程序工作得非常好，我很满意。
然后我的第一个用户尝试了，并立即问我为什么使用不可读的屏幕颜色，混合红色和蓝色！我不知道有些人是红/蓝色盲吗？我不知道知道红色和蓝色是最差的组合吗？他们在光谱的两端，特别是对于戴眼镜的人来说，它们的折射方式非常不同，这使屏幕难以阅读。
我一直没有意识到它，但我的用户认知模型和我的计算机模型显而易见不相同。他们没有同样的效果。
实际上，当我想到这一点时，我就知道了。 有趣的是，因为编程是如此困难（我试图通过十六进制给出一种风格的数字）我只能想出几个不同的RGB颜色，而没有办法去顾及其他事情。我有一个不同的RGB值，颜色肯定不同（我甚至不需要检查，当然他们是不同的）。关于“没有多余脑容量”的问题（也称为隧道感知或失去情境能力）是你甚至不知道你的能力不足：你是如此专注于手头的问题（这里，使用十六进制RGB数字编程）你没有考虑其他事情，你不知道你没有想到更广泛的问题。
在抽象术语中：我没有考虑RGB数字，通过用户的眼睛的瞳孔和到达在用户的眼睛后面的视网膜，进入用户模型是什么样子。我没有绘制抽象图并检查它们是否相通。更糟糕的是，这是一个简单的编程决策（只有RGB） 它永远不会进入我的思绪中。去思考视觉感知以及只是编程就足够复杂了。
我希望能够更早的用户能看到我的作品，以帮助我思考更多关于设计的内容！

尖端和钝端

the sharp end：the part of an activity, such as a job, where the most problems are likely to be found.
用户在事情发生的“尖端”工作。在人机交互中，我们倾向于关注很多关于尖端的事情，因为这是用户体验发生的地方。它是当然很重要。
例如，在医疗保健领域，照顾和治疗患者的过程处于尖端。如果出现问题，它会在极快的时间内快速被解决。用户得到责备，因为他们按下了按钮，他们造成了问题。
例如，执行任务要求很高，因此用户可以阻止分心，丢失（或至少妥协）环境感知。通常，用户会因为这种人为因素导致的失败而受到指责。还记得有关Air Inter 航线ITF148的事故调查引用了“机组人员工作量饱和”吗？
但是重要的事情也可能发生在钝端。设计师，开发人员和制造商花了数年时间根据已有产品的经验建立设计和构建用户正在使用的系统。设计师有机会小心谨慎地设计并避免用户将会在尖端遇到的许多问题，可以预见的不会受用户关心的事情——像删除键如何工作的细节。
不幸的是设计师有隧道效应，让程序工作起来已经很难了，更不用说让他们运作良好。 计算器似乎工作，我的RGB颜色选择似乎有效（我很快就接受了担心程序中“更有趣”的部分），所以只是我认为它们工作正常。
问题是设计师太容易陷入复杂的任务中比如编程，并且因为编程和设计的要求太高，他们无法退后一步，正确看待抽象感念。他们应该去使用数学，但他们忙于编程。它似乎工作，他们可以继续编程，但它肯定会更好地工作吗？不幸的是，除非他们正在实施的抽象概念是正确的。
提高可用性的传统方法（例如，Landauer，1995，emphasize）是告诉程序员更多关于用户、任务、和最好是人为因素。如果只有程序员才能理解以用户为中心的设计！矛盾的是，这使得问题更严重。程序员让程序跑起来已经很难了，更别说用户需求了。这本身就是人类的基本因素：用户和他们的任务是需要更广泛的考虑的一部分，但程序员因为沉迷代码而失去了对他们的认识。这个问题的标准解决方案是迭代设计（例如，ISO标准9241），但（来自隧道效应的）盲点问题在设计过程中可以通过迭代设计延续下去。
那么，坏消息是程序员必须改进他们的工作方式。 好消息是，产品需要数年时间才能开发出来，如果程序员愿意的话，那就是他们可以编写更好，更简单，更安全的用户界面。我们多学科团队可以通过分担负担帮助他们，帮助他们更有弹性。

走得更远

交互系统的抽象模型似乎很少见，但有几个很有希望并值得追求的领域：
•Smith 和 Koppel（2013）对卫生保健领域出现的设计问题进行了出色的分析。他们指出了患者、临床医生和医疗计算机系统使用的技术之间的“错位”。他们的工作表明，抽象方法可以在有效系统的设计方面提供非常高级的见解。
•Dix，Harrison，Runciman和Thimbleby（1987）开发了PIE模型并将此抽象思想应用输入命令序列及其属性。它可能是 一篇旧论文，但这些想法仍然非常重要。
•Masci，Zhang，Jones，Curzon和Thimbleby（2014）证明了这一点自动验证工具可用于分析人机交互设计，并在事故发生之前发现潜在的设计异常。本章讨论的各种各样的问题都可以自动定义：例如商业医疗设备中发现的问题，在YouTube上观看相关视频。

结论

当制造商和程序员了解正式方法，并且他们被激励，程序就会变得更容易使用或更安全。当错误被归咎于用户，而不是他们使用的系统，注意力将从设计被误导到用户身上。绘制抽象图可能是一种很好的帮助方式更清楚地思考；这些图表更容易讨论，更改和协商，而且它们比完整的正式方法更容易修订。
在20世纪60年代，汽车制造商说“司机发生事故”，这不是他们的错。在Ralph Nader（1965）发表论文Unsafe at Any Speed，尽管不是很快，但文化发生了巨大变还。今天制造商表示司机发生了事故 ，因此他们有责任让汽车更安全。
汽车是关键系统，与程序一样难以安全；不变量公式涵盖各种问题，从防撞区到ABS制动器，打滑轮胎，安全气囊，与复杂的世界互动。在大多数计算机内部通常都只有数字，文本，数据库和一个用户仍在使用办公软件，它应该很容易！
我回到了之前抱怨过的那个网站，它说“意外的错误。”
什么？！他们编写了一个程序来响应这个错误，否则他们就不会检测到这个问题。那怎么会出乎意料呢？他们真正的意思是，“我想 这里有一些问题，我不知道如何编程，但我也是忙于编写程序的其余部分，所以没时间帮助您解决问题。”
本章介绍了思考用户界面设计的框架， 我们使用了一些交互式系统的实例来展示用户之间的关键性 界面设计，以及结果（如飞机和患者安全）如何依赖于可能没有得到应有关注的小型设计决策。 但是我们的分析表明，对交互系统的严格思考非常困难，而且很难做对。也许更重要的一点是迭代设计并且应认真地持续改进（如ISO标准9241中的建议）以及获得用户评估的要求。没有案例，尤其是公司的网站，提供任何方式来接收来自的用户的反馈。因此制造商无法直接从用户体验的问题中学习。这是一个很遗憾。
作为用户，我对错误、意外不感兴趣。我想继续使用我的电脑时，我希望它能够紧密贴合我的心智模型；我是很高兴继续参加培训课程，让我的心智模型更适合计算机，但是当计算机忽视我时，我从不开心，特别是当我想到程序员花费了多年时间的时候，依然在钝端一直无视我和其他用户及其任务。那么，让我们祈祷程序员能更多地思考他们正在构建用户能够依赖的关键系统，因为他们对于抽象事物足够的思考可以确保用户得到想要的安全和正确结果。 人为因素专家可能需要提醒他们，因为他们沉迷于编代码，但是用户的重要工作及尖端对周围每个人的影响更为重要。