U.C7 商品條碼的誤導性查無結果 — 可本地判定的錯誤讓使用者白等 API

2026-07-16

book_overview_app 是一個 Flutter 書庫管理教學專案，以下案例取自該專案的實機測試。錯誤回饋的責任是回答使用者下一步該做什麼——一個字面誠實的訊息，若把可本地判定的輸入錯誤混進「查無結果」，就是誤導。

觀察

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

項目	修復前	修復後（W1-089）
判定位置	送 Google Books API 遠端查詢	`IsbnValidationService.isBookIsbn()` 本地判定 prefix
等待時間	2 秒以上	即時
回饋訊息	「查無結果」	「此條碼非書籍 ISBN，請掃描書背 ISBN 條碼」
使用者理解	「這本書資料庫沒有」（錯誤歸因）	「我掃錯條碼了」（正確歸因）＋知道下一步
掃描狀態	中斷	維持掃描中，對準正確條碼即續掃

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

可本地判定的錯誤該在本地即時回應。「這個條碼是不是書籍 ISBN」是純 prefix 規則，毫秒級本地可判。把它丟給 API 等於用 2 秒網路延遲換一個本來就知道的答案 — 違反回饋時間門檻之外，更浪費了「立即告訴使用者掃錯了」的機會。
「查無結果」誠實但誤導。API 確實查無結果，訊息字面為真。但使用者的歸因是「這本書資料庫沒收錄」，於是重掃、換角度、懷疑 app 壞掉 — 沒有一條路通往真正的解法「去掃書背的 ISBN 條碼」。回饋若不能修正使用者的心智模型，字面誠實沒有價值。
兩種「找不到」是不同的使用者情境，混用同一訊息給錯心智模型。「輸入本身不合法」（掃錯條碼，本地可判）和「輸入合法但查詢無結果」（確實查無此書，需遠端）需要不同的下一步：前者是換條碼，後者是手動輸入或放棄。訊息合併等於系統放棄了它明明有能力做的錯誤分類。

輸入驗證前移：格式與領域規則（長度、prefix、checksum）在送出前本地攔截，遠端只處理「合法輸入的查詢結果」。設計時對每個送遠端的輸入列一張「本地可判定規則」清單。
錯誤訊息以下一步行動為中心撰寫：訊息模板是「發生了什麼 + 該做什麼」（「此條碼非書籍 ISBN，請掃描書背 ISBN 條碼」），不是系統視角的查詢結果陳述。寫完自問：使用者讀完知道下一步嗎？
稽核每個「查無結果」訊息：對既有系統，逐一檢查回「查無結果／找不到」的路徑，問「有沒有本地可判定的原因被混進來」。有，就拆成獨立的即時提示。