作者: David 陳文剛

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

這是 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的都品質保證；選了「台灣沒有」，很務實，出國玩就是要玩點不一樣的；最後選了「恐怖」，這不是因為喜歡恐怖的東西，而是想要去揭穿大人的陰謀，因為這一定都是大人編出來呼嚨小孩的，他們想要去揭穿大人的騙術。很好，有自己的想法，有一致性的討論條件跟框架，這樣後續就可以務實地交流跟決策。

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

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

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

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