觀察

book_overview_app 的掃描器偵測所有 EAN-13 格式條碼。書籍 ISBN-13 一定以 978 或 979 開頭；其他開頭的 EAN-13 是一般商品條碼（飲料、餅乾、日用品）。使用者對準商品條碼掃描時：

修復是一個本地 prefix 檢查：非 978/979 開頭的 13 位條碼不進入 ISBN 驗證與 API 查詢流程，直接顯示本地化提示並停留在掃描狀態。978/979 開頭維持既有流程。

判讀

1. 可本地判定的錯誤該在本地即時回應。「這個條碼是不是書籍 ISBN」是純 prefix 規則，毫秒級本地可判。把它丟給 API 等於用 2 秒網路延遲換一個本來就知道的答案 — 違反回饋時間門檻之外，更浪費了「立即告訴使用者掃錯了」的機會。

2. 「查無結果」誠實但誤導。API 確實查無結果，訊息字面為真。但使用者的歸因是「這本書資料庫沒收錄」，於是重掃、換角度、懷疑 app 壞掉 — 沒有一條路通往真正的解法「去掃書背的 ISBN 條碼」。回饋若不能修正使用者的心智模型，字面誠實沒有價值。

3. 兩種「找不到」是不同的使用者情境，混用同一訊息給錯心智模型。「輸入本身不合法」（掃錯條碼，本地可判）和「輸入合法但查詢無結果」（確實查無此書，需遠端）需要不同的下一步：前者是換條碼，後者是手動輸入或放棄。訊息合併等於系統放棄了它明明有能力做的錯誤分類。

策略

1. 輸入驗證前移：格式與領域規則（長度、prefix、checksum）在送出前本地攔截，遠端只處理「合法輸入的查詢結果」。設計時對每個送遠端的輸入列一張「本地可判定規則」清單。

2. 錯誤訊息以下一步行動為中心撰寫：訊息模板是「發生了什麼 + 該做什麼」（「此條碼非書籍 ISBN，請掃描書背 ISBN 條碼」），不是系統視角的查詢結果陳述。寫完自問：使用者讀完知道下一步嗎？

3. 稽核每個「查無結果」訊息：對既有系統，逐一檢查回「查無結果／找不到」的路徑，問「有沒有本地可判定的原因被混進來」。有，就拆成獨立的即時提示。

下一步路由

• 輸入機制的四維度決策 → 輸入機制設計
• 結果通知屬於三層回饋的第三層 → 互動回饋三層模型
• 類似案例（回饋缺失）→ U.C5 匯出按鈕零回饋