设计体贴的软件

        纳斯和里夫斯认为，软件应该是礼貌的，但是我们更喜欢用“体贴的”这个词来形容。尽
管礼貌可以解释为一种礼节，如“请”、“谢谢”等，但其他有用的方面我们做得还不够，真正
的体贴意味着心里始终想着他人的需求。体贴的软件最关心的是用户的目标和需求，其次才是
其基本功能。
        如果软件缺乏信息，过程模糊，迫使用户到处寻找常用的功能，还因为软件自己的问题责
备用户，那么这种软件就是低效的，用户体验不到愉快。即便软件多么有礼貌，多么有代表性，
视觉隐喻多么好，内容多么充实或者多么拟人化，也是如此。
        此外，如果交互是谦让的、大方的，对人有所帮助，那么就会对用户产生长期的正面影响。
 

设计原则
        软件应该像人一样体贴。

        通常，具有交互性质的产品惹怒我们的不是它们缺少哪些功能，而是不体贴。其实，做一
个体贴的产品不比做一个粗陋的产品难多少，你只需要想象一个关心他人的人士是如何与别人
打交道的，效仿他就可以了。这些体贴的特征没有一个是和功能至上的数据处理的目标相违背
的，这些数据处理都是针对含有电子芯片的产品来说的。事实上，产品表现得越有人情味，就
越符合实用这个目的。如果这些富有人情味的特征适当地组织在一起，那么与用户间的对话便
利于有效地使用软件的功能。
        人有许多特征，让自己变得体贴。人们或多或少地也将这些特征赋予了具有交互性质的产
品，以下列举了一些体贴的交互性质的软件产品/(和人)所具有的特点。

• 体贴的软件关心用户喜好。
• 体贴的软件是恭顺的。
• 体贴的软件是乐于助人的。
• 体贴的软件具有常识。
• 体贴的软件有判断力。
• 体贴的软件预见需求。
• 体贴的软件是尽责的。
• 体贴的软件不会因为自己的问题增加你的负担。
• 体贴的软件会及时通知我们。
• 体贴的软件是敏锐的。
• 体贴的软件是自信的。
• 体贴的软件不问过多的问题。
• 体贴的软件即使失败也不失风度。
• 体贴的软件知道什么时候调整规则。
• 体贴的软件承担责任。
• 体贴的软件能够帮助你避免犯低级错误。

        顺便说一下，以上特点与更加实用的功能数据处理过程(这是所有数字产品设计的核心)
的目标一致，没有任何矛盾的地方。接下来我们将对以上特点进行详细阐述。
 

体贴的产品关心用户喜好

        体贴的朋友希望加深对你的了解。他记得你的喜好，知道如何使你开心。每个人都希望得
到个性化的体贴和照顾。
        然而另一方面，大多数软件不知道也不关心自己的用户是谁。尽管我们一直在反复使用个
人计算机中的软件，但它们好像也不记得关于我们个人的一些信息。举一个优秀的软件行为的
例子，火狐或者微软上网浏览器能够记住用户定期登录网站的相关信息，比如用户名和收件地
址。谷歌浏览器甚至能记住不同设备和会话的小细节。
        软件应该努力记住我们的小习惯，尤其是我们告诉过它的事。对于编写程序的开发人员来
说，从用户那里收集信息和从数据库里收集信息一样，是理所当然的。所以当程序需要信息时，
就让用户提供。用完了之后，程序就将这些信息扔掉。等下次再需要时，就再询问用户。程序
本来就比人更适合记忆信息，然而到头来，它却忘了这些信息，这就太不体贴用户了。记住用
户的行为和偏好，是最好的方法了，它能对用户使用软件产生积极作用。我们将在这一章的后
半部分详细讨论软件记忆这个问题。
 

体贴的软件是恭顺的

        一个好的服务员是客户至上的，她明白正在接受服务的人就是老板。当餐馆服务员将我们
带到一张桌子面前时，我们会认为他选择的座位只是一种建议，而不是命令。在人少的餐馆，
 我们如果礼貌地要求换另一个座位时，我们希望服务员接受我们的要求。如果餐馆服务员拒绝
了我们的要求，我们可能就会选择另一家更尊重我们意愿的餐馆。
        不体贴的软件监督并随意判断人的行动，当然软件可以认为我们犯了错。但是它随意判断
或者限制我们的行为，就显得太不体贴了。在我们输入自己的电话号码之前，软件可以建议我
们暂时不要提交，并解释原因。但如果我们坚持没有号码时也要提交，那么希望软件能够按照
我们的意愿做。“提交”这个词和它所代表的含义，有悖于软件应该扮演的恭顺角色。软件应该
向用户提交，任何提供“提交”按钮的程序都是不礼貌的，是有歧义、让人困惑的。
 

