分類: UX 體驗設計

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

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

複雜與否，這當中的權衡一直是很有趣的議題。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) 則是我們傾向選擇那些複雜和精細的解決方案，而非直接簡單的解決方案。這通常是因為複雜性會讓人聯想到：智慧、專業知識，或是有著深度的理解。

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

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

閱讀全文 Tesler’s law, 複雜性守恆定律

[大衛選讀] 隨著 Apple Vision Pro 的問世，互動設計打破了平面的界限，走向3D立體空間。對於設計師來說，這意味著必須跳脫二維思維的框架，開始以三維的視角來構思 app 的呈現方式。

Apple 的設計準則 – Human Interface Guidelines，在過往一直是設計師與開發者的重要指南。Apple在過往這上面投注了大量心力，詳細說明了他們的設計哲學、體驗考量和最佳實踐的具體範例。

這些設計原則也一致性地貫穿 iOS、macOS、watchOS 和 tvOS 等平台。現在再加上了 visionOS，增加了很多立體空間、音訊、手勢互動等元素，讓整個設計準則變得立體了起來。

以下簡要摘錄我覺得看了有啟發的點，有興趣的話，請直接參考 Apple Designing for visionOS 設計準則全文：https://developer.apple.com/design/human-interface-guidelines/designing-for-visionos

---

沉浸式體驗的深淺平衡 (Immersive experiences)

新的 visionOS 最重要的設計特點之一，就是沉浸感 (Immersion) 的營造。沈浸感在 visionOS 當中，不是零跟一，而是能在不同的沉浸程度間自如切換；加上穿透顯示 (Passthrough) 的功能，往後要如何透過設計去引導使用者珍貴的注意力，變成 UX 設計師在設計上的一大挑戰。

考慮給使用者更多的控制權，讓他們可以自行選擇何時進入更沉浸的體驗，例如優先考慮在 Shared Space 或 mixed immersion style 下啟動 app。避免一下子栽進另一個世界裡。

謹慎運用沉浸效果，將其保留給最具意義、最能彰顯 app 特色的時刻。並非每個任務都可以受益於沉浸式互動，也不是每個沉浸式的任務都需要完全的沈浸 (fully immersive)。設計上需要謹慎節制，避免過度設計，造成使用者不知所措。

設計體驗之間的平穩、可預測的漸變過渡 (smooth, predictable transitions)。透過溫和平穩的漸變設計，讓人們在視覺上能留意到變化，幫助人們為下一個截然不同的體驗預先做好準備。避免可能令人感到困惑、不舒服、突兀的轉場。

閱讀全文 visionOS 的互動設計原則，有啟發性的重點摘錄

[大衛選讀] 最近跟設計師聊到 AI 技術大幅降低了概念驗證 (proof of concept) 的門檻，大家都覺得能多做前期嘗試跟探索很好；但是再多談下去，總是會有這樣客戶跟老闆能接受嗎，如果失敗很多次會不會怎樣的疑慮。

我想了想，對耶。試做原型的門檻是降低了沒錯，但是如果觀念沒有改過來，那麼溝通的成本還是一樣高，而且做越多反而帶來更大的反效果。

Prototyping is a mindset 這集 podcast，講了一個我覺得很重要的觀念：試做原型是一種思維。生活中的任何事情可以原型化、試做看看，而且重點是保持好奇、擁抱改變，懂得利用原型測試去策略性地儘早學到新東西。

一旦在生活中帶入這樣的思維，所有的事情都只是個原型罷了，那所有的事情隨時都可以調整。都可以進一步學到東西、變得更好。真的會很酷。

很棒的一集專訪，值得花時間聽一次。內容整理如下，原文連結：https://voltagecontrol.com/blog/prototyping-is-a-mindset/

---

Prototyping is a mindset

製作原型 (prototyping) 在建築、產品設計，甚至工程領域裡佔有很大的比重。通常在設計過程中你會試著建造許多原型，不論是否會秀給別人看，直接用於溝通或是說明。

一圖勝千言，而一個原型勝過千張展示圖片 (a prototype is worth like a thousand pictures)。一旦你手邊有一個可以互動的東西，那個與人對話跟反饋的深度就會非常驚人。原型賦予了實際互動的可能性，那是非常有力量的 (incredibly powerful)。

「在真正全力投入製作之前，能先快速模擬一下嗎？」這個概念在日常生活中很有用。先試試看有沒有用，並且從中學到新的方法、發現新的可能性。

這跟閱讀、討論不一樣，透過把東西做出來，所能學到的東西，完全是另外一個檔次。

