介面設計中，使用者每執行一個動作，系統都必須提供回饋。回饋是可用性的基本要求。沒有回饋的按鈕，使用者無法區分「系統在處理」和「按鈕壞了」。

這個原則對應 Jakob Nielsen 十大可用性啟發法的第一條：系統狀態可見性（Visibility of System Status） — 系統應透過適當的回饋，在合理時間內告知使用者目前發生了什麼。

三層回饋模型

使用者按下按鈕後，回饋依時間順序分三層：

第一層：點擊確認（0-100ms）

系統確認「收到你的操作了」。

設計原則：第一層回饋必須在 100ms 內出現。這個門檻來自人類感知研究 — 100ms 以內的延遲被感知為即時反應，超過後點擊與回饋之間開始出現可察覺的落差，回饋就失去「確認」的效果。平台原生元件的 pressed / ripple 互動態已滿足這個門檻，用平台預設互動態即自動合格；自建元件（自繪按鈕、canvas UI）才需要自行驗證回饋延遲。

第二層：等待指示（100ms - 10s）

系統告知「正在處理你的請求」。

設計原則：等待期間必須禁用觸發按鈕（disabled 狀態），防止使用者因焦慮而重複點擊導致重複提交。UI 層的防重複提交降低發生率；最終防線是伺服器端的冪等設計 — 重複請求真的到達後端時要能被識別與去重。兩層都要做，本系列只涵蓋 UI 層。

400ms 門檻（Doherty Threshold） 的實務意義：非同步操作通常在 400ms 內完成時，可省略 loading 指示器、直接跳到第三層的結果回饋（點擊確認仍要在第一層提供）。這條門檻的出身與適用邊界、以及實際延遲有快有慢時怎麼對表，時間感知與回應策略有完整推導。

第三層：結果通知

系統告知「操作的結果是什麼」。

設計原則：結果通知必須恢復按鈕到可操作狀態。操作結束後按鈕仍顯示 loading = 介面凍結。

空結果的呈現：空狀態畫面要讓使用者分得出「查詢成功但沒有資料」和「還沒載入完」— 給明確文字（「沒有符合的結果」）與下一步建議（放寬條件、建立第一筆資料），載入中則維持等待指示。空狀態與錯誤狀態的措辭由模組四：錯誤訊息撰寫原則接手。

部分成功的呈現：批次操作（匯入 100 筆、87 筆成功）用摘要加明細兩層：摘要先告知整體結果（「87 筆成功、13 筆失敗」），明細列出失敗項與各自的修正動作，讓使用者只需處理失敗的部分、而非重跑整批。

結果通知的鏈路前提：第三層的設計都假設「結果會正確到達 UI」。UI 與執行端分屬不同 context 時（browser extension 的 popup / content script / service worker、跨 process 架構），結果要跨訊息通道才到 UI — 通道語意錯誤或事件訂閱缺失會讓通知消失、甚至反轉。一個 Chrome extension 提取成功 96 本且已寫入 storage，popup 卻顯示「提取失敗」— async listener 把 undefined 搶先當回應送回（U.C9）。跨 context 的結果通知要有端對端驗證（操作成功 → UI 顯示成功），不只測 UI 收到資料後的呈現。

本篇聚焦「該通知什麼」；SnackBar / Dialog / Banner / Bottom Sheet 之間的形式選擇由通知模式選擇展開。螢幕閱讀器的通知宣告（aria-live / aria-busy）屬無障礙實作，不在本模組範圍。

兩類按鈕的回饋設計

依操作的時間特性，按鈕分兩類（各狀態的視覺設計在按鈕狀態設計展開）：

非同步按鈕（API / 資料庫 / 權限請求）

完整三層回饋：

1[idle] → 點擊 → [loading: disabled + spinner] → 完成 → [idle + 結果通知]

設計要點：

• loading 期間按鈕 disabled（防重複提交）
• 按鈕文字可變（「送出」→「送出中…」）
• 結束後恢復 idle 狀態

同步按鈕（導航 / 切換 / 開關）

僅需第一層 + 防連點：

1[idle] → 點擊 → [視覺回饋 + 執行] → [完成]

設計要點：

• 操作在 100ms 內完成，不需 loading
• 加入防連點（300ms 上下的慣例值）避免快速連點觸發多次導航
• 視覺回饋（ripple / 狀態切換）即足夠

防連點的語意：第一次點擊立即執行、之後 300ms 內的點擊忽略（leading-edge debounce），或用導航鎖（in-flight flag）在導航完成前拒絕新請求。反過來「等 300ms 沒有新點擊才執行」（trailing debounce）會給每次導航加上 300ms 延遲，直接違反第一層的 100ms 門檻 — 防連點防的是第二次點擊，第一次要立即生效。

