An image to describe post 从我与网银app的一个月搏斗说起

2019,北海道

最近整个月我都很崩溃,一直在和某个网银App做斗争。

事情是这样的,我在德国的工资账户是朋友推荐的某家银行。账户顺利开设之后,公司已经可以拨付工资款了,我也在ATM上确认工资已经到账。剩下的问题,就是把网银App设置好,这样就可以随时自助查账、转账、缴费了。

打开官方网页,确认网银App的名字,前往应用市场。下载、打开、输入用户名、密码,却没有直接进入操作界面,而是得到一个提示,大意是:为了保证您的安全,我们需要对您的设备进行签名,生成唯一标识。

看起来,一切合情合理,安全考虑很到位。点“下一步”之后,得到提示是“我们会立刻给您发一封信,包含了唯一标识的激活信息,请收到信件之后按说明操作”。这也没问题,德国还大量使用信件呢,办银行账户我都陆续收了五封信(分别是卡、密码、网银账号、网银ID、数据隐私使用说明)。

过两天收到信件,里面有唯一标识和激活码。再次打开网银App,输入用户名密码,提示相同:为了保证您的安全,我们需要对您的设备进行签名,生成唯一标识。

我心想,这次应该要激活能用了,于是点“下一步”,又傻眼了,“我们会立刻给您发一封信,包含了唯一标识的激活信息,请收到信件之后按说明操作”。

过几天,又收到一封信,是新的唯一标识和激活码。再次打开网银,输入用户名密码,看到提示,点“下一步”,又告诉我要收信……

等再次收到信的时候,我多了个心眼,仔细阅读信里的说明:打开网银App,输入用户名密码之后,会提示需要签名,请按照引导激活…… 这,我还能说什么?

于是上网搜索,在应用市场里,这款App的第一条评价就是:我想这大概是蠢货设计的,我每次输入用户名密码就说给我发信,我拿到信再输入用户名密码又给我发信…… 看来吾道不孤,和我同样遭遇的大有人在。

然后我也进入了这种“死循环”,每次收到信就运行App,输入用户名密码,仔细研究“按照引导”是怎么回事。不过同样成本高昂,因为点错一次就全盘皆输,又要等两三天,收下一封信才能再试。这好像以前玩街机,要不停投币才能继续。

在收了四五次信之后,我接近崩溃。去问朋友才知道,原来收到激活信件之后,可以用电脑浏览器登录,看到待激活选项,输入激活码进行激活。照着做了之后,果然激活成功,看来大功告成了。

再次登录网银App却被一瓢冷水从头浇下——仍然是让我收信,而且再用电脑浏览器登录,发现已经激活的设备标识也失效了。没办法,我只能强打精神,继续2-3天为周期的试错法。

试到第十次的时候我忽然发现,在App上的引导激活过程中,左下角的“返回”按钮之外,还有一个不起眼的选项。诚惶诚恐地点进去,才发现别有洞天,竟然是“选择已经激活的设备标识登录”。Bingo!至此全部搞定,时间已经过去了一个月,前后收到的信件堆起来都有厚厚一叠。

回想这段折腾的过程,我“不够小心”当然是原因之一,但是另一方面,产品设计也有很大的问题。网银App一般不会盲目下载,下载的大多数是已经开户的人。从逻辑分析,在设备签名设置的引导页,肯定有超过一半的比例是已经收到激活码的用户。既然如此,为什么不提供一个醒目的“我已经收到激活码”的选项,而是把它藏在整个流程中某个步骤的角落里呢?哪怕用户本身德语很好,扫一眼就不会错过任何信息,但是,绝大多数人的日常习惯都是无意识持续点“下一步”,不会细看那些选项。

退一万步说,即便可以抱怨用户“不够聪明”,其实真正付出成本的还是银行——看看那十封信就知道成本有多高了。

我不由得想到前段看的一本书的主旨:技术在不断演进,但人的认知、思维、使用习惯却不能飞速演进,不可能也没有必要飞速演进。许多技术产品完全从技术实现的角度考虑,唯独忽视了使用者的感受。于是,产品的开发者和使用者似乎处在完全隔绝的两个世界,由此诞生了无穷无尽的沟通成本,小的如那十封信,大的可能是核电站事故。

不少人大概听说过“三里岛核电站事故”,这也是人类历史上第一次核电站事故。1979年3月28日,美国宾夕法尼亚州的三里岛核电站发生了部分堆芯融毁事故,是美国历史上最严重的一次核事故。虽然没有造成明显的人员伤亡,但影响仍然深远,美国因此“冻结”核电站建设超过三十年,到2012年才重启,期间流失了大量的专业人员,大量的经验也因为没有传承而遗失。

An image to describe post 从我与网银app的一个月搏斗说起

事故发生后的三里岛核电站 来源:AP

