分類: UX 體驗設計

[大衛選讀] 為什麼要有設計限制？這些限制綁住了設計師的手腳，限制了創新的可能性？

常常我們在做設計專案時，會聽到這樣的爭論跟抱怨。但實際上，設計限制 (design constraints) 是設計過程中必要的線索，甚至可以用來當做創新的起點。

沒有限制的設計，做到最後會很虛假；什麼都做了，但是什麼都不到位。而有明確嚴格限制的設計，一旦在那個限制下，創造出美好的新事物，那麼就會是其他人模仿不來的。因為競爭者沒有這種限制 (我更傾向叫做特性, qualities)，所以看不懂也學不來。

Design Constraints Are Not Restraints – They Stoke Creativity 這邊文章，很清楚地說明，設計師會遇到的各種限制，並且解釋了為什麼這不會是束縛，反過頭來，設計師更應該要去擁抱限制。

重點摘要整理如下，全文連結：https://www.toptal.com/designers/ui/design-constraints

---

設計限制不會是束縛，反而能激發創意

設計限制是一種線索 (clues)。有助於設計師在每個專案中對焦，在待解問題、所得資源，跟驗收條件之間，找到合適的交集。避免在無關緊要的設計想法上，浪費寶貴的時間。

每一次的設計嘗試，無論是看一次就要留下深刻印象的行銷廣告，或是用幾千萬次都一樣簡單好上手的軟體服務，在設計過程中都會有需要考慮的限制條件。

這些考慮因素叫做設計限制 (design constraints)。雖然它們看起來可能會削弱原創性，但這些限制其實是關鍵。有明確的限制，才能打造出長期可靠的設計解決方案。

Design constraints 是設計上的一種侷限，沒錯，任何專案都會有其限制。一個顯而易見的例子是預算。錢可以提供人力、工具，甚至在某種程度上爭取到寶貴的時間。但錢不是無限的，其他資源也是一樣。

如果看得不夠開闊透徹，眼前的限制就像是一種剝奪。這些限制讓我們取得不到真正想要的資源，會因此掐死創意。想起來就超級負面，是吧。

但換個角度看，限制其實是促進巧思的工具。因為資源不是無窮無盡的，而設計的驗收條件又必須設法達到，所以限制迫使我們必須更有系統地分析目標用戶及其需求問題。Design constraints 進一步促使設計師對他們使用的設計流程，和所能付出的精力，做策略性的思考與安排。

設計限制並非束縛 (Design Constraints Aren’t Restraints)

在藝術創作的實務經驗中，你會發現，限制解決了看著空白畫布無法下筆的問題。無窮無盡的選擇，會讓人在畫下第一筆的時候感到壓力。藉由有意識地放棄創意選擇（如顏色或主題）讓畫家有勇氣在一片空白中，畫下第一個筆觸。

設計師也有同樣的能力跟力量，但客戶與設計師的關係，多了一種在藝術領域比較少見的心理障礙。在設計師的心中，客戶要求的限制，很奇妙地變成了一種束縛，鎖住了通往理想設計結果的大門。

這樣的視角，會導致設計師落入沒有生產力的自我框框裡。一方面可能誤解了客戶的初衷；同時在渴望創意自由的當下，也可能忽視了一些明顯的設計機會點。

每位設計師都應該知道的幾種限制

規格跟限制，不是一道道封閉的門，它們更像是指示牌。指引設計師，哪些地方才是真正值得下手研究的起點。

常見的設計限制有很多種，以下列出幾種類型，方便設計師去辨識跟應對。有些大家都知道，有些則會感到出乎意料。試著去理解這些限制為何存在，以及它們如何被用來推動設計創新。

商業限制 (Commercial Constraints)

商業限制與企業的資源相關，如時間、預算和人力。在設計項目中，這些商業上的限制會互相權衡。例如當客戶撰寫需求簡報時，商業限制會被顯著地呈現。 像是：我們需要X成果，Y時間內，花費Z成本。

商業限制並非是完全不可變動的。詢問客戶為何有這些限制，說不定可以爭取到更多的時間或預算彈性，或者可能挖掘出客戶尚未考慮到的設計需求。

閱讀全文 設計限制不會是束縛，反而能激發創意

[大衛選讀] 設計師很怕受批評，是嗎？在真正的設計教育跟業界實務中，設計批判 (design critique)，應該要是一種工作日常才對。

How To Give And Receive Design Critique Well 這篇文章，很有結構性地說明了什麼是設計批判。好的批判應該會在極端正負之間，有一條微妙的平衡線。不但可以同時辨識出一個設計的好跟壞，能建設性地給予回饋，有清楚的評估原則、務實的參考資訊，並且能鼓勵設計師從錯誤中學習。

