概念位置

Affordance 在互動發生之前起作用 — 互動回饋三層模型管「操作之後系統怎麼回應」，affordance 管「操作之前使用者怎麼知道能操作」。兩個方向的錯位各自成類：暗示了但做不到（視覺像按鈕的狀態圖示、看似整行可點的列表行）、做得到但沒暗示（可捲動清單無捲動提示、隱藏手勢）。與 Touch Target 的分工：affordance 管「看起來能不能操作」、touch target 管「可操作範圍與尺寸是否足夠」。

可觀察訊號與例子

需要檢查 affordance 的訊號是使用者回報「按了沒反應」或「找不到功能」、而程式行為正確。實戰案例：狀態圖示與動作按鈕同形混排、被當成壞掉的按鈕（U.C18）；水平篩選列可捲動但無提示、截斷被讀成被遮蔽（U.C16）；整行反白暗示可點、gesture 只掛在尾端箭頭（U.C8）。

設計責任

Affordance 的設計責任是讓「看起來能做的」與「實際能做的」一致：可互動元素帶明確的互動形態（按鈕容器、ripple）、非互動指示用明顯非按鈕的形態、隱藏的能力（捲動、手勢）補可見提示。審查問句：這個畫面上哪些元素可互動，使用者分得出來嗎？

觀察

書庫管理 app 的篩選列有四顆 FilterChip（我的書庫 / 電子書 / 實體書 / 借閱書籍）加一顆重新整理鈕。版面實作（library_display_extensions.dart:191-219）：同一個 Row 內，chips 包在 Expanded > SingleChildScrollView(horizontal)、重新整理鈕固定在 Row 尾端 — 程式上沒有重疊，chips 可水平捲動。

驗收的讀法完全不同：第四顆 chip 在捲動視窗邊緣被截斷、位置緊貼重新整理鈕，被回報為「篩選按鈕被重新整理按鈕遮蔽」。實作正確、感知錯誤 — 捲動視窗沒有任何 affordance（無漸層遮罩、無箭頭、截斷位置又剛好貼著一顆固定元件），截斷被歸因成遮蔽。

判讀

1. 截斷的預設讀法是「壞了」、不是「可以捲」。使用者知道可以捲動的前提是畫面給了提示：邊緣漸層遮罩、下一個項目部分露出（刻意讓截斷停在半顆的位置）、方向箭頭。四顆 chip 剛好在視窗邊緣切齊或貼著固定鈕截斷時，連「有更多內容」的訊號都消失。

2. 截斷位置緊貼固定元件會製造錯誤歸因。可捲動區域與固定按鈕同列時，截斷發生在兩者交界 — 使用者看到的是「chip 被 refresh 鈕壓住」。可捲動與固定元件的視覺分隔（間距、分隔線、遮罩）是同列混排的必要配套。

3. 選項少時溢出本身可以被消除。四個篩選選項在多數螢幕寬度下接近放得下 — 換行 wrap、縮短文字、或改成下拉選單 / bottom sheet 都能根本消掉溢出，比補 affordance 更省。溢出處理的選擇順序：先問「能不能不溢出」、再設計溢出的可見性。

4. 驗收者的誤讀本身是訊號。「實作沒有 bug」不能關閉這個 finding — 感知層的錯誤歸因就是 UX 缺口，修的是 affordance、不是修驗收者的理解。

策略

1. 水平清單檢查一句：最後一個項目被截斷時，畫面給了什麼「還有更多」的提示？沒有提示就補（漸層 / 半顆露出 / 箭頭 / 捲軸指示 / 溢出計數）或消除溢出（wrap / 選單）。

2. 可捲動區與固定元件同列時加視覺分隔，截斷邊緣與固定元件之間保持可辨識的間距。

3. 驗收在窄幕裝置跑 — 溢出類問題在寬幕開發機上經常不出現。

下一步路由

• 溢出 affordance 與元件語意的章節整理 → 按鈕狀態設計
• 同一條篩選列的選中態對比問題 → U.C17 選中態換底色不換文字色
• 同構案例（視覺暗示與實際行為錯位）→ U.C8 標籤行只有箭頭可點

觀察

書庫管理 app 書卡的 trailing 區（列表項尾端的元件區）是一個 Row 三格（library_display_extensions.dart:432-448）：

驗收回報兩件事：「右邊兩個按鈕的圖示重複了」「最右邊的按鈕點了沒反應」。程式碼事實：中格是描邊 menu-book 的按鈕、右格是實心 menu-book 的狀態圖示（實體書的來源標記）— 描邊與實心的差異太細，兩者被讀成重複的兩顆按鈕，其中一顆「壞了」。

管理模式下右格換成 Checkbox — 選取控制與兩顆動作圖示混排在同一個 trailing 列，不是獨立的勾選欄。驗收另回報「勾選框沒有靠右對齊」；程式上 checkbox 恆為列末位、緊貼 trailing 邊界，視覺上不靠右的成因（padding / 卡片內距）待 app 端重查 — 混排本身則是可確認的設計層議題。

判讀

1. 同列混排讓可點性預設擴散。一列裡有兩顆按鈕時，使用者掃視的預設是「這一列是動作區、全部可點」— 混進去的狀態指示自動繼承這個預設。指示「沒反應」不會被讀成「這是標記」，會被讀成「按鈕壞了」（體感等同 U.C5 匯出按鈕零回饋）。

2. 描邊 vs 實心不是可靠的互動性訊號。同一個圖形的 outline / filled 變體在小尺寸下幾乎不可分，而且業界對「哪個代表可點」沒有慣例。可點性要用更強的形態訊號：按鈕容器（邊框 / 底色 / ripple）、或把指示改成明顯非按鈕的形態（文字 chip、彩色圓點）。

3. 圖示語意撞名是第二層問題。中格按鈕的 menu-book 圖示想表達「查書籍資料」、右格指示的 menu-book 想表達「實體書」— 同一個圖形承載兩個語意，即使解決了可點性、語意混淆仍在。圖示選擇要全畫面去重。

4. 選取控制與動作按鈕混排增加誤觸成本。批次勾選的操作是「沿一條垂直線往下點」— checkbox 與兩顆動作圖示同列時，勾選目標緊鄰著會觸發導航或 bottom sheet 的按鈕，動線上每一步都帶著誤觸風險。獨立成與動作列分開的勾選欄，批次動線才乾淨。

策略

1. 審查每一列混排的元件問一句：這一列哪些可點、哪些不可點，使用者分得出來嗎？分不出來就把指示改形態（文字 chip / 圓點）或移出動作列。

2. 圖示全畫面去重：同一個圖形只承載一個語意；狀態指示與動作按鈕禁用同形圖示。

3. 選取控制（checkbox）獨立成與動作列分開的固定欄（LTR 慣例放尾端、iOS 編輯模式放前端 — 關鍵是單一對齊軸、不是左右），不與動作圖示混排 — 對齊軸就是批次操作的動線。

下一步路由

• 鏡像案例（可點範圍小於視覺暗示）→ U.C8 標籤行只有箭頭可點
• 按鈕的可辨識性要求 → 按鈕狀態設計
• 工具列上的標籤語意歧義 → U.C15 切換按鈕標籤被讀成當前狀態