如今关于三里岛核事故的调查报道已经非常详细。简单说,当天二号机组的冷却系统忽然发生故障,堆芯温度急剧上升。按设计,此时应当启动的备用冷却系统也没有启动,原来两天前维修人员检修时忘记打开备用水泵的隔离阀,所以备用冷却系统也未能启动。

好在核电站的设计经过了充分考虑,保留了足够的安全性。核电站的堆芯紧急冷却系统(RCIC)及时发现了故障,启动紧急应急程序,向堆芯注入冷却水。于是,堆芯温度开始缓慢下降了。看起来,设计时考虑的预案已经生效,这只不过是一场虚惊。

此时,发现异常的工作人员仍然在努力解决问题。他们翻遍了安全手册,希望找出应对方案。据当事人回忆,当时整个控制室乱成一团,各种指示灯如繁星闪烁。大家“按规定”关闭了应急程序,却发现堆芯温度没有继续降低,反而持续上升……

万幸的是,最终事态得到了控制,此时堆芯上部温度已经达到2760摄氏度,而临界值是2871摄氏度,可以说是“惊险万分”了。

为什么系统明明已经开始紧急应对程序,事态开始缓解了,工作人员还要“帮倒忙”呢?

如果要把当时的情况拍成电影,大概会有这样的场景:控制室里大家忙成一团,无数的警报在响起。然后镜头突然聚焦在某个指示灯,下面有文字说明它指示的意义。在千百个闪烁的报警灯之中,这是少数几个没有亮起的之一——对,问题的关键就在这里。在灾难片和科幻片中,这种桥段再常见不过了。

不过真实的情况远没有那么简单。事后调查发现,这个PORV(pilot-operated release valve,人工操作泄压阀)指示灯的设计有严重误导性:只要有人开启了泄压阀关闭程序,这个灯就会灭,但是泄压阀到底有没有关闭,却没有对应的指示灯。换句话说,这个灯只能表示意图,不是表示实际的状态。

这就是许多报道中说的“误读”——工作人员看到指示灯灭了,想当然反应堆顶部的泄压阀已经关闭,此时如果继续注水,反应堆内部压力会超过限制,后果不堪设想。火上浇油的是,堆芯温度指示仪的读数不是数字,而是“???”,因为此时温度已经超过了设计时预计的正常范围。面对无可解读的读数,工作人员无从知道堆芯的温度还在持续上升,单纯从压力的角度考虑,他们直接关闭了正常运转的堆芯紧急冷却系统……

我们能指责工作人员的“误读”吗?或许可以,但它一定不是关键因素,因为这种设计方案,不可能有人不“误读”——我们当然可以说,核电站里面是高精尖的设备,需要学习大量的专业知识,需要持证上岗,平时需要反复演练各种预案…… 是的,这些都没有错。但是人总需要面对未知,人总需要依靠自己已有的知识、习惯、经验去解决问题。如果设计本身有违常识,有违认知习惯,那么被误读应当是家常便饭。

无论什么系统,在设计时如果一味从设计者自身的理念、从技术本身出发,而忽略了从使用者的角度出发,忽略了使用者的感受和认知习惯,忽略了使用者的限制和容易犯的错误,那么,无论使用者花多少心思去学习和训练,或许都不能彻底解决问题。

在设计时,不是单纯从设计理念或者机械原理出发,而是从使用者的感受和行为习惯出发,意味着一种全新的设计思维。如今大家追根溯源,一般都把二战时期轰炸机的这种设计思维的诞生点。

二战时期,B-17“飞行堡垒”是盟军进行战略轰炸的主力轰炸机,为击败纳粹德国立下了汗马功劳。但是,盟军也发现,许多轰炸机明明历经千辛万苦执行了轰炸任务并顺利返航,却在降落时忘记放下起落架,直接用机腹着地,着实可惜。于是,年轻的心理学家Paul Fitts被派来调查解决这个问题。

An image to describe post 从我与网银app的一个月搏斗说起

B-17“飞行堡垒”轰炸机

An image to describe post 从我与网银app的一个月搏斗说起

没有放下起落架,用机腹直接着地的B-17

一开始,Fitts想的是,看看这些飞行员的精神或者智商到底出了什么问题,怎么会犯下这么低级的错误。如果他们真的不是不小心,那么就应该改进筛选飞行员的程序,把会犯这种错误的人排除在外。

然而,在详细研究了过去22个月的降落事故,也亲身经历过多次飞行之后,Fitts和他的同事Alfonese Chapanis发现,没有任何迹象表明事故飞行员的精神或者智商有问题,然而,确实有457起降落事故看起来“一模一样”。

正常情况下,飞机在降落时应当放下起落架,同时因为速度下降,应当放下襟翼以增加升力。然而在B-17的驾驶舱里,襟翼的控制开关和起落架的控制开关紧邻着,而且看起来毫无差别。所以,历经千辛万苦完成任务返航,以为马上就可以松一口气的小伙子们,“放心”放下了起落架,接着安然减速、降落。然而他们只是放下了襟翼,起落架还处于收起状态。

