字與字節
字與字節

誠切的救贖者,以無用之物朝奉。每周四篇關於科技、未來、藝術、商業的精選長文。

Don Norman 冰箱的啟示

唐·諾曼(Don Norman)的冰箱


唐·諾曼(因在《設計心理學》(The Design of Everyday Thing)中推廣了“直觀功能(affordance)”而聞名)講述了壹個關於他的舊冰箱溫度控制的故事:


我曾經有壹臺普通的兩格冰箱,沒有什麽特別之處,問題是我不能正確地設置溫度。冰箱只有兩個東西可以控制:調節冷凍層的溫度和調節冷藏層的溫度。這裏有兩個控制鈕,壹個標記著“冷凍”,壹個標記著“冷藏”。問題是什麽呢?這兩個控制鈕不是獨立的,冷凍層控制器也影響到冷藏層的問題,反過來,冷藏層控制器也影響到冷凍層的溫度。


從人類角度,對於冰箱會有的壹個自然想法是:冰箱有兩層,我們會想要獨立控制這兩層的溫度。然而,冰箱顯然不是這樣工作的。為什麽不是呢?諾曼說道:


事實上,只有壹個恒溫器和壹個制冷機,壹個控制器調節溫度,另壹個控制器調節送入冰箱兩層隔間的冷空氣的比例。


不難想象為什麽這對於比較便宜的冰箱是壹個好的設計:它只需要壹個制冷機和壹個恒溫器。節省了重復零件的成本,但代價是造成了用戶的困惑。在這個情況下的根本問題是機器的結構(壹個恒溫器和對冷卻效能的分配)和人類想要的結構發生了錯位。為了使冰箱的行為和人類想要的行為相匹配,在某種程度上,需要有人去在這兩個結構之間進行轉換。在諾曼提到的冰箱的例子裏,這個轉換很糟糕,導致大家很困惑。


我們把用於結構之間進行轉換的方法或工具稱作“接口”。因此,創造好的轉換方法或工具就是接口設計。


接口(界面)設計


在編程中,類似的問題是 API 設計:將壹個軟件內部使用的數據結構,以壹種有用的,好理解的方式呈現給外部的程序員。如果系統的內部數據結構和用戶想要的結構不匹配的話,那就要由 API 設計者來進行轉換。壹個“好的 ”API 可以很好地進行轉換。


用戶界面(接口)設計是壹個相同問題的更普遍的情況,把壹個工具使用的內部結構,想辦法以壹種有用的,好理解的方式呈現給外部用戶。理論上。與 API 設計的唯壹區別是,我們不再假設用戶是通過代碼與工具進行交互的編程者。我們設計界面去滿足人們的各種使用場景,可能是門上的把手,或者移動應用上的按鈕,或者是冰箱上的溫度旋鈕。


從經濟上來說,界面設計是壹個必要的輸入方式,讓各種事物變得更經濟更有用。這種輸入方式有多稀缺?人們願意為壹個好的界面或接口花多少錢呢?


我的印象是:很多。有壹整類的科技公司的商業模式是:


- 找到壹個很有用的軟件工具或數據庫,但是界面做得很差;


- 為它建立壹個更好的界面;


- 通過這種模式來獲利。


這在小型但有盈利的軟件公司中是壹個非常常見的模式。這種模式是壹個小的團隊可以構建壹個工具,來擁有壹小部分高付費高忠誠度的用戶。這是壹個很有性價比的商業模式,妳找到那些在用“A”工具的人,但發現它很難用,然後妳就可以對他們說“看,我們提供的工具讓 A 好用很多。”比如:


- 為政府系統提供接口的公司:提供稅務服務、旅遊簽證、專利或商業許可。


- 為沒有相關專業知識的小企業以網站形式提供接口的公司:建立網站,Salesforce,企業架構、人力資源服務或航運物流。


- 為數據提供圖形界面(接口)的公司,例如網站流量監測、銷售渠道、政府合同或市場基本面信息。


我們可以在科技領域之外找到更大的例子,人類自身就是壹個接口,整個行業由作為接口的人組成。


這怎麽理解呢?整個稅務、法律合同、遊說的行業。原則上說這些事情妳可以自己完成,但這個系統是復雜和令人困惑的,所以有壹個專家在妳周圍把妳想要的東西轉換成系統結構是有幫助的。


