Tesler’s law, 複雜性守恆定律

[大衛選讀] 設計師會不會想太複雜了，有必要在系統上做到這樣複雜的判斷跟處理嗎？在產品規劃時，這是很常出現的來回思辨跟角力。

我的經驗是：表面上看起來簡單，其實裡頭通常並不簡單。一開始想簡單了，最後很可能用起來就會複雜到爆炸。

複雜與否，這當中的權衡一直是很有趣的議題。Tesler’s law 複雜性守恆定律，正是這樣的洞見，有助於我們理解整體的複雜性，並且更好地思考該如何應對。

這個定律簡單講，就是根本的複雜性是不可能消滅的。要麼這個複雜性在規劃階段由設計跟開發來承擔，要麼就是丟給使用者來自己面對。

但仔細去思考，就會發現人性偏好在未知懵懂的狀況下，去選擇複雜的解法以求得安心；過度的簡單，可能會造成體驗的反效果；以及如何利用建立概念模型、漸進式揭示等設計技巧，去有效承載消化不必要的複雜性。

本文選讀彙整了多篇文章。內容整理如下，原文連結則放在留言中。

---

在應用程式或流程中，誰應該承擔起這樣的複雜性？是使用者，還是設計師和開發人員？這是在做介面設計，以及更廣泛地考慮人類如何與技術互動時，必須面對的一個基本問題。

體驗設計師的其中一個關鍵目標是，為人們降低複雜性，讓產品和服務能夠變得更簡單易用。

但是每個流程都有一些固有的複雜性。不可避免地，當複雜性無法進一步降低時，只能將它其從一個地方，轉移到另一個地方。在這個時候，複雜性要麼進入使用者界面中，要麼進入設計師和開發人員的工作流程中。

▎The origins of Tesler’s law

複雜性守恆定律 (Tesler’s Law, Law of conservation of complexity) 的起源可以追溯到 1980 年代中期，當時全錄 PARC 的計算機科學家 Larry Tesler 正在協助開發全新的互動設計語言。這是一套定義互動系統結構的原則與標準，對桌上型電腦和排版技術的發展至關重要。後來又到了蘋果電腦，協助開發 Mac 物件導向的軟體框架。

Tesler 意識到，介面的一致性不僅會讓使用者受益，也能夠讓開發人員受益，因為共通的標準可以內建在共享的軟體庫中。很快速有效地導入，並且發揮綜效。

Tesler 將複雜性守恆定律，定義為一種向公司管理層以及獨立軟體供應商，推銷這個想法的說服方法，希望能在大眾市場軟體中建立標準，以減少終端客戶面臨的複雜性。

Tesler 認為：「工程師應該多花一週時間，來試圖降低使用端的複雜性，而不是讓數百萬的用戶因為這不必要的複雜性，而每天得多花一分鐘。這樣做是讓工程師輕鬆了，但是反過來懲罰了使用者。」

▎Complexity bias leads to more complex solutions 人們天生偏好看起來複雜精細的解法，結果往往導致更複雜的解決方案

人類有相當多的認知偏差，它是一種心理捷徑，讓我們能夠快速做出決定而不需徹底分析情況，進而提高了我們的效率。

複雜性偏差 (complexity bias) 則是我們傾向選擇那些複雜和精細的解決方案，而非直接簡單的解決方案。這通常是因為複雜性會讓人聯想到：智慧、專業知識，或是有著深度的理解。

簡單來說，我們經常過分讚許那些聽起來複雜的概念，或者當我們感到困惑或沒有花時間真正理解時，會將原本很容易理解的事物，視為是相對複雜和困難。

當我們選擇更複雜的解決方案時，我們就逃避了真正理解關鍵問題的必要性。但結果往往是，解決方案中的複雜性和假設越多，失敗的可能性就越大。

▎以日常生活中的電子郵件為例

要說明複雜性守恆定律，最簡單有效的範例是再常見不過的電子郵件。