任何東西都能原型化 (You can prototype anything)

你可以原型化一個過程、一項服務、一次體驗。任何東西都可以原型化。

你也可以在投資大量資本之前，就去原型化你的商業模式。不需要真的建立物流系統，就可以模擬假裝電商網購到貨的體驗，這個是很酷的事情。

不要讓試做原型變得太過麻煩 (reduce the barrier for people to prototype)

越簡單越好，從概略有個樣子去著手就可以。我期望人們能夠舒服自在、有自信地去試做原型。不要把試做原型搞成一個很困難、門檻障礙很高的事情。

原型的重點在於策略性地前導學習 (learning early & strategically)

我認為試做原型是一種方法，讓想法或概念以某種有形的方式活過來的方法 (a way to bring an idea or a concept to life in some type of tangible way)。

它是在試著設想某個東西的未來狀態 (envision the future state)，並且變得可以與他人互動的工具。

然而如果你只是建造某個東西，而從中沒有學到任何事，那你就沒有真正批判性地去做思考。

閱讀全文 Prototyping is a mindset

[大衛選讀] CJM 顧客旅程地圖在UX研究中很常見，很多設計師也喜歡在提案跟作品中展示 CJM，來代表自己對於用戶需求頗有掌握。

在打開滿滿一張 CJM 的那一刻，多半可以感覺到設計師的強烈自豪感，但後續在旅程地圖中卻也常常聽不到什麼有用的脈絡。要是使用了一個好工具，卻不知其所以然，那就真的很可惜。

Customer Journey Mapping Mistakes and How to Avoid Them 這篇文章，詳細說明了為什麼要建立 CJM，以及六個在運用顧客旅程地圖時的常見錯誤。像是一開始沒有設定目標、缺乏研究脈絡、角色發展不全、漏看了頭尾等。是一篇很好的實務經驗分享與觀念提醒。

內容整理如下，原文連結：https://www.uxpin.com/studio/blog/customer-journey-mapping-mistakes/

---

運用顧客旅程地圖時的常見錯誤

顧客旅程地圖，看起來很容易學習運用，但是在實際使用時常有誤解跟陷阱。以下我們將試著把這個工具的實務運用，說清楚講明白。

首先，為什麼要建立顧客旅程地圖？ (Why Creating a Customer Journey Map?)

在討論常見誤解之前，讓我們快速了解一下顧客旅程地圖的核心概念。如果你已經很熟悉，可以跳過這部分。

顧客旅程地圖 (Customer Journey Map, CJM) 是將目標用戶跟產品服務間的互動過程，以視覺化的方式表達出來。你可能會問，這些資訊對業務拓展有什麼幫助？

顧客旅程地圖可以幫助你分析客戶的體驗，識別當中的缺陷和改善機會，以進行後續的策略規劃。

另一個極大的好處是，這個方法有助於吸引你團隊的注意力，並在公司內部發展出共同的認知。像是我們的客戶到底是誰，以及如何接觸到他們。這將會讓團隊更好地合作，提高效率。

然而顧客旅程地圖這類的工具，有它的特性與限制。就像是特定的藥物一樣，必須正確地使用才能達到預期效果。以下則是運用顧客旅程地圖時的常見錯誤：

錯誤 #1：沒有設定目標 (No goals were set)

缺乏經驗的設計師或研究員，通常會單純為了製作而製作CJM；或者希望能透過一張旅程地圖，就能識別出客戶旅程中的所有缺口問題。

但實際狀況是，沒有明確的目標，就不會有任何結果 (no clear goal, no result)，回頭看都只是自我感覺良好的投入而已。在不知道為什麼要建立地圖的情況下，即使研究資料再多，一樣會鬆散沒重點，又能從中發展出什麼用戶體驗的改善策略？

解決方法是，在投入研究之前，先確保團隊能回答以下問題：

・你想分析什麼，為什麼？

・你希望改進哪部分的流程？

・誰對這旅程地圖盤點專案負最終責任？

・這涉及了哪些部門？

・是否有特定的客戶群體需要觀察？

・公司將如何從客戶體驗改善中受益？

你必須先設定一個明確的目標。避免所有 (all) 這個字，因為它意味著什麼都沒有 (nothing)；感覺就像登上了一架到處都會去，但卻沒有具體目的地的一班飛機。

你設定的目標越明確，顧客旅程地圖的計劃就越容易成功。

閱讀全文 運用顧客旅程地圖時的常見錯誤