畫面級回饋：多步驟流程的狀態轉換

上述按鈕級回饋處理的是「按一個按鈕」的單一操作。但有些使用者流程涉及整個畫面的狀態轉換 — 連線、配對、同步、多步驟表單 — 每個中間狀態都需要能被使用者區辨的 UI 回饋。

與按鈕級的差異

設計模式

以連線流程為例：

1[idle] ─點擊連線→ [connecting] ─成功→ [connected]
2                       │                    │
3                       ├─失敗→ [error]       ├─斷線→ [disconnected]
4                       └─取消→ [idle]        └─手動斷開→ [idle]

每個狀態的回饋設計：

關鍵設計原則：error 和 disconnected 必須同時提供「重連」和「返回」兩條路徑。只有重連會把使用者鎖在錯誤迴圈（如果問題無法透過重連解決，使用者永遠出不去）。

timeout 是 connecting 的隱形退出路徑：取消靠使用者主動，timeout 是系統兜底 — 取值略大於 client / 後端的逾時設定（讓真正的失敗先回來、而非 UI 提前放棄），逾時後轉入 error 狀態走「重連 / 返回」。

畫面級回饋的檢查清單

• 每個中間狀態能被使用者區辨（獨立畫面、或同畫面上明確的狀態指示）？
• 每個中間狀態有退出路徑（對應畫面狀態矩陣）？
• 等待狀態提供取消操作？
• 錯誤 / 中斷狀態提供重試和返回兩條路徑？
• 長時間等待有 timeout 機制（不會永久卡在 connecting）？

反模式

表格第一行（按鈕無任何視覺回饋）的完整實證案例見 U.C5 匯出按鈕零回饋——狀態機完備但 UI 沒接線，三層回饋全缺。同族的兩個變體：佔位 handler 上線 — 按鈕存在但 onPressed 只接開發提示或 log，dev toast 讓開發自測「有反應」、掩蓋未接線（U.C20）；回饋文字被版面擠壓 — state 有值、綁定正確，flex 寬度競爭把「已選擇: 3/45」壓成「…」（U.C19）。回饋鏈要驗到使用者的眼睛，state 有值、widget 有綁都不是終點。

版面擠壓類問題有一個常見的誤歸因：專案用了等比縮放套件（如 flutter_screenutil），版面出事時第一反應是查套件設定。換算工具工作在常數層（設計稿座標 → 裝置座標的數值換算）、空間分配發生在 layout 協商層（有限寬度分給動態內容）— 兩層獨立，「有用響應式套件」不構成版面不會擠壓的保證。判斷式（換算錯 vs 分配錯）與三層修法（設計層空間競爭規格 / 實作層 flex 顯式決策 / 驗證層窄幕檢查）見 #228 等比縮放不管空間分配。

設計檢查清單

為每個按鈕逐一確認：

• 點擊瞬間有視覺回饋（ripple / 狀態變化 / 觸覺）？
• 非同步操作：按鈕進入 disabled + loading 狀態？
• 非同步操作：完成後按鈕恢復 idle？
• 操作結果有明確通知（成功 / 失敗 / 空）？
• 失敗時提供可執行的下一步（重試 / 替代方案）？
• 同步按鈕有 debounce 防連點？

參考來源

本篇整理的設計原則來自以下公開可用性研究與設計系統：

• Nielsen’s 10 Usability Heuristics（Nielsen Norman Group, 1994）— 啟發法 #1「系統狀態可見性」是回饋設計的理論基礎
• Doherty Threshold（Doherty & Thadani, IBM 技術報告, 1982）— 400ms 回應時間門檻的原始研究
• Jakob Nielsen’s Response Time Limits（1993）— 100ms / 1s / 10s 三門檻模型
• Material Design 3: Interaction States（Google, m3.material.io）— 按鈕互動狀態定義（loading indicator 是 M3 的獨立元件、引用見時間感知與回應策略）
• Apple Human Interface Guidelines: Feedback（Apple Developer Documentation）— 回饋要可察覺、資訊明確並準確反映進度（本系列據此精神歸納出「即時、誠實的回應」的說法）
• Laws of UX（Jon Yablonski, lawsofux.com）— Doherty Threshold 的現代整理與應用案例

按鈕的每種視覺狀態都傳達一種系統訊息，缺少任何一種，使用者就失去對應的判斷依據。三層回饋模型回答「什麼時候給回饋」，本篇回答「用什麼視覺狀態給回饋」— 從無互動、游標懸停、鍵盤焦點到處理中，一顆按鈕的生命週期裡每個階段都有它要對使用者說的話。

