最近整個月我都很崩潰，一直在和某個網銀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 工業設計 設計