你遇到的設計師，會一直為自己的設計辯護嗎？還是他們能夠充分說明設計的原委，然後熱切地張大耳朵，期待聽到你的看法與回饋？

重點摘要整理如下，全文連結：https://blog.prototypr.io/how-to-give-and-receive-design-critique-well-20a2639f79f1

---

如何更好地給予 & 接受設計批判 (design critique)

喜歡接受批評的設計師，非常罕見。

要針對他人的評論去修改設計很難，看到自己辛苦工作的成果被別人批評跟拆解，那更是會非常不舒服。所以設計師們創造了一個委婉的用詞：「反饋, feedback」，來稍稍緩解我們對於接受設計批評的心理恐懼。

在這篇文章中，我們將探討是什麼是設計批判 (design critique)，為何重要，以及我們為什麼應該學會熱愛並珍惜每一次的設計討論。

什麼是設計批判，為什麼很重要？

Critic 這個字，有判斷、評價的意思，同時也跟鑑別力有關。所以從字面上來看，Critic 評論家這個角色有兩個任務：首先，區分出好跟壞；其次，對作品形成整體評價。

好的設計批判，不只是找缺點。我們形塑出的鑑別度，應該同時包含了作品的正面與負面。身為評論者，我們應該努力做到中肯、誠實跟有同理心。有了這樣的態度，設計批判看起來更像是一種具創造性的任務，而不是去搞破壞。

如果 critique 批判做得好，將可以識別出作品的優點、有助於改善作品的弱點、幫助培養專業、增強團隊互信和協作，並且幫助整個設計專業領域持續進步和成長。

為了更好地理解，什麼是好的批判，以及跟糟糕的批判之間的差別，以下舉幾個例子：

閱讀全文 如何更好地給予 & 接受設計批判 (design critique)

[大衛選讀] How might we (HMW) 提問法，是UX體驗設計上常用的一項工具。儘管如此，我還是常常在作品集跟設計提案裡，看到很匪夷所思的 HMW問句。有些設計師會把「我們如何」當做一個神奇的發語詞，好像只要念出這幾個字，就能冒出神奇的設計創新。

事實上，HMW是很好的設計提問工具。用得好的話，可以在專案早期，透過一連串的好問題，跟團隊一起釐清設計方向，並且打開設計的空間，帶出創新的各種可能性。這個方向感，正是 HMW 有用而且好玩的地方。

本文參考了How Might We Statements: Asking the Right Questions這篇文章，但內容已經融入我的個人經驗，相當幅度地改寫過。

重點摘要整理如下，全文連結：https://www.viima.com/blog/how-might-we

---

How might we: 如何問對問題

「How might we (HMW)」 提問法，是設計思考當中，應用於問題定義階段的一種設計工具。這個工具讓你能夠透過同理心步驟的研究，在一狗票頑固且刁鑽的設計問題中，篩選出真正值得投入的核心議題，並幫助定義出實際可解的問題 (solvable problems)。

設計思考 (design thinking) 是一種以人為本的問題解決方法。它包含5個明確的階段：同理、定義、發想、原型和測試。

同理 (empathy) 是整個設計思考流程的起點。在這一步，你試著理解目標使用者是誰，以及他們的感受和需求。只有在掌握目標使用者之後，才有機會真正開始定義你的問題。

定義 (define) 則是設計思考流程的第二步。在這一步，你運用手頭上所有的研究數據，以及各種問題定義的方法，試著去找出最底層的東西。也就是，撇開一大堆的抱怨跟期待，到底什麼才是你真正需要解決的問題？

有些設計師會一開始就試著拼命去做「設計」，想辦法做點什麼東西出來給大家看。但這是沒有用的，就像有了一台計算機，手邊卻沒有沒有任何數學問題跟假設，那什麼也算不出來。只有先掌握了正確的問題，才可能產生有用的答案。

在問題定義的階段，有很多不同的方法可以運用，像是：5個為什麼 (5 whys)，問題框架 (problem framing) 等。在這當中， HMW 是一種創新、有趣，而且相當簡單的方式，來面對各種設計挑戰。

H、M、W 背後的魔法

How might we (HMW) 提供了我們思考問題的新視角。包含了Why 為什麼要做這件事、為什麼要創新、為什麼要改變；同時也拉出了 How 的討論，讓團隊開始去思考我們可以從什麼角度切入，去解決眼前的問題。