[大衛選讀] Persona是很常用的研究溝通工具，但也常常是整份報告當中最大的敗筆。一份整理不到位的人物誌，讀起來很容易閃神出戲，導致整份研究報告的可信度大幅下降。

The Problem with Personas 這篇文章，列出了人物誌常見的五個問題，像是不夠深入、太多細節、虛假跟欠缺真實情境等。並且建議了幾個可以替代補充的工具。

實際上，人物誌本身並沒有錯，其他工具也一樣可能會被濫用。我們該重視的不只是交付成果本身，更關鍵的是整個研究過程以及當中的思考脈絡。做了什麼不重要，重要的是，學到了什麼。

重點摘要整理如下，全文連結：https://medium.com/typecode/the-problem-with-personas-b6734a08d37a

---

Personas 人物誌所帶來的問題

幾年前，我和客戶合作進行一個網站設計專案。儘管沒有太多預算可以用於研究，但他們說已經建立好 persona，可以直接取用。我心想太好了！如果客戶已經做了一些研究，並且定義了他們的目標用戶，這將會相對容易些。

不幸的是，我得到的只是一堆隨機事實 (random collection of facts)，以及幾個顯然不存在的假想人物。

之所以會形塑出這些人物的刻板印象，只是客戶覺得，會需要有一些代表性的人物描述，像是：老年人、年輕人、中年職業媽媽等；以及他們的好惡，像是：購物、發訊息、看電視等。哦，可想而知，這些人物剛好都對客戶想要賣給他們的東西，充滿了熱情跟渴望。

這些所謂的人物誌，裡頭充斥了各種我告誡學生千萬別做的錯誤嘗試。

不客氣地說，身為一位設計師，我的責任是設計一個能解決真人問題的產品。而這些虛假的人物誌，對我來說一點用處也沒有。

Personas 人物誌有什麼問題？

首先我想明確地指出，我不認為人物誌在本質上是錯的，只是建立的過程方法往往有問題。

新手要學習一個工具，往往是從模仿範本開始，然後慢慢去掌握工具的特性，並且知道什麼時候該如何使用。最後才能進一步創造新的工具用法，來呼應眼前的需求。這就是學習。

問題在於，很多人試著寫出一份人物誌，就因此感到滿足了。完全不會去質疑，這裡頭的資訊甚至人物誌本身，是否真的有用。

如果不去批判性地思考，到底要呈現什麼資訊，以及如何呈現它，我們很容易在錯的事物上打轉。工具本身是有用的，只是人們使用它的方式有問題。

歸根究柢，人物誌只是一種包裝你所做過研究的方式 (a way to encapsulate all the research that you’ve done)。目的是讓資訊更容易消化、更容易記住，並且期望能觸發後續的設計行動。

合理的設想是，若是透過一個看起來真的人來展現研究成果，這將更容易引發同情心，因此更願意為他去做對應的設計改變。那麼，如果這個虛構的人不夠真實，那麼就不會激發同情心，而是會引起反感，對吧。如果發生了反效果，這又有什麼好驚訝的呢？

此外，即使是站在我們面前的實際人物，也不總是能激發同情心。相信我，我每天都搭乘地鐵；單單針對一位通勤者的平淡描述，如果我們之間沒有什麼特殊的不同之處，這種程度的刺激並不會觸發我的神經。

那麼把人口統計數據放進人物誌裡面，這樣會更豐富可靠嗎？這是一個值得深思的問題。畢竟，一個人物誌是否在Target或Walmart購物真的很重要嗎？這裡頭其實帶有相當程度的假設，讀到這資訊的人會把自己的偏好跟看法，投射到人物誌當中，並且做出個人的判斷評價。在這狀況下，這樣的人物誌很可能會帶來更多壞處，而非優點。

常見的問題是什麼？

為了不要一竿子打翻一船人 (throw out the baby with the bathwater)，我想提供一些方法來改善人物誌。以下是我在創建人物誌時，會儘量避免的事情，也是我經常看到新手會發生的幾個錯誤：

閱讀全文 Personas 人物誌所帶來的問題

[大衛選讀] 你是否在解決正確的問題？ 這是在初次接觸客戶時，我腦袋裡面會想的事情，也是我最常在專案前期詢問自家設計團隊的問題。

Are You Solving the Right Problems? 這篇文章，很清晰地說明了重新框定問題 (reframing) 的概念。真正創新的解決方案，大多來自於對於問題的另一種定義。Reframing 的重點，不在於找到「真正」的問題，而是在於是否有「更好」的問題可以解決。重新去辨識問題的不同面向，有時可以帶來根本性的改進，甚至可以激發出創新破框的解決方案。