体贴的软件是乐于助人的

        如果向商店服务员询问在哪里可以找到某件商品，我们希望他不仅能回答我们的问题，还能主动向我们提供一些其他有用的信息,比如花差不多的价钱可以买到某种性价比更高的商品。
        多数软件不会尝试提供其他相关信息;相反，它只是狭隘地回答我们问它的问题。即使是与我们的目标明确相关的其他信息，它也不愿提供。当我们告诉文字处理器打印一份文档时，它不会告诉我们打印纸不够了，也不会告诉我们前面有40份文档在排队等待打印，或附近另一台打印机空闲，而一个乐于助人的人会告诉我们这些信息。
        给用户提供有用的信息，需要一个合适的途径，微软的剪贴小助手(Clippy)一直以来因为其自以为是的帮助而受到普遍的歧视。比如“你似乎正在打印一封信，需要帮助吗?”虽然我们很赞赏这种热心帮助的好意，但我们不需要其帮助时，希望它不要那么鲁莽，能够领会我们的暗示。毕竟一个好的服务员不会打断客人讲话而去询问是否需要加水，而是当杯子空了以后，就会给你倒上。他总是可以对你的暗示心领神会，而不是通过询问得到答案。
 

体贴的软件具有常识
        在不合适的地方提供不合适的功能是交互产品设计失败的一大标志。多数交互产品将经常使用的控件和从不使用的控件放在一起，你很容易发现菜单中，简单、无害功能与不可撤销的类似“弹射座椅控制杆”等专业级的功能紧邻在一起，这就像坐在打开的烤肉炉边上的感觉一样。
        一些可怕而让人恼怒的事是计算机系统反复地给用户发送金额为0的支票，或数字为957,142,039.58美元的账单。我们认为此类事情发生，尤其是频繁发生时，系统应该提醒收账或
付账部门人员，但大多数信息系统很少能有这种常识。

体贴的软件有判断力
        一般来说，我们希望软件能够记住我们的操作和指令。但也有一些信息，比如密码、纳税
人号码、银行账号和密码等，我们不希望在没有接受用户指令的情况下自动记录。相反，我们
希望软件能够帮助我们保护此类个人隐私数据，比如选择安全的密码，及时报告不当的操作，
类似于账户正在陌生电脑或地址上登录。
 

体贴的软件预见需求
        当你前往一个陌生城市旅行，你的助手能够在你没有提出任何要求时，主动帮你预定你所
需要和喜欢的旅馆，说明她能够预见你的需求。

        当我们仔细浏览网页时，网络浏览器浪费大量的时间闲置着，什么也不做。其实它可以在      我们阅读时，轻松预测我们的需求并做好准备，也可以利用这些闲散的时间提前下载所有可见
的链接。当我们要求浏览器检测一个或多个链接，它能够立即进入相应界面。要知道关闭一个
不想要的请求很容易，但等待请求加载却很浪费时间。我们将在后半部分进一步讨论如何利用
软件的空闲时间为我们办事。
 

体贴的软件是尽责的

        一个尽责的人会从长远的角度来认识所执行任务的意义。例如，一个尽责的人会擦干净柜
台，倒空垃圾，而不只是洗刷盘子，因为那些事情与清洁厨房这个更大的目标有关。一个尽责
的人在起草报告时，还会在报告上加一个漂亮的封面，并为整个部门影印足够的份数。
        举个例子，假设我们有一个助手叫罗德尼，我们让他把一个名为马尼拉的文件夹整理好。
他检查了文件夹标签上的名字，比如说微晶石公司合同，然后在文件库里寻找。在M条目下，
让他吃惊的是其中也含有一个同样的微晶石合同标签的马尼拉文件夹。罗德尼注意到它们之间
的差别并进行研究。他发现先前的文件夹包含一份关于17个机械小部件的合同，这些机械小部
件4个月前已经交付到微晶石公司;另一方面，新文件夹是有关下个季度生产和交付32个齿轮
部件的合同。有责任心的罗德尼将老的文件夹改名为2013年7月份微晶石小部件合同，然后将
新文件夹改名为2013年11月份微晶石齿轮合同。这种主动做事的态度让我们觉得罗德尼很有
责任心。
        假设我们之前有个助手叫艾略特，他完全是个傻瓜，一点都不负责任。如果他遇到相同的
