介面會說話：使用者怎麼理解你的文案

「確定」是最忙的按鈕，也是最沒用的

數一數你今天點過多少次「確定」。它出現在刪除、提交、退出、覆蓋、清空的彈窗裡，同一個詞替一百種後果背書。問題就出在這：按鈕自己不帶答案，答案在正文裡，使用者必須讀完整段話，才知道這一下點的是什麼。「確定 / 取消」配對是偷懶，把閱讀成本推給了使用者。

處方是讓按鈕把後果帶在身上：「刪除這 3 條」替掉「確定」，「留著」替掉「取消」。這樣哪怕正文一個字沒讀，掃一眼按鈕也能安全作答。Cooper 在《About Face 4》第 21 章給功能對話框立過同款規矩：標題要用動詞。標題說清在確認什麼，按鈕說清點了會怎樣，兩頭都不讓使用者猜。

「在功能對話框的標題中使用動詞。」
Alan Cooper，《About Face 4》第 21 章：動詞帶著動作和後果，名詞和「提示」什麼都不帶。

這條規矩還有一個測試版本：把彈窗正文遮住，只看標題和按鈕，能不能安全作答。能，文案就合格；要回頭翻正文，就還是「確定 / 取消」的偷懶變體。先看幾組對照，找找動詞按鈕的手感。

場景	偷懶版	攜帶後果版
清空購物車	確定 / 取消	清空 12 件 / 先留著
退出編輯	是 / 否	儲存並退出 / 丟棄改動
解綁手機號	繼續 / 返回	解綁 1382046 / 不解綁

注意「攜帶後果版」的另一個副產品：數量和對象一併寫進按鈕（12 件、138****2046），等於替使用者做了最後一次核對。誤操作大多發生在「我以為選的是另一批」，按鈕把對象報出來，這層誤會當場消解。

使用者的詞，系統的詞

按鈕之外，第二個重災區是名詞。介面上寫著「欄位 user_mobile 校驗失敗」「違反唯一性約束」，這些詞一個使用者都不認識，它們是從資料庫和日誌裡直接端出來的。Cooper 在第 14 章把根子挖了出來：開發者把資料庫的需求放在使用者的需求前面，軟體成了替 CPU 服務的，使用者反倒像在替軟體打工。

第 14 章還有一條被引用得很多的原則：出錯可能不是程式的問題，但是程式的責任。手機號少一位、使用者名稱重複，都算使用者的「錯」，但把錯誤翻譯成使用者聽得懂、改得動的話，是程式分內的事。連選單名都逃不過這條：Cooper 認為「檔案」這個選單名都是實現模型的詞，發票應用的選單就該叫「發票」，使用者管自己的東西叫什麼，介面就叫什麼。

系統的詞	它其實想說	病根
此操作無法撤銷	「此操作」指哪個操作？說出來	系統視角的指代，使用者要自己回憶上一步
Error 422	哪裡填得不對、怎麼改	HTTP 狀態碼是寫給開發者的日誌（第 2 節的病歷）
Session 已過期	登入過期了，重新登入就行	Session 是實現模型的詞，使用者的詞是「登入」

AI 寫介面時特別容易犯這個病：它對著資料結構生成文案，欄位叫什麼，標籤就叫什麼。你不攔，資料庫就直接上臺演講。下面動手改一個彈窗，三處文案逐條換成人話，看 mock 當場變樣。

動手 · 改寫一個彈窗，mock 即時變

左邊這個刪除確認彈窗出自 AI 產出的真實水平：標題「提示」、正文含糊、按鈕「確定 / 取消」。右邊三處逐條點「說人話」，每改一處，彈窗當場更新，三處全改完再做遮正文測試。

按鈕文案改寫器改寫 0 / 3

場景：使用者勾了 3 封郵件點刪除。點右側每條的「說人話」，左邊彈窗即時變

mail.example.com/inbox

提示

確定要執行此操作嗎？此操作無法撤銷。

取消確定

標題提示說人話 →

刪除這 3 封郵件？

「提示」零資訊量。功能對話框標題用動詞（第 21 章），動作和數量都擺進標題，使用者第一眼就知道在確認什麼。

正文確定要執行此操作嗎？此操作無法撤銷。說人話 →

刪除後會進「已刪除」，保留 30 天，之後才永久消失。

「此操作」是系統視角的指代，使用者要自己回憶剛才點了什麼。正文該交代的是後果的細節：東西去哪了、留多久、還救不救得回。

按鈕取消 / 確定說人話 →

留著 / 刪除這 3 封

「確定 / 取消」把答案全押在正文上。按鈕攜帶各自的後果，危險的那顆換成紅色，正文一個字不讀也不會點錯。

對決 · 哪個彈窗更危險

危險的定義先說清：使用者沒讀懂也會點下去的那種，才叫危險。上一節的狼來了實驗演過，使用者處理彈窗的平均耗時讀不完一行字，文案模糊的彈窗等於在盲點裡放了一把刀。下面兩個彈窗都在刪客戶資料，點你敢把使用者交給的那個。

模糊文案 vs 明確文案 A/B 對決

點你敢把使用者交給的那個，投完揭曉另一個危險在哪

方案 A

crm.example.com/customers

警告