當你撰寫一封電子郵件時，有兩個必需的資訊：來自誰，以及應該發送給誰。如果缺少其中任何一個資訊，電子郵件就無法發送，這就是必要的複雜性 (necessary complexity)。

為了減少這種複雜性，現代的電子郵件工具會做兩件事：預先在發件人欄位填上你的電子郵件地址，並在你開始輸入收件人地址時，根據之前的電子郵件記錄和聯繫人清單來提供輸入建議。

在這個例子裡，複雜性並沒有完全消失；它只是被抽象化 (the complexity isn’t entirely gone; it’s just abstracted away)，以減少使用者的負擔。

換句話說，透過將填寫發件人和收件人地址的複雜性，轉移到了電子郵件工具端，讓寫電子郵件的體驗變得更簡單了。設計師與工程師的努力，讓幾十億人省下了寶貴的時間。

▎Simpler isn’t always better 然而，更簡單並不代表一定會更好

複雜性守恆定律下的第一個經驗教訓是，一個東西看起來簡單，並不代表它使用起來真的很簡單 (how simple something looks is not a reflection of how simple it is to use)。

人們有一種直覺，認為複雜性是省不掉的，必定會存在於某個地方。所以如果使用的產品或服務太過簡單時，用戶可能會感到懷疑，這搞不好是假的，或覺得被剝奪了控制權。

實際上，複雜的行為，就會需要複雜的工具。與其試圖簡化工具，像是刪除或是隱藏功能，我們真正需要的是一個更好的概念模型 (conceptual modal)；去包容整合這些複雜的功能，讓整體的用戶體驗，感覺起來更為簡單。

例如在電腦上，你可以將文件拖拉到文件夾中。文件和文件夾以跟現實世界類同的圖示出現。對用戶來說，這個過程很簡單，因為它借用了人們已經理解的東西，提供了一個清晰的概念模型。

這個過程之所以看起來簡單，只是因為這是個有效的概念模型。它並不代表電腦上實際發生的情況，那裡並不存在真正的文件和文件夾，即使是同一批資料也可能分散儲存在多個不同的磁區。

反過來，移除功能也並不會使事物變得更簡單。簡單的工具，在簡化流程上的能力是有限的。如果硬是用簡單的工具去做複雜的事情，結果反而會弄得更為麻煩。

體驗設計大師 Don Norman 就曾說到：某件事是否複雜，取決於觀察者的心理 (Whether something is complicated is in the mind of the beholder)。

以A380飛機的座艙介面為例，專業的飛行員看到的是一系列不同的工具，每一個都很簡單。他們知道何時該使用每一個特定的工具，來使整個飛行操作過程更容易。專業人士經驗豐富的概念模型，能幫助他們駕馭各種專業工具。

▎Simplicity is being devoid of unnecessary complexity 所謂的簡單，就是沒有不必要的複雜

掌握真正的簡單，就是知道什麼是剛剛好 (just enough)。也就是當你知道，你正在為用戶提供剛好足夠的功能來完成任務，而不會妨礙到他們的那個時刻。

這可以透過多種方式來實現，比如漸進式揭示，隱藏不必要的東西，直到它們需要時才顯示。但在走這條路時必須注意，不要影響到產品的品質。

你必須正確劃分預設主要功能，和進階次要功能。你必須在前面就顯示使用者經常需要的所有內容，這樣他們只有在極少數情況下才需要進入次要進階的選單。

透過任務分析和實地研究，可以讓你洞察人們真正需要什麼。如果你正在改進現有系統，過往的點擊數據分析可以幫助你確定功能的優先順序。

要特別留意的是，有時候追求簡單 (Simple)，卻做過頭變成了最小 (minimal)，導致了功能不足的缺陷。要是對用戶來說沒有產生足夠的價值，造成用戶體驗上的問題，那就是簡單過頭了。

系統的整體複雜性是不變的，重點是要適當地分配跟緩解，避免在用戶端留下不必要的複雜。