文中舉了經典的慢速電梯問題，以及大量的實務案例。同時也把重新框定問題的七種實務技巧，都詳細說明了。內容很長，但是值得反覆閱讀，遇到問題時用來敲敲自己的腦袋。應該會有不錯的效果。

重點摘要整理如下，全文連結：https://hbr.org/2017/01/are-you-solving-the-right-problems

---

Are You Solving the Right Problems?

你是否在解決正確的問題？

大多數公司在辛苦掙扎的並不是如何解決問題，而是找出問題是什麼。

在針對 17 個國家的106位 C-suite 主管的調查中，我發現有整整 85% 的人同意他們的組織在問題診斷方面做得並不好，並且有 87% 的人同意這導致了大量成本。

這個行為模式很明顯：由於傾向立即採取行動，管理者往往在不確認他們是否真正理解問題的情況下，就快速切換到解決方案模式。

企業都知道正確診斷問題的重要性，但一部分受制於完整的問題診斷工具過於複雜跟耗時。像是TRIZ, Six Sigma, Scrum等框架，這些工具很強大，但是在組織內導入需要很長一段時間的培訓。即使人們改用更簡單的問題診斷框架，例如 root cause analysis 以及 5 Whys questioning technique 等，他們經常會發現自己是在已經定義的問題上繼續挖得更深，而不會得到其他角度的診斷與觀點。

深入分析問題很好，但真正創新的解決方案，大多來自於對於問題的另一種定義 (alternative definition of your problem)。

慢速電梯問題 (The Slow Elevator Problem)

想像一下：你是一個辦公大樓的業主，你的承租戶正在抱怨電梯很慢，必須等待很長的時間。

當被問到這問題時，大多數人很快就能找出一些解法建議：像是更換電梯、安裝更強的馬達，或者升級電梯的軟體等。

這些建議都屬於解決方案空間 (solution space)：一系列各式各樣的解決方案，背後都有著共同的問題假設。在這種情境下，關鍵的問題假設就是電梯很慢。

然而，當這個問題傳給大樓管理員時，他們提出了一個更為巧妙的解決方案：就是在電梯旁邊擺上一面鏡子。這個簡單的措施在減少投訴上非常有效，因為人們在有極其吸引人的東西可以看時 (也就是他們自己)，往往會忘記時間。

鏡子的解決方案之所以特別有趣，因為實際上它並不是對原先問題的解決方案：它並未使電梯變快。相反地，它提出了對於問題的不同理解。

要注意的是，一開始的問題分析框架並不一定是錯的，安裝新的電梯確實可能會有效。重新框定 (reframing) 的重點，不在於找到「真正」的問題，而是在於是否有「更好」的問題可以解決。

事實上，認為事物背後肯定有單一的根本問題 (single root problem)，可能是個誤解。實務上，問題通常是有很多因素的，並可以透過多種方式來解決。

例如，電梯問題可以被重新定義成高峰需求的問題。問題是太多的人需要同時使用電梯，那就可能會產生出一個致力於分散需求的解決方案，例如如何有效錯開人們的午餐時間。

重新去辨識問題的不同面向，有時可以帶來根本性的改進，甚至可以激發出創新破框的解決方案。

重新框定問題的七種實務技巧 (Seven Practices for Effective Reframing)

在我的經驗中，重新框定 (reframing) 最好能被視為是一種快速的迭代過程。就像是快速原型製作 (rapid prototyping) 一樣。

我在這裡列出的實務技巧，可以用其中任一種方式，取決於你對情況有多少控制權。

一種方式是將所有七種實務技巧都應用到問題上。這大約可以在 30 分鐘內完成，並且有助於讓每個人熟悉這套方法。

另一種方式，只需選擇其中一兩種當下最適合的實踐方式。在你無法控制情況，並且必須根據手邊可用時間多寡來調整方法時，也許就只有五分鐘也行。五分鐘聽起來連描述一個問題的時間都不夠，更不用說是要重新框定它了。但令人驚訝的是，我發現這種短暫的介入 (short interventions) 往往足以激發新的思考，並從根本上改變你對問題的看法。

太貼近手邊的問題，可能會讓你迷失在細節中，進入無止盡的思考迴圈。這時候你會需要有人跳出來，對你大聲說，這問題難道只能這樣想嗎？

以下是七種重新框定問題的實務技巧：

閱讀全文 你是否在解決正確的問題？