最近整个月我都很崩溃，一直在和某个网银App做斗争。
事情是这样的，我在德国的工资账户是朋友推荐的某家银行。账户顺利开设之后，公司已经可以拨付工资款了，我也在ATM上确认工资已经到账。剩下的问题，就是把网银App设置好，这样就可以随时自助查账、转账、缴费了。
打开官方网页，确认网银App的名字，前往应用市场。下载、打开、输入用户名、密码，却没有直接进入操作界面，而是得到一个提示，大意是：为了保证您的安全，我们需要对您的设备进行签名，生成唯一标识。
看起来，一切合情合理，安全考虑很到位。点“下一步”之后，得到提示是“我们会立刻给您发一封信，包含了唯一标识的激活信息，请收到信件之后按说明操作”。这也没问题，德国还大量使用信件呢，办银行账户我都陆续收了五封信（分别是卡、密码、网银账号、网银ID、数据隐私使用说明）。
过两天收到信件，里面有唯一标识和激活码。再次打开网银App，输入用户名密码，提示相同：为了保证您的安全，我们需要对您的设备进行签名，生成唯一标识。
我心想，这次应该要激活能用了，于是点“下一步”，又傻眼了，“我们会立刻给您发一封信，包含了唯一标识的激活信息，请收到信件之后按说明操作”。
过几天，又收到一封信，是新的唯一标识和激活码。再次打开网银，输入用户名密码，看到提示，点“下一步”，又告诉我要收信……
等再次收到信的时候，我多了个心眼，仔细阅读信里的说明：打开网银App，输入用户名密码之后，会提示需要签名，请按照引导激活…… 这，我还能说什么？
于是上网搜索，在应用市场里，这款App的第一条评价就是：我想这大概是蠢货设计的，我每次输入用户名密码就说给我发信，我拿到信再输入用户名密码又给我发信…… 看来吾道不孤，和我同样遭遇的大有人在。
然后我也进入了这种“死循环”，每次收到信就运行App，输入用户名密码，仔细研究“按照引导”是怎么回事。不过同样成本高昂，因为点错一次就全盘皆输，又要等两三天，收下一封信才能再试。这好像以前玩街机，要不停投币才能继续。
在收了四五次信之后，我接近崩溃。去问朋友才知道，原来收到激活信件之后，可以用电脑浏览器登录，看到待激活选项，输入激活码进行激活。照着做了之后，果然激活成功，看来大功告成了。
再次登录网银App却被一瓢冷水从头浇下——仍然是让我收信，而且再用电脑浏览器登录，发现已经激活的设备标识也失效了。于是，我只能强打精神，继续2-3天为周期的试错法。
试到第十次的时候，我忽然发现，在App上的引导激活过程中，左下角的“返回”按钮之外，还有一个不起眼的选项。诚惶诚恐地点进去，才发现别有洞天，“选择已经激活的设备标识登录”。Bingo，至此全部搞定，时间已经过去了一个月，前后收到的信件堆起来都有厚厚一叠。
回想这段折腾的过程，我“不够小心”当然是原因之一，但是另一方面，产品设计也有很大的问题。网银App一般不会盲目下载，下载的大多数是已经开户的人。从逻辑分析，在设备签名设置的引导页，肯定有超过一半的比例是已经收到激活码的用户。既然如此，为什么不大方提供一个“我已经收到激活码”的选项，而是把它藏在整个流程中某个步骤的角落里呢？哪怕用户本身德语很好，扫一眼就能知道意思，日常习惯也是无意识持续点“下一步”，而不会细看那些选项。
退一万步说，即便可以抱怨用户“不够聪明”，其实真正付出成本的还是银行——看看那十封信就知道成本有多高了。
我不由得想到前段看的一本书的主旨：技术在不断演进，但人的认知、思维、使用习惯却不能飞速演进，不可能也没有必要飞速演进。许多技术产品完全从技术实现的角度考虑，唯独忽视了使用者的感受。所以产品的开发者和使用者，似乎处在完全隔绝的两个世界，由此产生了无穷无尽的沟通成本，甚至是重大事故，比如核事故。
不少人大概听说过“三里岛核电站事故”。1979年3月28日，美国宾夕法尼亚州的三里岛核电站发生了部分堆芯融毁事故，是美国历史上最严重的一次核事故。虽然没有造成明显的人员伤亡，但影响仍然深远，美国因此“冻结”核电站建设超过三十年，到2012年才重启，期间流失了大量的专业人员，大量的经验也因为没有传承而遗失。
事故发生时的三里岛核电站 来源：AP
如今关于三里岛核事故的调查报道已经非常详细。简单说，当天二号机组的冷却系统忽然发生故障，堆芯温度急剧上升。按设计，此时应当启动的备用冷却系统也没有启动，原来两天前维修人员检修时忘记打开备用水泵的隔离阀，所以备用冷却系统也未能启动。
好在核电站的设计经过了充分考虑，保留了足够的安全性。核电站的堆芯紧急冷却系统（RCIC）及时发现了故障，启动紧急应急程序，向堆芯注入冷却水。于是，堆芯温度开始缓慢下降了。看起来，设计时考虑的预案已经生效，这只不过是一场虚惊。
此时，发现异常的工作人员仍然在努力解决问题。他们翻遍了安全手册，希望找出应对方案。据当事人回忆，当时整个控制室乱成一团，各种指示灯如繁星闪烁。大家“按规定”关闭了应急程序，却发现堆芯温度没有继续降低，反而持续上升……
万幸的是，最终事态得到了控制，此时堆芯上部温度已经达到2760摄氏度，而临界值是2871摄氏度，可以说是“惊险万分”了。
为什么系统明明已经开始紧急应对程序，事态开始缓解了，工作人员还要“帮倒忙”呢？
如果要把当时的情况拍成电影，大概会有这样的场景：控制室里大家忙成一团，无数的警报在响起。然后镜头突然拉进到指示灯，下面有文字说明它指示的意义。在千百个闪烁的报警灯之中，这是少数几个没有亮起的——对，问题的关键就在这里。在所有的灾难片中，这种桥段再常见不过了。
不过真实的情况远没有那么简单。事后调查发现，这个PORV（pilot-operated release valve，人工操作泄压阀）指示灯的设计有严重误导性：只要有人开启了泄压阀关闭程序，这个灯就会灭，但是泄压阀到底有没有关闭，却没有对应的指示灯。换句话说，这个灯只能表示意图，不是表示实际的状态。
所以，工作人员看到灯灭了，“以为”泄压阀已经关闭，如果继续注水，反应堆内部压力会超过限制。火上浇油的是，堆芯温度指示仪的读数是“???”，因为此时温度已经超过了设计时预计的正常范围。面对无可解读的读数，工作人员无从知道堆芯的温度还在持续上升，单纯从压力的角度考虑，他们直接关闭了正常运转的堆芯紧急冷却系统……
或许我们可以说，核电站里面是高精尖的设备，需要学习大量的专业知识，需要持证上岗，平时需要反复演练各种预案…… 是的，这些都没有错。但是人总需要面对未知，人总需要依靠自己已有的知识、习惯、经验去解决问题。在设计时，如果一味从设计者自身的理念出发，而不是从使用者的角度出发，考虑使用者的感受和认知习惯，考虑使用者的限制和容易犯的错误，那么，无论使用者花多少心思去学习和训练，或许都不能彻底解决问题。
在设计时，不是单纯从设计理念或者机械原理出发，而是从使用者的感受和行为习惯出发，意味着一种全新的设计思维。如今大家追根溯源，一般都把二战时期轰炸机的改进作为原点。
二战时期，B-17“飞行堡垒”是盟军进行战略轰炸的主力轰炸机，为击败纳粹德国立下了汗马功劳。但是，盟军也发现，许多轰炸机明明历经千辛万苦执行了轰炸任务并顺利返航，却在降落时忘记放下起落架，直接用机腹着地，着实可惜。于是，年轻的心理学家Paul Fitts被派来调查解决这个问题。
B-17“飞行堡垒”轰炸机
没有放下起落架，用机腹直接着地的B-17
一开始，Fitts想的是，看看这些飞行员的精神或者智商到底出了什么问题，怎么会犯下这么低级的错误。如果他们真的不是不小心，那么就应该改进筛选飞行员的程序，把会犯这种错误的人排除在外。
然而，在详细研究了过去22个月的降落事故，也亲身经历过多次飞行之后，Fitts和他的同事Alfonese Chapanis发现，没有任何迹象表明飞行员的精神或者智商有问题，但是有457起降落事故看起来“一模一样”。
正常情况下，飞机在降落时应当放下起落架，同时，因为速度下降，应当放下襟翼以增加升力。然而在B-17的驾驶舱里，襟翼的控制开关和起落架的控制开关紧邻着，而且看起来一模一样。所以，历经千辛万苦完成任务返航，以为马上就可以松一口气的小伙子们，“放心”放下了起落架，然后安然减速、降落。然而他们只是放下了襟翼，起落架还处于收起状态。
B-17的驾驶舱，起落架和襟翼开关在红圈处
红圈处放大，8为起落架控制，9为襟翼控制开关
改进后的B-17驾驶舱，襟翼控制开关的颜色和触感都完全不同
于是Chapanis再没有纠结心理和智商问题，而是“反其道而行之”，他设计了一整套新的系统，不同功能的控制开关从外观上就完全不同，飞行员凭最直观的感觉就能分辨。这样，不但在白天，哪怕是在夜晚，飞行员操作时也不会有任何混淆。这种设计理念被证明是极为有效的，在飞机设计上一直沿用至今。
从我自己的经验出发，我觉得程序开发分为两部分：一部分是自己实现技术功能，这就好像解数学题，一个人花心思总可以解决；另一部分是把功能“包装”给用户，这有点像聊天，需要反复琢磨人的心思。
技术人员往往对前者非常认可，非常感兴趣；而对后者毫无兴趣，认为“都是些无聊的玩意儿”。然而许多时候，恰恰就是那无聊的部分——甚至简单如字体、字号、疏密、颜色、顺序等等设置，决定了用户的体验，决定了用户对程序员工作的评价。
正因为如此，我在阅读最新出版的 USER FRIENDLY: How the Hidden Rules of Design Are Changing the Way We Live, Work, and Play 时感到非常过瘾。作者的观点是，以智能手机为代表的设备已经深入我们的生活，科技对普通人来说已经举足轻重，如果设计时仍然只考虑技术本身，日后必然要花费大量的成本来沟通、协调、培训，也极大影响产品的使用感受。所以，普通人应该读这本书，科技从业者更应该读这本书。
这个观点，我是非常赞成的。在这个问题上，尽管我之前有过一些思考，阅读时仍然为作者的洞见所折服。比如作者开篇就花了不小的篇幅讲解和强调“反馈”：反馈，是我们普通人认识世界的方式。
恰恰因为有反馈，我们才知道自己行为的结果，才能不断调整。如果没有反馈，我们必然陷入巨大的迷惘。自然界充满了反馈，所以我们习惯反馈。所以对人工设计的系统，反馈也应当认真纳入设计当中，而且更应该给出迅速、直接、准确的反馈，这是设计者和开发者的指责所在。
我真的很想把这段话贴出来，送给遇到的每一位程序员。毕竟，运行了就“处于未知状态”，或者有反馈但模糊不清不知所云让人急得跳脚的程序，我见得实在太多了，血泪教训也太多了。
最后，我知道一定会有人问我：这本书哪里有？有没有中文版？
第一个问题如今实在不该问。最简单的，亚马逊就有这本书的电子版（点击“阅读原文”可以直达对应页面），付款之后唾手可得。第二个问题，据我所知已经有国内出版社买了版权（动作真快，这本书11月刚出版），但具体出版计划还不清楚。
不过就像我之前说的， 。如果你真的对这本书的内容有兴趣，不妨就从它开始练习英文阅读吧。
閱讀更多 餘晟以為 的文章
關鍵字: 原汁原味的德系SUV 工业设计 设计