An image to describe post 从我与网银app的一个月搏斗说起

B-17的驾驶舱,起落架和襟翼开关在红圈处

An image to describe post 从我与网银app的一个月搏斗说起

红圈处放大,8为起落架控制,9为襟翼控制开关

于是Chapanis再没有纠结心理和智商问题,而是“反其道而行之”,他设计了一整套新的系统,不同的控制开关从触感和外观都完全不同,飞行员凭不需要动脑筋就能分辨。这样,不但在白天,哪怕是在夜晚,操作时也不会有任何混淆。

An image to describe post 从我与网银app的一个月搏斗说起

改进后的B-17驾驶舱仪表盘局部,襟翼控制开关的颜色和触感都完全不同

实践证明,这种办法是相当有效的,所以一直沿用到战后,沿用到各种飞机上。如果你走进现代飞机的驾驶舱,会发现起落架控制开关和襟翼控制开关截然不同,不需要说明书也可以一眼看出来。

An image to describe post 从我与网银app的一个月搏斗说起

现代飞机上的起落架开关大多长这样,就像个轮子,无论看还是摸,都不会错

An image to describe post 从我与网银app的一个月搏斗说起

现代飞机上的襟翼控制开关,也很形象

从我自己的经验出发,我觉得程序开发分为两部分:一部分是自己实现技术功能,这就好像解数学题,一个人花心思总可以解决;另一部分是把功能“包装”给用户,这有点像聊天,需要反复琢磨人的心思。

技术人员往往对前者非常认可,非常感兴趣;而对后者毫无兴趣,认为“都是些无聊的玩意儿”。然而许多时候,恰恰就是那无聊的部分——甚至简单如字体、字号、疏密、颜色、顺序等等设置,决定了用户的体验,决定了用户对程序员工作的评价。

正因为如此,我在阅读最新出版的 USER FRIENDLY: How the Hidden Rules of Design Are Changing the Way We Live, Work, and Play 时感到非常过瘾,过瘾的来源也不限于上面两个故事。

User Friendly作者的观点是,以智能手机为代表的设备已经深入我们的生活,科技对普通人来说已经举足轻重,如果设计时仍然只考虑技术本身,日后必然要花费大量的成本来沟通、协调、培训,也极大影响产品的使用感受。所以,普通人应该读这本书,科技行业的人更应该读这本书。

An image to describe post 从我与网银app的一个月搏斗说起

这个观点,我是非常赞成的。关于这个问题,尽管我之前有过一些思考,阅读时仍然为作者的洞见所折服。比如作者开篇就花了不小的篇幅讲解和强调“反馈”:反馈,是我们普通人认识世界、与世界打交道中必不可少的元素。哪怕是简单在纸上画一条直线,我们也离不开反馈:一但看到画歪了,大脑就要立刻调整手的动作。

恰恰因为有反馈,我们才知道自己行为的结果,才能不断调整。如果没有反馈,我们必然陷入巨大的迷惘。平时,自然界充满了反馈,所以我们习惯接受反馈。然而对人工设计的系统来说,反馈并不是天然就有,而是需要人工设计和实现的,因此它往往被忽略。然而从用户的角度出发,也恰恰是这种反馈,当然应当认真纳入设计当中,而且应该更迅速、更直接、更准确,这是设计者和开发者的职责所在。

我真的很想把这段话贴出来,送给遇到的每一位程序员。毕竟,运行了就“处于毫无反馈未知状态”,或者有点反馈但模糊不清,关键时候让人急得跳脚的程序,我实在见得太多了,血泪教训也太多了。

我已经无数次在团队里强调:写程序一定要考虑意外情况,一定要给出准确的、其他人看得懂的运行和报错信息,但是效果往往并不好。所以我在想,如果大家多看看这类书,或许会有启发?

最后,我知道一定会有人问我:这本书哪里有?有没有中文版?

第一个问题如今实在不该问。最简单的,亚马逊就有这本书的电子版(点击“阅读原文”可以直达对应页面),付款之后唾手可得。第二个问题,据我所知已经有国内出版社买了版权(动作真快,这本书11月刚出版),但具体出版计划还不清楚。

不过就像我之前说的,《 多看点英文报道吧,这是我的良心建议》。如果你真的对这本书的内容有兴趣,不妨就从它开始练习英文阅读吧。

An image to describe post 从我与网银app的一个月搏斗说起

如果您认为本文有意思,欢迎长按识别上面的二维码订阅。

“余晟以为”虽是个人号,但只用心做原创,不虚张声势,不故弄玄虚,不带节奏,力求定期更新,只为和你一同探索世界,分享致中平和的观点。