基本狀態

前五種狀態出自 NN/g 與 Material Design 的互動狀態定義；Loading 則來自非同步按鈕的回饋需求（等待指示 + 防重複提交）— 本篇把它跟五個通用狀態並列，因為缺了它、非同步按鈕的生命週期就不完整。切換型控件（toggle、segmented control）另有 selected 態 —「現在是開還是關」也是一種系統訊息；本表聚焦動作按鈕，選取態屬選擇控件設計。

Default

按鈕的初始狀態（三層回饋模型的狀態流程圖以 idle 標記的就是這個狀態）。設計重點：讓使用者一眼辨識「這是個按鈕」。常見設計手法包括填色背景、邊框、圓角矩形、陰影。與普通文字或裝飾元素的區別必須明確。

Hover（桌面端）

游標移到按鈕上方時的狀態。行動裝置沒有 hover 概念（手指碰到螢幕就是點擊），這個狀態僅對桌面端（含 web）有意義。常見做法是背景色稍微加深或加上微陰影。

Active / Pressed

使用者按住按鈕瞬間的狀態。對應三層回饋模型的第一層「點擊確認」。視覺上通常表現為凹陷效果、顏色加深或縮小動畫。在觸控裝置上可搭配觸覺回饋（震動）。

Focus

透過鍵盤 Tab 鍵導航到按鈕時的狀態。這是無障礙設計（Accessibility）的基本要求 — WCAG 2.1 要求所有可互動元素在獲得焦點時必須有可見的視覺指示。常見做法是加上明顯的邊框或外框光暈。

Disabled

按鈕不可操作時的狀態。設計要點：

• 視覺上與可操作狀態有明確區別（通常降低透明度）
• 告知使用者「為什麼不能按」 — 單純灰掉不夠。優先用常駐說明文字（按鈕旁的條件提示）；tooltip 只在桌面端可行 — 行動端沒有 hover、disabled 元素通常也不接收 focus，hover 觸發的提示對行動端與鍵盤使用者不可達
• disabled 與隱藏的分工：條件可由使用者滿足時用 disabled（灰掉 + 說明怎麼解鎖，讓使用者知道功能存在）；條件與使用者無關（權限不足、功能未開通且無法自行開通）時考慮隱藏 — 展示一個永遠按不了的按鈕只製造困惑

Loading

非同步操作處理中的狀態。對應三層回饋模型的第二層「等待指示」。設計要點：

• 按鈕內容替換為 spinner 或文字變更（「送出」→「送出中…」）
• 按鈕自動進入 disabled（防重複提交）
• 操作完成後必須恢復到 default 或顯示結果
• 設定逾時：取值略大於 client / 後端 timeout，逾時後恢復並給錯誤訊息（兜底原則同三層回饋模型畫面級的 timeout 段）

非同步按鈕的狀態流

非同步按鈕＝點擊後需要等待伺服器或 IO 回應的按鈕（送出表單、呼叫 API）；同步按鈕＝操作在本地立即完成的按鈕（導航、切換）。

1[Default] ─點擊→ [Active] ─釋放→ [Loading] ─完成→ [Default + 結果通知]
2                                      │
3                                      └─失敗→ [Default + 錯誤訊息]

要點

1. Active → Loading 的過渡 在使用者釋放點擊後立即發生（不等伺服器回應）
2. Loading 期間按鈕 disabled — 這是設計需求不是實作細節
3. Loading → Default 必須發生 — 不論成功失敗，按鈕必須恢復可操作狀態
4. 結果通知獨立於按鈕 — 成功/失敗訊息用 SnackBar 或畫面更新呈現（形式選擇見通知模式選擇），不塞在按鈕裡

同步按鈕的狀態流

1[Default] ─點擊→ [Active] ─釋放→ [Default]（操作在釋放時同步完成）

同步按鈕不需要 Loading 狀態。防連點用 debounce 處理，不用 disabled — disabled 會讓按鈕在每次點擊後閃跳灰態，而第一次點擊本來就該立即生效；「立即執行、短時間內忽略後續點擊」的執行語意，三層回饋模型的防連點段有完整說明。

落點：設計系統元件層

這些狀態的實作落點在共用 Button 元件層，不是逐顆按鈕。Material、Cupertino 等平台元件庫已內建 hover / pressed / focus 的視覺處理，真正要補的通常只有 Loading 與 Disabled 的語意 — 何時進入、何時恢復、disabled 原因怎麼給。估工時以「元件層一次工 + 各按鈕接上狀態來源」計算，而非「按鈕數 × 狀態數」— 後者會把成本高估數倍，讓完整的狀態設計看起來做不起。

