一个坏的功能和一个好的功能
这里有另一种程序员搞砸用户界面的方法，让他们的用户觉得自己很蠢。在Windows桌面上，选择一个文档，任何文档。然后按Delete键。除非您知道如何禁用该功能，否则您将看到一个类似于图1 - 3，询问是否真的要删除该文件。
来自Windows回收站的无用确认框
你有没有，哪怕只有一次，说:“哇!我不想那样做。谢谢你邀请我。”然后点击“不?”你见过有人这么做吗，或者听说过吗?我没有。具有讽刺意味的是，确认法已被如此广泛地滥用，以至于它已变得完全无用。因为这个盒子一直在“狼来了”，就像伊索寓言中的牧童一样，没有人注意到它，即使它警告你有一个你真的不想删除的文件。你已经看到它太频繁了，以至于它不被注意到。你在自动驾驶仪上浏览它，无意识地点击“是”。它不会给你带来任何安全保障。 None. Fortunately, you can turn off this particular confirmation dialog.6还有很多你无法摆脱的人，他们都不应该存在。在所有。任何地方。永远。
生活中的其他操作不需要确认。当你转动钥匙时，你的车不会问:“你真的想发动引擎吗?”当你把食品杂货放在收银台上时，超市店员不会问:“你真的想买这些东西吗?”想想自从你发现了亚马逊的1-Click订购功能后，你又从那里买了多少书。7
为什么程序员总是要求确认?他们这样做是因为他们认为他们的用户感到困惑，不理解他们刚刚告诉程序做的事情的后果。考虑到用户界面其他部分的糟糕质量，这可能是真的。但确认并不能解决这个问题。如果用户在第一次给出触发确认框的命令时感到困惑，那么当他看到它时就会更加困惑。由于程序似乎不愿意按照他的指令去做，他认为自己犯了某种错误。确认框的使用使程序员不必)清楚地向用户解释他在做什么,所以他不做他不想,和b)提供一种方法来恢复时用户真的做点什么,后来他后悔。
但如果用户真的犯了错误呢?如果你把一个手电筒和一包大小错误的电池放在收银台上，一个细心的店员不会问:“你确定要这些吗?”一个好的用户界面不应该让我们避免这样的错误吗?它当然应该这样做，而计算机程序的美妙之处在于它能够做到。但如果每次都盲目地问:“你确定吗?真的想做你刚才让我做的事吗?”相反，一个好的用户界面可以从一开始就防止问题的发生。也许在销售手电筒的网页上会有一个复选框，上面写着“包括电池”。它会被默认检查，因为手电筒没有电池就不能工作。已经有很多这种尺寸的电池的买家可能会放弃。更妙的是，这种手电筒会被收缩包装，里面已经有电池了，所以当你打开它的时候，它就会工作，没有人会去想它。一个聪明的用户界面设计师在开始编程之前就会想到这一点。如果一个程序员认为他需要一个确认框，我向你保证，他搞砸了用户界面的某些其他部分，这将阻止它的需要。他可能连试都没试过，也可能从没想过要试。确认是懒惰或无知的程序员的拐杖，由每个用户支付。 And it's one that doesn't work.
但你难道不想确认破坏性行为吗，比如删除文件?不,不是真的。没有要求你确认启动汽车或购买食品杂货的另一个原因是，如果你突然意识到自己犯了错误，这些操作很容易，也很便宜。你只要关掉点火器或把不想要的东西还回去就行了。计算机程序可以非常快速、很容易地复制文件和存储器。这允许程序员向用户提供逆转已执行操作的能力。这个撤销功能是用户界面设计者的最佳武器之一。在我看来，这是自鼠标以来用户界面设计的最大进步。
单击确认框中的“是”图1 - 3(或者如果你已经完全关掉了电脑)，Windows实际上并不会清除你电脑上的文件。相反，它会将硬盘移动到另一个叫做回收站的区域，类似于麦金塔电脑上著名的垃圾桶。如果您在此之后改变了主意，想要返回文档，那么只要您没有清空回收站，就可以从回收站检索文档。几乎所有时候你都想移动文件。修复实际发生的相对较少的错误(例如，鼠标滑倒导致您选择了错误的文件进行删除;我昨天就这么做了)，而不是试图通过在每次删除时都添加一个确认框来阻止他们，尤其是后者因为过度使用而无法工作。一盎司的治疗不如五磅的预防。
撤销功能不仅可以用于文件操作，还可以用于应用程序。它通常在“编辑”菜单和它的同伴“重做”(当然，它可以撤消撤消)中找到。我五分钟都写不下去;也许是键入了一个愚蠢的句子，或者把文本移到了错误的地方。实现这个特性的程序员是任何用户最好的朋友。我每次见到他们都给他们买啤酒，你也应该买。为了让这一功能发挥作用，让用户无需考虑它，我们付出了大量的努力(俗话说“容易就是难”);只要按Ctrl-Z键(左手的小指和无名指)，一切就都回来了。一个程序应该只确认它不能撤消的操作。它应该能够撤销一切。
撤销的真正美妙之处在于它允许用户探索程序。从菜单项上的短标签和工具栏按钮上的小图片，往往很难理解一个新程序的操作。但是因为存在撤销操作，用户可以通过尝试不同的东西来进行实验，知道他不会损坏一些用几次按键就无法修复的东西。我可以移动一个段落，看看我是否喜欢它在其他地方，如果我不喜欢，可以快速撤销操作。程序员经常认为用户输入错误是白痴的行为，他们应该坐下来阅读手册。它不是。这是人类学习的主要机制。具有撤销功能的应用程序将变得可探索，而不是令人恐惧。它识别并增强用户的人性。不能正确地执行它是不可饶恕的罪。
如果正确地实现了撤销，整个系统中只有一个破坏性操作，那就是清空回收站。有些人会说，这个操作应该有一个确认对话框，就像它目前所做的那样。但即使在这里，确认对话框的存在也只是为了防止另一个糟糕的设计，将Explore上下文菜单项放在Empty Recycle Bin的旁边。鼠标滑动一次，在上下文菜单上滑下三个而不是两个空格，就会得到后者而不是前者。坏的。由于这是系统中唯一具有破坏性的操作，清空回收站应该有一个不用于其他目的的特殊操作，可能是同时点击它上的两个鼠标按钮(一个操作调用)拨弦的)，或者按住某个键点击它。更好的是，回收站应该自动清空自己，删除文件后，他们已经在它里面的一些可配置的时间，可能从一个月开始，所以你很少需要手动清空它。难道你不希望你家里的垃圾桶也能这样吗?在任何情况下，都不应该在任何地方看到确认对话框。一个程序员已经放弃了自己的职责，不应该从事用户界面业务。
愚蠢地停止程序
程序员设计的用户界面在向用户传递错误消息时绝对是最差的。就在今天，当我在写这一章的时候，我读了CNN.com的主页，并想把它保存到我的磁盘上。我从网页浏览器的菜单中选择了“文件”、“保存”。会出现一个对话框，显示节省操作的进度——5%完成，15%完成，等等，直到99%完成。然后那个盒子不见了，又有一只飞了进来图1 - 4．
非常愚蠢的对话框
这个盒子是一个真正的白痴创造的。为什么这个网页无法保存，我能做些什么来修复它?网页拷贝是否像专业艺术家网站有时尝试的那样受到了保护?服务器不可用吗?如果操作失败，为什么进度条会上升到99% ?它告诉我它保存的那99%的页面呢?这还不如百分之百好，但我宁愿有也比什么都没有好。为什么它消失了?该框显示页面无法保存到选定的位置;这是否意味着它可以被保存到其他位置? If so, where, and how would I know? If not, why is it mentioning location? The browser has already successfully shown me the page, that's why I said to save it; why doesn't it just save the data it's actually showing? The box doesn't tell me how to figure out exactly what the problem is, or where to go for more information. And for a response, it offers only the OK button. No, it is不我认为这个操作没有成功，程序也无法解释原因。甚至“错误保存网页”的标题也是错误的。我没有犯错误。我做了程序允许我做的事。程序犯了一个错误，它不能保存我的页面，然后又犯了另一个错误，因为它不能解释为什么。仅仅用15个词就造成了这么大的混乱，其中两个是的是我见过的最伟大的白痴成就。
我之前提到过的用户界面设计大师艾伦•库珀(Alan Cooper)将这种情况称为“愚蠢地停止进程”，即使他没有使用我拼写的最后一个单词，这也是一个绝妙的说法。如果我真的无法保存页面，我的浏览器应该知道这一点，阻止我尝试，并以某种方式向我解释，最好不要弹出另一个愚蠢的框。也许当我进入那个页面时，保存菜单应该变成灰色，也许应该改为“不能保存-保护”，这样我就能知道是什么以及为什么。如果它不能保存整个页面，它应该保存它能保存的内容，并告诉我它遗漏了什么——同样，不要让我点击另一个愚蠢的对话框。可能保存的页面会在无法保存的区域中包含占位符，当无法找到请求的页面元素时，会在浏览器显示中显示红色的小X图形。
通过调查幕后情况，我能把发生的事情拼凑起来。我将浏览器设置为屏蔽某些恼人的内容。浏览器在屏幕上以空白区域显示它们，我非常喜欢这种空白区域，而不是经常出现在那里的愚蠢的跳舞广告。(我将在另一章讨论跳舞广告的愚蠢。)当程序的保存部分遇到页面的这些部分并发现它们被阻塞时，它不会像程序的显示部分那样忽略它们。相反，它会让他们窒息，放弃整个过程，而不是保留它所能保留的，并以我刚才描述的愚蠢方式停止了进程。
当有人弹出这样一个难以理解的盒子时，谁能不觉得自己像个傻瓜呢?知道这根本不是你的错，而是程序员没有尽到自己的责任。意识到用户不应该理解这样愚蠢的通信。想象你的手扼住程序员的喉咙，你的膝盖像打桩机一样撞到他的胯部。通过遵循本章末尾和本书最后一章的建议。
活体动物试验
程序员永远不会在没有测试内部操作的情况下发布产品(好吧，她不应该)．为什么她认为她可以不测试用户界面，就能发现用户是否真的可以使用它?因为她知道她喜欢它，发现它是可用的，所以其他人怎么可能不这样做呢?正如我们已经看到的，这种无意识的假设几乎总是错误的。用户不知道如何使用的电脑是非常昂贵的镇纸。测试用户界面，调用可用性测试,是困难和昂贵的，但必要的。
她不能只是给用户她的程序，然后问他们是否喜欢它。他们通常不会记得他们所做的,或者他们不想告诉她一个问题他们因为他们觉得愚蠢,不能算出来,或者他们不想侮辱她,告诉她一个完整的堆废话她职业生涯的最后两年的产品了。(你可能已经猜到了，我没有这个问题。)为了找出什么是有效的，程序员必须准确地观察用户在处理用户界面时做了什么。他们首先尝试做什么?他们接下来要去哪里?他们要尝试多少次才能真正弄明白?他们需要多长时间才能注意到这样或那样的特征?
他们必须以一种不影响用户行为的方式观察。这意味着用户必须呆在一个孤立的房间里，只能访问他们在现实生活中可能拥有的任何支持材料(例如，在线文档，或者谷歌)。你必须通过单向玻璃观察他们，录下他们的反应，并使用日志软件，这样你就可以准确地看到他们曾经尝试使用哪些按键和鼠标点击来处理你的应用程序。一些可用性实验室甚至有跟踪耳机，可以报告用户正在看屏幕的哪个部分。
当你这样做的时候，灯泡就亮了。正如艾伦·库珀在他的经典著作中所写，关于面子:用户界面设计的要点(IDG Books, 1995):“(可用性专业人员)把程序员拖进黑暗的房间，在那里他们通过单向镜子看到不幸的用户与他们的软件斗争。起初，程序员怀疑测试对象有脑损伤。最后，经过痛苦的观察，程序员被迫向经验证据低头。他们承认自己的用户界面设计需要改进，并发誓要改进。”
不幸的是，可用性测试经常被搁置到开发过程的后期，也就是产品发布之前。日程总是滑,8所以可用性测试经常被完全忽略。当它确实找到有用的信息时，通常不允许有时间来改变程序。可用性测试需要尽早完成，理想情况下是在进行任何编程之前。
一些公司认为在产品发布前进行大量的测试会产生更有用的产品。例如，微软会做它称之为“dog-fooding”的事情，这是“吃我们自己的狗食”的缩写。就在公司向公众发布产品之前，它会让公司内部的真实用户看到它——例如，把秘书们切换到下一个版本的Word for Windows。这确实捕获了一些错误，我指的是程序员的逻辑错误，他们忘记携带两个或其他东西，导致程序崩溃。但是对于发现设计错误来说已经太晚了，尤其是在可用性领域。在把你自己的狗粮发布给用户之前，吃它会让你的狗粮尝起来比不吃它的好一点。但它不会把它变成猫粮，狗粮阶段已经太晚了，不能发现你的用户真的是猫或长颈鹿。
这是一个正确的例子。我曾经在一家保险公司做顾问，这家公司正在编写一个Windows程序，以取代一些昂贵的IBM终端。对于一家保险公司来说，这是很不寻常的，他们实际上做了我刚刚告诉你们的可用性测试。他们也做得很好，用录像带和程序员通过单向玻璃观看。他们发现用户基本上喜欢这个应用程序，觉得它可用。但用户习惯按Enter键从一个输入字段移动到下一个输入字段，就像他们的IBM终端那样，而不是像Windows应用程序那样按Tab键。他们问道，难道开发商就不能改变这一点吗?在仔细考虑之后，开发人员决定，尽管它在技术上很容易，但它不会让用户高兴，尽管用户认为它会。当然，他们可以让这个应用程序以旧的方式工作。但是所有新的商业Windows应用程序都不会以这种方式运行，用户很快就会患上精神分裂症，每天来回切换很多次。 So the developers convinced the users to bite the bullet and make the change. And after the requisite period of squawking, the users calmed down and swallowed it, helped by the abysmal job market in the area at that time. My point is not that programmers should cram down users' throats the features they think would be good for them. You usually can't get away with that; this was a special case. I'm relating the story to show you how a client of mine did a good job of usability testing. They did the testing they needed to do. They found what there was to find. And then they made the right decision based on what they found. I wish more companies would do that.
我们在哪里，你能做什么
我们这些可怜的用户该怎么办呢?总结一下我的观点:
你不愚蠢的。用户界面确实很糟糕，这是不应该的。
它们很糟糕，因为它们是由程序员设计的，他们没有意识到他们的用户和他们自己不一样。
因为第2点，他们的界面故意变得复杂，他们希望你喜欢处理这个，而你不喜欢(参见第1点)。
在每个软件项目的一开始就有可用性专家参与，用户界面会变得更好。在这方面，一般的程序员比无用的还要糟糕。必须有人为沉默的大多数用户说话，他们不关心技术本身，他们只是想完成他们的工作，这样他们就可以回到他们的生活中。我试着在我参加的每一次设计评审中扮演这个角色。“你们就像那些在家得宝(Home Depot)卖的钻头的设计人员，”我告诉程序员们。“你们在这里，争论这个或那个钻头的内部细节，滚珠轴承、滚子轴承和空气轴承，你们每个人都声称这是你的客户在世界上最想要的东西。错了。客户并不在乎你的钻头，一点也不。从来没有，将来也不会。他去家得宝不是因为他想要钻头。 He goes to Home Depot because he wants holes. If he could just buy a box of holes to put on his wall, without having to touch a drill, he'd be much happier. (Remember Ringo in the movie黄色潜水艇吗?“我的口袋有个洞……”)在你的用户寻找洞的过程中，你的钻头是一个必要的恶魔。现在问问你自己，并诚实地回答:“你的用户真正想要什么样的漏洞，你的程序如何以更少的钱为他提供更好、更快的漏洞?”
既然您已经完成了这一章，那么您就和其他人一样有资格告诉软件供应商您喜欢什么，不喜欢什么。程序的用户界面结构并不是西奈山上的戒律。它是由程序员和其他开发人员的设计决策创建的，他们也可以很容易地做出其他的设计决策。给他们发电子邮件，多发些。告诉他们你喜欢什么，不喜欢什么。告诉他们把确认功能从你的脸上去掉，提供更好的撤销功能。
在这个世界上，程序员最讨厌看起来愚蠢。丑陋，阳痿，对孩子和小动物不友好，他们不在乎，但是哑巴?愿上帝怜悯我们。在他们的自我评价中，智力远远高于一切。如果你需要让程序员做一些事情，确保他不做的话会在公众面前显得很愚蠢。
所以，下次当你看到一个设计糟糕的用户界面时，停下来看看它。玩一会儿;明确地找出你不喜欢它的原因，以及什么会让你更快乐。在“耻辱大厅”网站上发布一个关于这个糟糕设计的通知。这本书的网站，http://www.whysoftwaresucks.com这将是一个很好的开始。然后给应用公司发电子邮件，向他们展示你的公共邮箱exposé。你发现他们越蠢，他们就越讨厌公开这件事。然后他们可能会,可能最终让他们明白他们的用户并不是他们自己。