情况，就会不假思索地将新的微晶石合同文件堆到旧的微晶石合同旁边。诚然，他也完成了任
务，但他原本可以做得更好，让我们将来查找该文件更方便。这也是我们为什么不想让艾略特当助手的原因。
        如果我们依靠文字处理软件草拟一份新的齿轮合同，然后想把它保存在微晶石目录下。程
序提供的选择是要么毁掉原先的小部件合同重新拟定新合同，要么就根本不能保存。程序不仅
没有罗德尼能干，甚至还不如艾略特，他比傻瓜还愚蠢。软件如此笨拙，以至于仅仅因为文件
的名字相同，就认为我们要把旧的文件扔掉。
        最起码，程序应该将两个文件标上不同的日期，然后保存。即使程序拒绝单方面采取这种
极端的行为，它至少应该在保存新文件之前，向我们显示旧文件，请我们重新命名该文件。程
序完全可以采取更多负责任的行为。
 

体贴的软件不会因为自己的问题增加你的负担
        在服务台前，人们总是希望服务员能够充分照顾自己的关注点，而不是她滔滔不绝地介绍她所关心的问题。也许这对他们来说有失公平，但这就是服务业的规则。交互产品也应该对自己的问题保持沉默，关注用户的需求。由于电脑没有自我意识或者敏感脆弱的情感，它们更应该胜任这种角色，然而事实正好相反。
        交互产品总是用错误信息提示向我们抱怨，用确认对话框打断我们，用一些不必要的通知向我们炫耀(文档保存成功!软件先生，你太好了，你有过保存失败的时候吗)。我们对程序是否有信心清空垃圾箱不感兴趣，我们不想听到软件抱怨不知道将文件保存到磁盘哪个位置。我们也不需要看到电脑的数据传输率和它的加载顺序，就像我们不需要知道客服代表不愉快的情感经历一样。软件不仅要对自己的事情保持沉默，还应该更聪明、自信并自主地解决自己的问题。 
 

体贴的软件会及时通知我们
        虽然我们不希望交互产品因为小小的恐惧和成功不断纠缠我们，但我们却真心希望它能够
及时通知我们所关心的事情。我们不希望酒吧招待向我们抱怨他最近离婚了，但我们会感谢他
能在明显的地方标明酒类价格，在黑板上写明何时举行赛前晚会、谁将出场，以及当前的活动。
获得这些信息时，没有人打断我们。无论何时，这些信息都在那里。同样，软件可以为我们提
供大量运行状态的非模态反馈，这点我们将在第15章中谈到。
 

体贴的软件是敏锐的
  现在大多数软件都不怎么敏锐，它们对多数问题的理解是狭隘的。它也许愿意执行艰难的任务，但这只是在正确的时间接收到准确的指令时才会这么做。比如，如果你请库存查询系统
告诉你有多少小部件，它会忠实地查询数据库，并报告你截至目前库存的数量。但是，如果20
分钟后，达拉斯分公司的人将库存的所有小部件都清走了，情况又会如何呢?当你的电脑傻在
那里，运算着10亿次无用指令时，你的操作就有可能引起大麻烦，它完全没有意识到这些问题。
当你查询过一次小部件的数量，难道这不意味着你很有可能会再次查询这一信息吗?虽然你不
希望以后每一天都收到小部件库存情况的报告，但很有可能在查询后的一星期内你是希望看到
这些信息的。敏锐的软件能够察觉用户的操作，并利用这些观察为用户提供相关的信息。
        软件也应该观察我们的偏好，并且主动记录下来。如果我们总是将一个程序的屏幕设置为
最大化，程序在几次之后就应该将这一模式设定为默认设置。对于调色板、默认工具、经常使
用的模板设置和其他有用的设置也应该如此。
 

体贴的软件是自信的
        交互产品应该坚定自己的信念，如果我们命令电脑删除一个文件，它不应该问“确定删除
该文件吗?”我们当然确定，否则也不会提出这一请求，他不应该怀疑我们或自己。
        另一方面，如果计算机怀疑我们可能出错(这也是常事)，它应该做好准备恢复已删除的文件。
        多少次，你点击完打印键后去喝杯咖啡，等你回来时却发现一个可怕的对话框在屏幕中央
抖动:“你确定要打印吗?”这种不安全感简直令人抓狂，它完全违背了体贴这一原则。

体贴的软件不问过多的问题
        不体贴的软件总是问许多烦人的问题。过多的选择很快就让它丧失了优势，反而成了一种
痛苦的经历。
        问问题与提供选择完全是两码事。当你一个人在商店里逛时，你会有很多选择。当你参加