為什麼要用 might, 而不是can 或是 should? 如果一開始就用「可以」和「應該」這樣的字，人的腦袋裡面就會不自覺地開始進入一連串的批判跟評估：我們真的可以做得到嗎，這是一定得要做的嗎？改用「可能, might」這個字，則有助於延遲判斷，讓人們有機會打開更多可能性，自由地創造出更多的選擇。

閱讀全文 如何用 HMW 打開設計的空間跟方向感

[大衛選讀] 想太多 vs. 想太少，這常常是我跟設計師對談的時候，會遇到的兩種極端狀況。

要看一個設計師有沒有實務經驗，通常我會問一個問題：「你覺得一個功能流程，如果正向順著走的流程要寫5頁UX規劃文件，那負向流程大該需要幾頁？」

沒有實務經驗的設計師，大概會猜0.5~1倍左右；而身經百戰 (被磨到會怕) 的設計師，則多半會猜5~10倍。我個人經驗是約3~10倍，端看個別功能的複雜度。

How to find and deal with edge cases in UX design 這篇文章，很有系統地說明了，如何區分主要路徑、延伸案例、邊緣案例。同時也分享了實務上如何找到邊緣案例、如何評估跟排解。更重要的是，要知道什麼時候得放手，專注在真正重要的價值上。

重點摘要整理如下，全文連結：https://uxplanet.org/how-to-find-and-deal-with-edge-cases-in-ux-design-6852ab508205

---

我們經常在設計完產品解決方案，並認為所有事情都搞定之後，然後產品團隊中的一個開發者問我們：

「你們是否有考慮過，要如何處理用戶的這種情況？」

有時我們會說是；更多的時候，我們會說：

「我們之前沒有考慮到這種情況，好吧，我們得回去繼續工作，設法解決它。」

當設計師突然意識到，設計中存在一些邊界案例 (edge cases) 需要被解決，以便能夠發佈產品時；這總是使產品設計工作變得更加複雜，並且需要更長時間來解決。

在這篇文章中，我會說明如何找到邊界案例，如何處理它們，以及為什麼我傾向不去解決所有的邊界案例。

首先讓我們理解「快樂路徑」、「不同的案例」，和「邊緣案例」之間的區別。

快樂路徑  (happy path) 是指用戶採取行動之後，沒有遇到任何困難就能實現目標的情況。這是最常見的情況，也是大多數用戶會走的路徑。

以登入流程為例，快樂路徑大概會是：用戶打開應用程式 > 輸入電子郵件地址 > 輸入密碼 > 點擊登入按鈕 > 登入成功。

不同的案例 (different cases)，有些設計師叫它做錯誤案例 (error cases)。也行，就是多了一點設計師的個人價值判斷。最常見的例子是“忘記密碼”的功能，點擊後，會發送一封包含更改密碼指示的電子郵件。大多數情況下，除了透過信件重設密碼外，應該有不止一個流程路徑；而且權限越多層、資安層級越高的產品，重設密碼的流程會更加複雜。這樣的案例很常見，所以我們預設應該要解決它們。

邊緣案例 (edge cases)。假如用戶不僅忘記密碼，還忘記了電子郵件的密碼，這就是一個邊緣案例。在這狀況下，用戶會把我們的系統推到了極限。這是一種可能發生在少數用戶身上的極端情況，不常見，但確實可能發生，也就是它被稱為邊緣案例的原因。

閱讀全文 如何有效探索一個體驗設計的極限

這是 2021年四月，設計遊牧的Podcast文字記錄。如果你對於這一集的採訪內容有興趣的話，可以直接收聽完整錄音內容：http://apple.co/32gkKdq

主持人引言：

相信大家都有參加或辦理工作坊經驗，每每聽到「設計工作坊」心中就會浮現一個使用很多便利貼、團體討論、腦力風暴的畫面，但是，工作坊真的如你所想像，是解決問題的萬靈丹嗎？到底如何辦理一場讓客戶買單、成果有用、又能加速溝通的工作坊呢？這次邀請到 AJA 大予創意設計的使用經驗總監 David，來聊聊設計工作坊的迷思、實務經驗，以及如何應用

議題一：帶領小孩子工作坊的啟發前訪時 ，David 有跟我們提到如果今天不是做設計的話，會去做小孩子的啟蒙教育！你自己有帶著兩個孩子操作許多有趣的工作坊，並從中獲得很多啟發，應用在後來帶大人、帶客戶的工作坊上，要不要先跟我們分享一下你的看見和收穫。

當初怎麼會想開始設計小孩的工作坊？有哪些有趣的設計和發現？

