◆ 為什麼設計稿很漂亮，做出來卻「破破爛爛」？
在 《#059 寫給 PM 的設計心理學》，我們談了如何用格式塔原則 Review UI。當畫面調整到順眼之後，考驗才真正開始。
原因很簡單：產品不是放在 Figma 裡被欣賞的，而是會在各種不理想的情境下被使用。
PM 最常遇到的困境是：Demo 階段看起來都很漂亮，但一旦上線，頁面變形、資料空白、錯誤訊息像天書。
回頭檢視設計稿時，也很難把責任推給設計師，因為稿上通常只呈現流程最順的那條路。
真正的魔鬼，藏在那些 Edge Cases (例外狀況) 裡。
◆ Happy Path vs. Unhappy Path：你以為使用者在走流程，其實他在撞牆
設計稿通常只描繪一種順利的使用情境：資料齊全、網路穩定、字數剛好。
這條路被稱為 Happy Path (快樂路徑)。
然而，真實世界更常遇到的是 Unhappy Path (痛苦路徑)：
資料還沒載入、網路斷線、名字太長導致版面炸開、後端回傳錯誤碼。
PM 在這一關要留意的重點其實很清楚：
不要只檢視「流程順利」的情境，也要檢視「流程不順利」的情境。
因為使用者通常不會因為 UI 好看就原諒 Bug。他更在意的是按下去後「結果是否符合預期」。
◆ 四種最常被忘掉的狀態：Loading、Empty、Error、Success
不少產品在設計稿上只交代「完成畫面」，其餘狀態 RD 只好自己發揮（通常就是放一個醜醜的瀏覽器預設彈窗）。
結果就是產品進入開發後才開始補洞，修正成本極高。
請務必把這四種狀態定義清楚：
1. Loading (載入中)
- 別只放轉圈圈：至少要讓使用者理解「目前在做什麼」（正在整理資料…），以及「大概還需要多久」。
- 骨架屏 (Skeleton Screen)：比起轉圈圈，顯示一個灰色的版面骨架，會讓使用者感覺載入比較快。
- 可取消嗎？：如果載入太久，有沒有「取消」或「重試」的按鈕？否則使用者會暴力重新整理，導致系統負載更重。
2. Empty (空狀態)
- 空值不是錯誤：空值代表「目前沒有內容」。
- 這是最好的引導機會：不要只寫「沒有資料」。要寫「為什麼是空的？」以及「怎麼讓它變有？」（例如：「尚未建立專案」，下面放一個大大的「建立專案」按鈕）。
3. Error (錯誤狀態)
- 說人話：不要寫
Error 500: Server Internal Error。要寫「伺服器累了，請稍後再試」。 - 給出路：告訴使用者現在該怎麼辦？是「稍後再試」？還是「聯絡客服」？不要讓他卡死在死胡同。
4. Success (成功狀態)
- 成功之後呢？：不要只顯示「成功」。要告訴他「下一步去哪裡」（例如：回到列表、查看詳情）。
- 非同步處理：如果是「已送出，稍後處理」，請講清楚，否則使用者會以為系統沒反應，又多按了好幾次。
◆ 極端資料會把 UI 的假象撕開
字體大小、行距、卡片高度在正常資料下看起來都很合理。
但遇到極端值時，往往會立刻暴露結構性問題。
以下幾種情境特別值得直接拿來測試：
1. 名字長到 50 個字
- 公司名稱、活動名稱往往很長。
- 規則定義：要換行？還是用
...省略？滑鼠移上去有沒有 Tooltip 顯示全文？
2. 金額有小數點、負數、天價
- 不要假設金額永遠是整數。
- 規則定義：千分位怎麼標？小數點顯示幾位？負數要不要變紅字？
3. 圖片災難
- 解析度太低：會不會糊掉？
- 比例不一致：會不會被切到頭？（設定
Object-fit規則） - 載入失敗：有沒有預設圖 (Placeholder)？還是會顯示一個「破圖」圖示？
◆ 文字與多國語言：不是排版問題，是信任問題
許多介面災難表面上看起來是排版問題，實際上是使用者開始懷疑系統可靠度。
1. 文字截斷 (Truncation)
按鈕文案過長被截斷，使用者無法判斷點下去會發生什麼。
規則定義：按鈕寬度是固定的還是彈性的 (Responsive)？
2. 多國語言 (Localization)
- 英文通常比中文長 2 倍：德文更長。
- 版面炸裂：若只在中文稿上檢視，等到切英文那天，按鈕變兩行、表格破版，幾乎是必然。
- 測試技巧：用「Google 翻譯過的網頁」先做一次壓力測試，通常就能暴露問題。
◆ 怎麼把關？一張「狀態表」+ 三包「測試資料」
實務上，要降低補洞成本，關鍵在於把「狀態」提前變成共同語言。
我自己的做法是，在 UI Review 進入開發前，要求團隊至少補一張 UI Stack (狀態表)：
同一個頁面，Loading / Empty / Error / Success 長怎樣？
這張表一旦建立，設計師較好完善畫面，RD 較好落實邏輯，PM 也更容易驗收。
再搭配 三包測試資料 跑一遍流程：
- 空的 (Empty)：完全沒有資料時，畫面長怎樣？
- 極端的 (Extreme)：超長文字、超大數字、異常圖片。
- 錯的 (Error)：格式錯、必填漏、網路斷線。
◆ 廣三觀點
嗨，我是廣三。
做產品一段時間後會發現：UI 好看只是第一關。
真正痛苦的，是那些「設計稿沒有交代」的狀態。
它們不太會出現在簡報裡，卻常出現在使用者最不安、也最容易流失的時刻。
你不需要把每一個例外都推演到極致，那不划算。
但要把最常見、最容易造成不信任的狀態（空值、錯誤、載入）先交代完整。
下一次你在看 UI 稿時，不必只問「好不好看」。
更值得問的是：
「資料是空的時會怎樣？」
「網路斷線時會怎樣？」
「輸入錯誤時會怎樣？」
這些都被顧到，產品才算真正具備「進入戰場」的能力。
若你在PM這條路上感到迷茫，
或想更清楚了解自己的能力與定位，
歡迎試試這份《PM產品／專案雙軌分析報告》。
它不為了定義你，而是幫助你更看清自己。
歡迎關注：
官網：https://unityprosper.com/
部落格：https://hero-mi.com/
FB：https://www.facebook.com/DigiPRDCoachHeroMi
LINE OA：@hero-mi
《歡迎加我LINE，一起破局未來》
請於下方輸入電子郵件信箱，即可接收最新訊息。
留言