工作面试时，面试官会询问你很多问题。这两个体验哪个更舒服呢?部分原因在于我们都明白
提问题的人所处的位置要比被提问的人更优越，有权威的人提问，级别或职位稍低的人回答问
题。当软件提问而不是提供选择时，用户会产生类似的胁迫感。
        除了权力导致的这种结果，问题也会让人感觉受到烦扰和侵犯。你喜欢汤还是沙拉?沙拉。
你喜欢卷心菜还是菠菜?菠菜。你喜欢法式、千岛还是意式沙拉酱?法式。你想要清淡点还是
正常放盐量?够了，还是请你给我来一份汤吧!你想要玉米浓汤还是鸡肉面汤?
        用户不喜欢产品问问题，尤其是一些愚蠢或不必要的问题。产品问问题会让用户觉得产品:

•         无知。
•         健忘。
•         软弱。
•         烦躁不安。
•         缺少主动性。
•         要求过多。

        这些正是我们在人际交往中讨厌的毛病，又怎么会希望产品有这些特点呢?交互产品的应用程序不是像朋友在餐桌边上聊天一样，用好奇或者想聊天的方式询问问题，而是表现得很无知，同时还夹带着不该有的权威感问问题。它对我们的想法不感兴趣，只是需要得到一种信息，而通常这些信息压根儿就没必要询问我们。
        许多自动取款机一直询问用户选择哪种语言:“西班牙语、英语还是中文?”用户第一次做出选择后，以后使用时也不可能再改变答案。问题少的交互产品，不会询问问题而是会提供选择，并且能够记住用户的信息;这样的产品对用户来说更聪明，也更礼貌和贴心。

贴的软件即使失败也不失风度
        当你的朋友很没礼貌时，他会试图弥补，尽可能挽回损失。当程序发现一个致命问题时，
它可以充分利用时间，努力弥补过失而不让用户受到损害，或者简单点让系统直接崩溃。
        许多应用程序包含大量的数据和设置，一旦崩溃，信息就丢失了，而用户只能自认倒霉。
比如说，程序运行良好，正从服务器下载电子邮件，此时内部子程序内存已满。和多数桌面软
件一样，程序发出一个有效消息:“你的程序完全瘫痪了”，在单击确定按钮后程序会立即结束。
当你重新启动程序，或者重启电脑时，却发现电子邮件内容丢失了。当你向服务器查询时，又
发现它已经删除了你的邮件，因为邮件已经移交给了程序，这不是我们所希望的好软件应该出
现的情况。
        在电子邮件的例子中，程序接收到服务器的电子邮件后立即删除了邮件副本，却没有确保电子邮件会自动记录下来。如果邮件程序先确保那些邮件写进了本地磁盘，然后通知服务器已经成功下载那些邮件，就不会出现这种问题。
        有些优秀的设计软件，可以利用撤销缓冲从崩溃中恢复，比如专业音乐制作软件Ableton
Live。这是一个产品轻松追踪用户行为的极佳例子，这样即使有些情况下出了问题，还是可以
轻松地从困境中解脱。
        即使程序没有崩溃，不体贴的行为也是很常见的。尤其是在网上，这种问题更加明显。用
 户经常需要在网页的一系列表单中输入详细信息。在填完10个或11个字段之后，用户可能单
击提交按钮，但由于这部分输入有错误或者遗失，站点拒绝其输入并提示纠正。于是用户单击
返回箭头回到页面，发现那些正确的输入连同那些无效的输入一起都被删除了。还记得那个不
可理喻的可恶的初中地理老师吗?他把你那篇南美洲的报告全部撕成碎片然后扔掉，只因为你
是用铅笔而不是钢笔写的。直到今天，你还因此讨厌地理吧。不要创造类似的产品!

体贴的软件知道什么时候调整规则
        在人工信息处理系统被转化为计算机系统的过程中，一些东西丢失了。尽管一个自动订单输入系统可以处理上百万次的订单，比人类员工能处理的要多得多;但人类能够以某种多数自动系统忽略的方式工作，而在自动系统中几乎没有利用这种功能。
        在人工系统中，当销售部的员工告诉职员加速处理某个订单意味着更多生意的时候，他就可以迅速处理那个订单;当另一个订单缺失一些关键信息时，他也可以继续处理并记得随后要补充和记录这些信息:这种灵活性是自动系统所缺乏的。
        多数计算机系统只有两种状态，即不存在或者全部一致，无法识别或接受任何中间状态。