在某種意義上,整個軟件工程領域就是壹個例子。軟件工程師的主要工作就是去把人類想要的東西轉換為電腦可以理解的語言。人們使用軟件工程師是因為相比對著 Juptyer(壹個 Python 編程語言的編輯器)中的壹個空文件來說,跟軟件工程師交談是壹個更容易的接口(雖然也很難)。


這些都不是廉價的行業。律師、會計、說客、程序員,這些人都是復雜系統方面的專家,他們得到相應的報酬。世界花費了大量使用人作為接口的資源,這表明這種接口是壹種非常稀缺的資源。


為什麽這麽困難


諾曼的作品中充滿了很多有趣的例子,以及用來把工具內部結構準確地傳遞給用戶的普適性的技巧,壹個經典的例子就是,在門上,把手即代表“拉”,平面即代表“推”。從這壹點上,我想人們會對這些技巧有壹個很好的理解,而且它們正在逐漸傳播開來。但是只有這個系統的內部結構本身非常簡單時,比如壹扇門或壹臺冰箱,精準地傳遞系統的內部結構才是有用的。假如我想寫壹份合同,那麽我需要去和合同法的系統進行對接,想要準確地傳遞這種結構,甚至只是總結關鍵部分,那是需要讀完整整壹本書的。


對於很多非常簡單的系統而言,界面(接口)設計所關註的主要問題就是準確地傳遞內容,這包括大部分日常的物品(比如冰箱),以及大多數的網站和移動應用。


但是,有些地方我們會看到比較昂貴的負責提供接口的行業,比如法律行業或軟件行業,這些行業通常底層系統更復雜。在這些情況下,人類想要的東西的結構與系統的結構差異非常大,兩者之間的轉換需要大量學習和實踐。僅僅準確地傳遞系統內部的結構是不足以讓問題簡單化的。


換句話說,對於復雜系統的接口是特別稀缺的,在很多不同的領域,人們特別需要這種接口。我們會看到壹整個的大型行業主要的目標就是去給非專業的人們提供對應到壹個特定的復雜系統的接口。


考慮到對應到復雜系統的接口通常是壹種稀缺資源,我們還可以想到其它什麽呢?由於對應到復雜系統的接口是艱難和昂貴的,我們還能想到什麽是艱難和昂貴的呢?


AR vs VR


按照軟件工程的標準,現實世界中幾乎任何事情都是復雜的。對接現實世界意味著我們不必去進行對象化(本體論),我們可以創建壹堆的對象類型和數據結構,但現實世界不會認為有義務去遵循它們。計算機或編程語言很少能和現實世界的結構完美契合。


所以把現實世界對接到計算機中,是壹個我們認為比較艱難也會比較昂貴的領域。


AR (增強現實 augmented reality)是壹個我預期可以強烈感受到這個現象的領域,尤其與 VR(虛擬現實 virtual reality)相比。我認為 AR 應用在接受度和產品質量方面將大大落後於完善的 VR。我認為 AR 將主要應用於穩定的可以控制的環境裏,比如工廠的地板或逃生風格的遊戲。


為什麽軟件與現實世界的對接很難?這裏有些標準的答案:


- 現實世界本身就是復雜的。這是壹個逃避性的答案,實際上什麽都解釋不了。


- 現實世界有很多邊緣案例。這也是壹種逃避,但更隱晦。如果我們程序的對象化(本體論)與現實不壹致,現實世界似乎只會充滿邊緣案例。真正的問題是,為什麽我們的對象化(本體論)很難與現實保持壹致?


這裏是壹些更有趣的答案:


- 現實世界不是用 Python 實現的。在某種程度上,現實世界只有壹種語言,那就是數學。隨著軟件更多地要與現實世界對接,它將需要更多的數學知識,就如我們在數據科學領域看到的,而並不是所有數學知識都可以輕松地變成黑盒隱藏在 API 之後。


- 即使有著無處不在傳感器,現實世界也只是部分可以觀察到的,我們不能像使用數據庫那樣隨時隨地查詢任何東西。對於我們不能直接觀測到的事情進行建模會越來越重要,這意味著要更多地依賴於概率和機器學習工具。


- 我們需要足夠的計算機來運行所有的數學部分。在實踐中,我認為這個條件不像它壹開始看起來那麽難。只不過,我們仍需要高效的算法。