元件語意與版面

狀態清單之外，按鈕的文字、圖示、選中視覺與所在的版面各自承載語意，常見缺口：

切換元件的標籤要能區分「現態」與「動作」。「顯示目標模式」（播放鍵顯示「播放」）和「顯示當前模式」（開關顯示現態）是兩種並存慣例，單顆文字按鈕無法自證是哪種 — 名詞標籤（「管理模式」）特別容易被讀成狀態指示。消歧做法：狀態顯示與動作按鈕分離（非互動的現態文字 +「切換模式」動作鈕）、或改用自帶 on/off 語意的控件（switch / segmented control）。不幫助消歧的圖示是雜訊、應移除（U.C15）。

非互動指示不可與動作按鈕同形。狀態圖示混排在動作按鈕同列、又用近似圖形（描邊 vs 實心）時，使用者的預設是整列可點 — 點到指示的「沒反應」被讀成按鈕壞掉。描邊 / 實心差異不是可靠的互動性訊號；指示要用明顯非按鈕的形態（文字 chip、圓點）或移出動作列，同一個圖形全畫面只承載一個語意（U.C18）。

選中態是（底色, 文字色）的成對設計。只設定選中底色、文字色走主題預設，組合對比沒有人驗證過 — 淺藍選中底疊淺色預設文字就是「選中後看不到字」的成因。對比方向成對反轉：底色淺配深字、底色深配淺字，逐狀態驗 WCAG AA（一般字級 4.5:1、大字 3:1）（U.C17）。

水平排列的元件列溢出時要有捲動 affordance。chip 列、按鈕列超出畫面寬度時，截斷的預設讀法是「壞了」或「被旁邊的元件遮住」、不是「可以捲」— 提示手段：邊緣漸層遮罩、下一個項目部分露出、方向箭頭、捲軸指示；選項少時優先消除溢出（wrap 換行、改選單）。截斷邊緣緊貼固定按鈕會讓視覺歸因錯到那顆按鈕上 — 一條實作正確的可捲動篩選列因此在驗收被回報成「被重新整理按鈕遮蔽」（U.C16）。

常見設計失誤

設計檢查清單

逐一確認每個按鈕：

• 有 Default 狀態且明確可辨識為按鈕？
• 桌面端有 Hover 狀態？
• 有 Active / Pressed 視覺回饋？
• 有可見的 Focus 狀態（鍵盤導航）？
• Disabled 狀態有說明原因？
• 非同步按鈕有 Loading 狀態？
• Loading 期間按鈕 disabled？
• Loading 有超時機制（不會永久卡住）？
• Loading 結束後恢復可操作狀態？
• 切換型按鈕的文字讀起來是動作而非現態（或已拆成狀態顯示 + 動作按鈕）？
• 同列的非互動指示與動作按鈕形態可區分、圖示無撞名？
• Selected 態的底色與文字色成對設計、對比達 WCAG AA？

參考來源

• Nielsen Norman Group: “Button States: Communicate Interaction” — 按鈕各狀態如何傳達互動性的使用性研究
• Material Design 3: States（m3.material.io/foundations/interaction/states）— Google 設計系統的互動狀態定義
• WCAG 2.1 Success Criterion 2.4.7: Focus Visible — 焦點狀態可見性的無障礙標準
• Apple Human Interface Guidelines: Buttons — Apple 的按鈕設計原則

概念位置

Debounce 站在互動回饋的輸入端：Touch Target 管點擊有沒有落在可反應的區域、debounce 管落進來的重複點擊怎麼收斂、Doherty Threshold 管收斂後的輸出多快要回來——三張卡沿著「一次點擊的生命週期」排開。它的守備範圍是同步按鈕（導航、切換）；非同步按鈕的重複提交由 loading + disabled 狀態防守，兩者分工見可觀察訊號段。

兩種執行語意

同一個 debounce 週期有兩個可執行的時間點，選錯會直接改變使用者體感：

• Leading-edge（立即執行）：第一次點擊立即生效，之後一段時間內的點擊忽略。按鈕防連點要用這種 — 第一次點擊本來就該立即回應。
• Trailing-edge（延遲執行）：等一段時間內沒有新觸發才執行。適合搜尋框輸入這類「等使用者打完字再送查詢」的場景；用在按鈕上會給每次操作加上等待週期的延遲，違反點擊確認的 100ms 即時門檻。

導航鎖（in-flight flag）是按鈕防連點的替代做法：操作進行中拒絕新請求、完成後解鎖，不依賴固定時間窗。