在任何手工系统中，有一个重要但矛盾的状态一一尽管没有被说出，也没有记载，但又非常可
靠，即暂停状态。这一状态中，尽管交易没有全部处理完毕也能被接受。操作员在头脑中、书
桌上或者口袋里创建了这种状态。
        举个例子，数字系统在保存发票之前需要客户和订单信息，而员工则可以在得到客户的详细信息之前直接提前登记订单;即计算机系统会拒绝这笔交易，因为没有详细的客户信息就不允许开发票。
        在人工操作系统中，人们会打破操作顺序，或在满足先决条件之前就执行操作，这称为“规避能力”(fudgeability)。这是计算机系统的缺失之一，这种缺失是数字系统缺乏人性的一个关键因素，这是实现模型的自然结果。开发人员没有看到任何创建中间状态的理由，因为计算机不需要，但人类对于轻微调整系统却有着强烈需求。

        可规避系统的一个好处是减少错误。通过允许小的临时错误进入系统并授权人们可以在造
成严重问题之前纠正它们，从而避免更大以及更永久性的错误。矛盾的是，大多数计算机加强
硬性规则正是为了防止类似错误的出现。这些死板的规则将软件和人类对立起来。因为人类拒
绝采取规避措施来防止更大的错误，因此很快就对软件的保护措施失去兴趣，也就无法避免真
正的大问题。当死板的规则强加在灵活的人类身上时，两面皆输。从商业上说，阻止人们做他
们想做的事总是不好的，而计算机系统也不得不经常消化无效的数据。
 
        在现实世界中，缺失的信息和没有适当填充到标准字段的额外信息都是成功的重要工具。
如果截止日期比计划期限延长两星期，某个交易才能完成，多数公司宁愿延长计划期限，也不
愿看到一个上百万美元的交易化为泡影。在现实世界中，限制总是可以调整的，体贴的软件需
要意识到并且包容这类事实。

体贴的软件承担责任
        大多数软件面临问题时，会采取这种态度:“这不是我的责任。”当工作任务暂时告一段落，转交某些硬件设备继续工作时，它顿时当起了甩手掌柜，任由愚蠢的硬件来完成任务。任何用户都可以看出这样的软件不体贴，不负责任，这种软件没有分担责任来帮助用户变得更加高效。例如，在一个典型的打印操作中，程序开始发送20页报告给打印机，同时打开带有取消按钮的打印过程对话框。如果用户很快意识到自己忘了一个重要的改动，他在打印机刚打出第1页时单击取消按钮，程序立即撤销打印操作。但是用户不知道的是，当打印机开始打印第1页时，计算机已经把15页报告交给了打印机缓存。程序取消的是最后5页，但是打印机对取消操作一无所知。它只知道要完成交给了它的15页任务，于是继续打印。同时，程序还自鸣得意地告诉用户打印已经取消。用户可以清楚地看到程序在说谎。
        用户对程序与打印机之间的通信问题没有多少理解。他不关心通信是否是单向，只知道在打印机输出栏中出现第1页纸之前已经决定不打印文档。他单击了“取消”按钮，然而愚蠢的程序仍然继续打印了15页。
        想象一下，如果程序可以和打印驱动器通信，打印驱动器也可以和打印机通信，用户的体验会怎样呢?如果程序足够聪明，打印工作就可以在第2页纸浪费之前轻松地取消掉。打印机当然也有取消功能，只是软件在设计时偷懒没有设计这一功能。
 

体贴的软件能够帮助你避免犯低级错误

        当你要做一些肯定会后悔的事情时，比如在一群陌生人面前大声咆哮你的个人私事，或者
要把一个空信封交给领导的时候，一位乐于助人的同伴会默不作声地把你叫到一旁，委婉地指
出你的错误。
        数字产品也应该在类似情况发生时这样帮助你。比如，当你想将信息发送给某个朋友，而
不小心发送给全部朋友时，或者要给部门领导发送电子邮件时，忘了把邮件中提及的季度报告
附进去的时候，数字产品应该像人类伙伴一样及时给予提醒。
        然而这种提醒不应该以标准的错误信息对话框的形式阻止动作的发生，这只会在伤口上撒 
盐。恰当的方式是通过细致的视觉和文字反馈，提醒你正在将信息发送给全部朋友而不是单个
人，或者尽管你在邮件中提到要添加相关附件，却忘了这么做。
        在后一种情况中，你的电子邮件应用程序甚至可以毫无模式地标出缺失区域，提醒你添加
附件，同时给你选择是否继续发送无附件的邮件，防止软件误解了你的意图。       

         产品能够更进一步帮助用户避免令其尴尬的错误，并不因此责备用户，这样产品会快速赢
得用户的信赖和忠诚。体贴的产品设计是区别一般产品和伟大设计的标志之一，也许是唯一的
标志。