作者: David 陳文剛

[大衛選讀] 設計師很怕受批評，是嗎？在真正的設計教育跟業界實務中，設計批判 (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 批判做得好，將可以識別出作品的優點、有助於改善作品的弱點、幫助培養專業、增強團隊互信和協作，並且幫助整個設計專業領域持續進步和成長。

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

[大衛選讀] 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」這個字，則有助於延遲判斷，讓人們有機會打開更多可能性，自由地創造出更多的選擇。

[大衛選讀] 想太多 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)。假如用戶不僅忘記密碼，還忘記了電子郵件的密碼，這就是一個邊緣案例。在這狀況下，用戶會把我們的系統推到了極限。這是一種可能發生在少數用戶身上的極端情況，不常見，但確實可能發生，也就是它被稱為邊緣案例的原因。