- 我們感興趣的現實世界是抽象的、高層次的對象。在這壹點上,我們甚至沒有數學工具來處理這些種模糊的抽象。


- 我們不能直接控制現實世界。虛擬世界可以以滿足我們的各種假設為基礎來建造,而現實世界不能。


- 結合以上幾點,對於這種表達現實世界的模型我們並沒有什麽好的方法,也很難描述我們在現實世界中想要什麽。


- 軟件工程師大多不善於描述他們想要的東西,也不善於構建與現實世界相壹致的對象化(本體論)。 這些都是很難培養的技能,幾乎沒有程序員可以明確意識到他們需要培養這些技能。


組織中的接口


準確地傳達我們想要的東西是很困難的。程序員和產品設計師尤其熟悉這壹點:


說話的動機有時候是個問題(顯然人們不會信任廣告和銷售人員說的話),但即便是最真誠的溝通者(客戶、項目經理、設計師、工程師等)也很難解釋清楚事情。壹般來說,人們不理解哪些方面是與其他人相關的,甚至不知道哪些方面是與自己最相關的。設計師會向程序員解釋與設計最相關的部分,而程序員會關註與編程最相關的部分。


不僅僅是人類想要的東西的結構與現實世界的結構不匹配。人類中的專家看待世界的結構在不同專家之間也大有不同。當兩個不同領域的專家需要去傳遞彼此想要什麽的時候,某人/某物就要進行結構的轉換工作,換句話說,我們需要壹個接口。


幾年前有過壹個很深刻的例子:我無意中聽聞了壹個設計師和壹個工程師在討論網頁上的壹點小改動。事情是這樣的:


設計師:“我想讓它和之前壹樣,但把這個放在頂部。”

工程師:“像這樣?”

設計師:“不,我不希望其它東西移下來。讓所有東西都在原位,然後把這個放在最上面。”

工程師:“但把它放在最上面會讓其它東西都拉下去。”

設計師:“它不壹定,看,只是……”


這種情況持續了大約 30 分鐘,雙方都越來越沮喪。


事實證明,設計師的工具是從頁面底部開始構建所有內容,但工程師的工具則是從上到下構建所有內容。 所以從設計師的角度來看,“把這個放在頂部”並不需要移動任何東西。 但是從工程師的角度來看,“把這個放在頂部”意味著其他的東西都要被拉下來。


需要有人/工具來完成轉換的工作。這是壹個雙方面的接口問題。


對於管理者或決定組織結構的人來說,解決這種類型的問題是壹個核心的職能。讓壹個項目經理參與到設計師和工程師的每壹次對話聽起來是比較蠢的,但如果項目經理完成了雙方的轉換,那麽這麽做就是有用的。上面的例子不是壹個好現象,但至少雙方都意識到了他們沒有成功地進行溝通。最糟糕的事,如果雙方都產生了以為自己都說清楚了的幻覺(double illusion of transparency),最後可能都沒有人能意識到這個問題。


這就是為什麽在大型組織中,那些能夠跨部門協作的人價值千金。 接口是壹種稀缺資源。跨部門協作的人員可以充當人工接口,在組織之間轉換模型結構。


1986 年的《戈德華特-尼科爾斯法案》就是壹個很好的例子。 它旨在解決美國軍方各部門之間缺乏溝通、協調的問題。 基本想法很簡單: 任何人都不能晉升為中尉或更高級別的官員,除非首先完成壹項”聯合任務” ,在這項任務中,他們會直接與其他部門的成員壹起工作。 能夠在分支機構之間充當接口的人員是壹種稀缺資源,戈德華特-尼科爾斯引入了壹種激勵機制來創造更多這樣的人員。 在該法案提出之前,各部門的高級指揮官都反對該法案,他們認為這是國會的幹預。 但是在第壹次伊拉克戰爭之後,所有人都證明說這是美國軍隊有史以來最棒的事情。


文 | johnswentworth


來源 | LESSWRONG


原文鏈接


字與字節。

誠切的救贖者,以無用之物朝奉,冷靜旁觀所謂進步,徘徊於未來的當口,詢問“真的就是這裏嗎?”。

每周四篇關於科技、未來、藝術、商業的精選長文。

CC BY-NC-ND 2.0 版权声明

喜欢我的文章吗?
别忘了给点支持与赞赏,让我知道创作的路上有你陪伴。

加载中…

发布评论