[大衛選讀] 想太多 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)。假如用戶不僅忘記密碼，還忘記了電子郵件的密碼，這就是一個邊緣案例。在這狀況下，用戶會把我們的系統推到了極限。這是一種可能發生在少數用戶身上的極端情況，不常見，但確實可能發生，也就是它被稱為邊緣案例的原因。
為什麼我們需要解決邊緣案例
從用戶體驗的觀點來看，未解決的邊緣案例可能會對用戶體驗產生負面影響。Google Drive之類的雲端硬碟服務，如果設定了過短的檔名顯示限制，用戶將無法看到文件的完整名稱，而這可能會影響到用戶體驗。
從技術的觀點來看，也需要針對邊緣情境有適當的設計。假如系統上傳的限制是10GB，在99.99%的情況下，用戶上傳的文件大小會介於 1MB 到 500MB 之間。當有人突然上傳一個 2TB 的文件時，在這種情況下，我們必須意識到系統可能有崩潰的風險。如果你是與開發人員一起共事，他們通常會注意到這類的技術邊緣案例，並且提出問題。
我同時想強調的是，我們並不需要解決所有的邊緣案例，因為有時候這樣做可能並不值得。
如何在你的設計中找到邊緣案例
根據我的經驗，我使用三種主要的方法來掌握邊緣案例：
首先，在設計工作中找到邊緣案例。我會在一份文件中累積記錄所有想到、遇到的邊緣案例。一旦解決了happy path 跟 different cases，我就會回頭查看這份清單，並著手處理它們。
再來，當完成設計後，我會使用像 Figma 這類的設計工具創建一個互動原型，並開始試著自己操作看看，停在每一個螢幕並問自己簡單的問題，例如：
– 如果用戶試圖上傳一個大文件會發生什麼事？
– 如果檔名太長會怎麼樣？
– 如果這時候失去網路連線會怎麼樣？
最後，在設計完成後，我會將設計展示給開發人員，並請他們指出觀察到的任何錯誤或邊緣案例。開發人員之外，QA測試人員是我遇過，最善於找到邊緣案例的一群人，他們通常會將產品測試到極限，對於這類情境非常有經驗。
識別並解決邊緣案例的正確過程
一般來說，如果一位設計師對於邊緣案例考慮很多很細，並且試圖在完成整個設計系統之前，就試著先解決這些邊緣案例；那在我看來，這可能是一個很有問題的事情。
為什麼從一開始就關注邊緣案例或解決它們，會是一種錯誤的作法？
就像我們的日常生活一樣，凡事必須先解決最重要關鍵的問題，然後再逐步解決其他不那麼急的項目。設計的過程，當然也是如此。
設計師們必須明白，重點是要先針對設計的原始目標，找到一個解決方案。這是設計最重要的核心，也就是一般人預設會走的 happy path。然後再解決 different cases，最後才是邊緣案例。
Happy path 是解決方案的核心，必須全力以赴，竭盡所能地解決它。這是大多數用戶會使用的情境，我們必須從這一點開始著手。在徹底搞定 happy path 之前，寧願不去觸及different cases，更不用說是邊緣案例了。
評估邊緣案例是否值得動手處理，要思考的是：解決這個邊緣案例是否很重要？如果我們不解決，它會對用戶體驗產生重大影響嗎？
首先，取決於情境。小公司要衝成長，跟大公司要維持廣大用戶的可用性，那需要考慮的重點就會不一樣了。
再來，取決於產品。如果產品的價值來自於高品質、零錯誤，那麼邊緣案例的解決與否，可能就會影響到產品的獲利，而必須謹慎對應。
與團隊確定優先順序
每當你設計新的東西時，總是會遇到多個邊緣案例需要解決。設計師有時會過於關注在用戶介面設計上，一些不那麼重要的細節。透過讓其他團隊成員參與其中，給予回饋，設計師可以更好地了解全局。
試著列出所有的邊緣案例，並且跟產品經理和開發人員共同卻認邊緣案例的優先順序，會是比較好的做法。這將讓團隊對這些案例有一個清晰的了解，並幫助團隊了解，最關鍵必要的是哪些項目。
最後
邊緣案例是我們 UX 設計工作的一部分，作為一個UX設計師，你需要識別並解決它們。我們可以在產品的邏輯中、在互動元件的設計上，以及在整體使用介面上，找到各種邊緣案例。
解決邊緣案例之前，最好先排序，從最重要的問題開始著手。此外，需要跟產品團隊有一致的共識，清楚區分出需要解決，以及可以忽略的邊緣案例。
想太多跟沒想過之間，應該有一個最好的權衡點。