此操作將影響所選資料，確定要繼續嗎？

取消確定

影響什麼資料、影響成什麼樣，全靠使用者腦補

方案 B

crm.example.com/customers

刪除這 3 位客戶？

會同時刪除他們名下的 24 條跟進記錄。刪除後 30 天內可以在回收站找回。

留著刪除這 3 位

對象、連帶後果、退路，三樣都寫在明面上

動手 · 把系統語翻譯成人話

按鈕練完練名詞。下面五條都是 AI 愛直接端上介面的系統語，每條從兩個翻譯裡挑出真正的人話。小心，有個別選項只是把系統語打扮了一下，骨子裡還是日誌。

系統語翻譯題 0 / 5

每條選一個翻譯，選錯有解釋，可以再選

DB_CONN_TIMEOUT

A資料庫連線超時（錯誤碼 10060），請稍後重試。

B剛才沒連上伺服器，你寫的內容已存在本機，網路恢復後會自動重試。

打扮過的系統語。「資料庫」「錯誤碼」還是實現模型的詞，使用者不關心哪個環節超時，關心的是我的東西丟沒丟、接下來要不要管。

對。隻字不提資料庫，先交代使用者最怕的事（內容沒丟），再交代要不要行動（不用管，會自動重試）。技術故障自己消化，這是第 2 節三要素的名詞版。

欄位 user_mobile 校驗失敗

A手機號少了一位，現在是 10 位，補上就能提交。

B手機號格式不合法，請檢查後重新輸入。

對。user_mobile 翻成「手機號」只是及格線，說出「少了一位」才算把校驗結果翻譯完，使用者不用數就知道怎麼改。

「不合法」加「請檢查」，等於讓使用者自己當校驗器再跑一遍。程式明明知道差在哪，說出來是它的責任（第 14 章）。

Session 已過期，Token 失效

A會話憑證已失效，請重新獲取訪問令牌。

B登入過期了，重新登入就能接著編輯，草稿已經保留。

把 Session 翻成「會話憑證」、Token 翻成「訪問令牌」，詞是中文了，模型還是實現模型。使用者的詞典裡只有「登入」。

對。使用者的詞（登入）、明確的出路（重新登入）、最要緊的安撫（草稿還在），一句話三件事全辦了。

404 Not Found: /orders/8291

A請求的資源不存在，請確認地址是否正確。

B這筆訂單找不到了，可能已被撤銷。去「全部訂單」裡看看，或者聯絡客服幫你查。

「資源」「地址」都是 HTTP 的詞。使用者點的是一筆訂單，他的世界裡沒有資源，只有訂單。

對。用使用者的詞（訂單）說清現狀，給兩條出路（去列表、找客服）。404 這種死胡同頁面，出路比解釋更值錢。

該操作違反唯一性約束

A這個使用者名稱已經有人用了，換一個試試，比如加個數字。

B資料重複，操作被拒絕，請修改後重試。

對。「唯一性約束」是資料庫給自己立的規矩，使用者眼裡這件事叫「名字被人佔了」。順手給條建議（加個數字），把死胡同變成岔路口。

「資料重複」比「唯一性約束」好懂一點，但哪個資料重複、跟誰重複、怎麼辦，一個都沒說。翻譯要翻到使用者能行動為止。

錯誤資訊三要素，第 2 節講過了

聊到這裡你可能想起第 2 節的錯誤文案改寫器：發生了什麼、為什麼、怎麼辦。那套三要素管錯誤資訊的骨架，這一節管的是骨架裡每個詞的選法，兩邊拼起來才是完整的文案功。三要素不重教，跳轉卡在這。

本章引用 · 狀態三件套：loading、空態、錯誤態錯誤資訊三要素（發生了什麼、為什麼、怎麼辦）和三條弱文案的完整改寫，第 2 節講透了，點這裡跳過去。

最後一道綜合題，把這一節的按鈕功和上面的三要素合在一起考。

關檔案時還有改動沒儲存，按鈕組怎麼配單選

選錯也有解釋，選到對的為止

A「確定 / 取消」，正文寫明會丟失未儲存的改動

B「儲存並關閉 / 不儲存 / 取消」，三顆按鈕各帶後果

C「是 / 否」，正文問「要儲存嗎？」

D「知道了」，告知改動將丟失

本節要點

✓

按鈕攜帶後果：「刪除這 3 條」替掉「確定」，「留著」替掉「取消」。驗收標準：遮住正文只看標題和按鈕，還能安全作答。

✓

用使用者的詞：Session、欄位名、錯誤碼都是實現模型的詞，別端給使用者（Cooper，《About Face 4》第 14 章）。翻譯要翻到使用者能行動為止。

✓

出錯是程式的責任：使用者的輸入可以有錯，把錯講成聽得懂、改得動的話，是程式分內的事。措辭不責備使用者，三要素骨架在第 2 節。

✓

給 AI 提需求的話術：「按鈕文案寫明動作和數量，禁用『確定 / 取消』配對；介面文案禁止出現欄位名、錯誤碼、Session 等系統詞」。介面細節到此講完，下一節開始把這些要求翻譯給 AI 聽。

內容來源：小山學堂「互動工程」專題原創；部分互動原則整理自《About Face 4：互動設計精髓》。