真的耶，我有時候會想，我是不是被UX耽誤的老師或教練，呵呵。不過，設計確實是很泛用的能力，懂得設計的道理，要做什麼事情都會容易很多，也比較有進一步連結跟創造的可能性。

回到IDEA for Kids的起點，最早是在三年前，我發現現在國小的孩子有兩個狀況。第一個是資訊取得太容易，只靠Google查答案，不太去動腦想事情。例如有一年寒假作業要畫年獸，小孩子Google圖片搜尋到什麼，就跟著畫什麼。他們對於年獸的起源典故沒有什麼背景理解，也沒有什麼深入的想像，就照著Google上面找到圖案下去抄，那真的是很可惜耶。

第二個是，學校裡的團隊協作、溝通互動太少。不是你聽我的，就是我照你說的做，不習慣去做團隊的共創跟激盪。孩子的可能性本來應該是很開闊的，一群孩子湊在一塊，能打開的空間應該很大才對。如果都只能一個人單打獨鬥，那就浪費了這個可能性。

所以，在一次的契機下，造就了IDEA for Kids的設計思考工作坊原型。那是2018年，那年規劃要去日本東京迪士尼玩。跟鄰居的兩個小朋友一起出門，總共四個孩子，吵了半天，到了出門前的一週，大家對於要玩哪幾個設施、行程要怎麼走完全沒有共識。像是巨雷山，他們的討論是那裡會打雷，很恐怖，我不要。你一聽就知道他們沒有什麼脈絡，就只是瞎吵一輪。其實這跟大部分的大人開會很像，哈哈。

我花了一個晚上，把迪士尼兩個樂園，總共60幾個遊樂設施，都做成討論用的牌卡。相關資料都在迪士尼官網上，複製貼上就可以了。接下來就走共創討論的流程：

首先是「理解」：帶著孩子先從看迪士尼的樂園設施介紹影片開始，搭配牌卡說明，每看完一個就把牌卡貼上牆，先對個客觀事實有一致性的理解，後續的討論才有個基礎。

接下來是「設定討論框架」。其實一天最多就只能玩8-10個遊樂設施，一定是玩不玩的，得去做挑選跟判斷。跟孩子討論，那你們的選擇的條件是什麼？他們第一個選了「冒險」，這是孩子心裡的渴望，很好；選了「有Fast Pass的」，很聰明，因為他們發現有Fast Pass的都品質保證；選了「台灣沒有」，很務實，出國玩就是要玩點不一樣的；最後選了「恐怖」，這不是因為喜歡恐怖的東西，而是想要去揭穿大人的陰謀，因為這一定都是大人編出來呼嚨小孩的，他們想要去揭穿大人的騙術。很好，有自己的想法，有一致性的討論條件跟框架，這樣後續就可以務實地交流跟決策。

閱讀全文 設計遊牧 EP26 – 卡住了就來場設計工作坊吧！？

晚上七點，David從容走進會議間，手上提著一袋晚餐和飲料，笑著說怕我們餓；這樣注重每個體驗細節的態度，融入了他與設計團隊的日常。OpenHCI採訪小組這次來到深根臺灣設計顧問領域多年的AJA大予創意設計，並很榮幸能與其使用經驗設計總監David 陳文剛（以下簡稱David）進行一個多鐘頭的訪談。

秉持“Real problem, real solution”，在每個設計流程都做到位

一開始，我們好奇地詢問AJA有沒有什麼服務準則、設計規範？David 則表示，其實並沒有一個絕對的準則，但存在著服務客戶的終極信念：“Real problem, real solution” 他也進一步解釋，如果還沒有定義出真正要解決的問題，專案就不會立刻開動。許多題目起點上看似要幫助特定用戶族群，但是深入理解釐清後會發現，也許關鍵問題不在這裡，也許真正需要關注的users, 甚至是stakeholders比我們想像的來得多。

至於該如何評估是否為 Real problem, real solution呢？David 認為需要去思考：「專案的核心問題是什麼，是否有清楚的目標？以我們的專業能不能做好的探索與落地？能不能真正幫助到客戶？這些條件都符合，我們才會去承接專案、服務客戶。」David也補充，一旦AJA的團隊幫上忙後，客戶通常會持續與他們合作，無論是延伸既有專案，或是接續去挑戰下一個更難的題目。他也提到必須要讓甲方和乙方的關係是長遠而健康的，在路上遇到也能像朋友一樣開心打招呼，是他們一直期待的合作關係。

閱讀全文 OpenHCI專訪: 台灣最大UX設計顧問團隊，有著怎樣的日常，如何看待設計？