UIUX – UI 策略
H.Y. Chen UI 策略（UI Strategies）談的是：畫面在「等資料、寫入、失敗、衝突」時要怎麼表現。跟元件名稱（Button、Modal）不同，這篇文章主要着重在「行為與時機」。
一、寫入回饋策略（Optimistic / Pessimistic UI）
Optimistic UI（樂觀更新）
先假設這次操作會成功：使用者一按，畫面立刻改成成功後的樣子，再在背景打 API。成功就維持；失敗再還原並提示錯誤。
- 適合：按讚、收藏、開關、清單勾選等低風險、可輕易還原的操作。
- 優點：體感很快，不用乾等 spinner。
- 代價：失敗時要能 rollback，並說清楚「其實沒存成功」。
Pessimistic UI（悲觀更新）
先等伺服器確認成功，再改畫面。按下後通常進 loading／disabled，成功才更新；失敗則留在原狀並顯示錯誤。
- 適合：付款、刪除、權限變更、不可輕易還原的寫入。
- 優點：畫面與真實資料較不易短暫不一致。
- 代價：網路慢時使用者會明顯感到等待。
注意：這裡的「樂觀／悲觀」指的是畫面要不要先改，不是資料庫的樂觀鎖／悲觀鎖。
中間態（Pending / Intermediate）
不完全樂觀也不完全乾等：先顯示「處理中」狀態（例如列上出現 pending 標記、按鈕轉圈），成功再變成最終狀態。
二、載入、空、錯三態（Loading / Empty / Error）
同一個畫面通常至少要設計三種內容狀態：
| 狀態 | 意思 | 常見 UI |
|---|---|---|
| Loading | 資料還在路上 | Skeleton、Spinner、按鈕 loading |
| Empty | 成功但沒有資料 | 空狀態插圖＋下一步引導 |
| Error | 請求失敗 | 白話錯誤說明＋重試 |
再補兩個常見狀態：
- Success：短暫 Toast／Snackbar（如「儲存成功」）。
- Partial：部分成功（例如批次上傳 10 筆失敗 2 筆），要能逐筆說明。
三、防重複提交與操作鎖定
使用者連點「送出」時，若不處理，可能重複建立訂單或重複扣款。
常見策略：
- 送出當下把按鈕 disabled，並顯示 loading。
- 請求進行中忽略再次點擊（前端節流／鎖旗標）。
- 必要時搭配後端 idempotency key（同一操作重送只生效一次）。
這跟悲觀 UI 常一起出現：先鎖住操作，等伺服器回應再放開。
四、衝突、回滾與權威來源
衝突（Conflict）
兩人幾乎同時改同一筆，或樂觀更新期間伺服器其實已是新版本。UI 要決定：覆蓋、合併、還是提示「資料已被他人更新，請重新載入」。
回滾（Rollback）
樂觀 UI 失敗時，畫面必須回到操作前，且提示不能只說「錯誤」而不還原。
權威來源（Source of truth）
最終以誰為準：伺服器、本地快取、還是表單草稿？多人協作與離線場景一定要把規則講清楚，否則 UI 會「看起來存了、重整又沒了」。
五、感知效能（Perceived Performance）
實際還沒更快，但讓使用者覺得比較快：
- Skeleton 先畫結構，比空白轉圈更安心。
- 樂觀更新讓高頻小操作幾乎零等待。
- 預取 prefetch 在使用者可能點之前先載入。
- 優先顯示首屏，次要區塊延後。
六、狀態機思維（UI as State Machine）
把一個元件／一頁想成有限狀態，例如：
idle → loading → success | error
或表單：
pristine → dirty → submitting → success | error
好處：避免「loading 跟錯誤同時出現」「成功了按鈕還在轉」這類非法組合。實作可用明確的 status 欄位，而不是一堆互斥的 boolean。
UI 策略的核心不是「看起來炫不炫」，而是：等待時說清楚、失敗時能復原、成功時與真實資料一致。
1 comment