Throttle 是近親：固定時間窗內至多執行一次、但持續觸發會持續執行（如捲動事件每 200ms 取樣一次）；debounce 則把連續觸發收斂成一次。防連點用 debounce，高頻連續事件的節流用 throttle。

可觀察訊號與例子

需要 debounce 的訊號是同一個操作被觸發多次的紀錄：導航堆疊被 push 兩層一樣的頁面、後端收到毫秒級間隔的重複請求、表單被建立兩筆相同資料。非同步按鈕通常用 Loading + disabled 防重複提交，debounce 主要負責同步按鈕（導航、切換）— 這些按鈕操作瞬間完成、沒有 loading 狀態可以擋。

設計責任

Debounce 的設計責任是在不犧牲第一次點擊即時性的前提下吸收重複觸發。時間窗常見慣例值是 300ms 上下，依操作型態調整。完整的防連點決策（哪類按鈕用 debounce、哪類用 disabled）見互動回饋三層模型的兩類按鈕段。

觀察

book_overview_app 的匯出設定頁有一顆「確認匯出」按鈕。實機測試按下後畫面無任何變化：沒有 loading、沒有成功訊息、沒有錯誤訊息。使用者無法判斷三種可能中的哪一種成立：匯出已完成、匯出正在執行、按鈕根本沒接線。

翻開程式碼，真相是第三種 — onPressed 是一個空 callback，裡面只有一行 // 導航到進度頁面 註解。而 ViewModel 層的 startExport() 早已具備 idle / inProgress / completed / failed 的完整狀態轉換邏輯，頁面從未呼叫它。

修復只改一個檔案（匯出設定頁），ViewModel 與狀態定義一行未動。

判讀

1. 三層回饋全缺時，「正確的後端」對使用者不存在。回饋是使用者感知系統狀態的唯一通道。點擊確認回答「系統收到了嗎」、等待指示回答「還在跑嗎」、結果通知回答「成功了嗎、檔案在哪」。三層全缺時，使用者只能靠猜 — 而猜的預設答案是「壞掉了」。

2. 缺口在接線、設計本身完備。狀態機四個狀態齊全、retryExport() 都寫好了。缺口是 UI 層留了一行 TODO 式註解就交付。domain 層完備反而讓缺口更隱蔽：單元測試全綠（ViewModel 邏輯正確），widget 測試只斷言畫面渲染，沒有斷言「按下後狀態轉換」，測試體系抓不到這種缺口。

3. onPressed: () {} 是可機械掃描的訊號。空 callback、只含註解的 callback，跟寫了函式沒有呼叫者一樣，是「UI 死路」的字面特徵，grep 就能找到，不需要等實機測試。

策略

1. 三層回饋條款化為驗收標準：每顆觸發非同步操作的按鈕，驗收清單固定三問 — 點擊有確認？等待有指示？結果有通知？本案修復同時把這三層寫進規格（FR-8 補「按鈕層級三層回饋」條款，引用 100ms/400ms/1s 時間門檻），讓後續頁面在設計階段就對照。

2. 接線完整性掃描：交付前 grep onPressed: () {}、onPressed: null（非刻意禁用場景）與只含註解的 callback。UI 接線遺漏跟死程式碼一樣可機械偵測。

3. widget 測試必含行為斷言：每顆按鈕至少一個「tap 後斷言狀態轉換或副作用」的測試，不能只有「按鈕存在且可見」的渲染斷言。本案的 RED 測試（按下確認匯出後狀態非 idle）正是修復前缺失的那一個。

下一步路由

• 三層回饋模型的完整定義 → 互動回饋三層模型
• 非同步按鈕的生命週期設計 → 按鈕狀態設計
• 等待指示的時間門檻 → Doherty Threshold
• 類似案例（回饋誠實但誤導）→ U.C7 商品條碼的誤導性查無結果
• 未接線的另一種形態（刻意佔位）→ U.C20 管理模式操作全是佔位

設計問題

使用者點擊按鈕後，有三個時間點需要回饋：

1. 點擊瞬間 — 系統收到操作了嗎？（點擊確認）
2. 等待期間 — 系統在處理嗎？（等待指示）
3. 操作完成 — 結果是什麼？（結果通知：成功 / 失敗 / 空結果）

缺少任何一層，使用者的反應都是「再按一次」— 導致重複提交、重複導航、重複請求。

「按了沒反應」在案例庫有四種被驗證過的成因，診斷時逐一排除：回饋未接線（U.C5）、佔位 handler（U.C20）、點到的不是按鈕（U.C18）、回饋被版面壓縮（U.C19）。

章節

每篇文末附設計檢查清單，可直接作為 code review 與規格驗收的依據。

模組邊界