本篇文章主要針對幾組比較容易混淆的按鈕文案進行對比說明，以區分它們之間的不同和釐清各自適合的使用場景。
我們在各種作業系統、各種應用程式的彈窗上可以見到多種多樣的文案，比如「確定」、「確認」、「提交」、「發送」、「發布」、「保存」等等。有時候我們在設計產品的彈窗時，自己也會偶爾拿不準在某個場景下，究竟應該在操作按鈕上使用什麼文案來準確符合當前場景要求，避免歧義。
彈窗按鈕文案
所以，我綜合整理了一下彈窗按鈕上經常使用的一些基本文案，並分析了各自的使用場景，希望能夠拋磚引玉，查漏補缺。
這些按鈕文案可以有多種分類方法，如按照最早的Alert、Confirm、Prompt方法來分的話，可以分為：
單純的信息已讀確認帶有法律責任的籤署同意某項操作的開關將附加信息保存 而這些按鈕一般都會附帶解散彈窗的附加功能。
除此之外，對於非單純信息確認型的彈窗，如果用戶不想執行某項操作，可以用「取消」按鈕可以只解散彈窗而阻止後續操作繼續進行。
我把所有常用的表單按鈕文案進行了整理和羅列，並把使用場景和功能也一一列出：
表單按鈕文案列表（點擊查看大圖）
以上這些表單按鈕文案基本涵蓋了普通的彈窗按鈕文案，當然運營彈窗和明確操作目標的按鈕除外，在運營按鈕上文案是比較自由的，而在明確操作目標的按鈕上，可以直接把要做的操作如「渲染」、「運行」、「中斷」等操作目標直接標註上去。
上一篇文章把彈窗按鈕主要使用的文案以及使用場景和作用進行了羅列，本篇文章主要針對幾組比較容易混淆的按鈕文案進行對比說明，以區分它們之間的不同和釐清各自適合的使用場景。
一、「好的」 vs. 「我知道了」
「好的」和「我知道了」使用的場景並沒有非常顯著的區別，所以這兩個按鈕文案的使用經常容易被混淆，但仔細思考還是能發現兩者之間的不同點：
好的vs.我知道了
a. 使用「我知道了」按鈕時系統傳遞的信息的正式程度和重要程度比使用「好的」時更正式，更重要，如系統重要通知、系統發放的優惠券等等，適合用「我知道了」。
b. 用戶在面對「好的」按鈕時，對系統信息的重要程度的心理預期比「我知道了」要低很多。因為相較於「好的」的隨意，「我知道了」更接近一種契約，一種承諾，用戶會有一種在點擊「我知道了」按鈕時，系統拿到了「用戶已閱」回執的心理模型，雖然系統並沒有這麼做。
我知道了更正式
c. 「好的」一般也用於有前置操作的後續反饋，如前面的操作導致了彈窗結果，而用戶對於前面的操作導致的彈窗結果有一定心理預期。而「我知道了」更適合於在沒有用戶前置操作的情況下重要的系統信息。
好的 vs. 我知道了
所以，設計者在設計無後續操作的Alert彈窗時，需要衡量所傳遞給用戶的信息的重要性。對於那些非常重要的需要用戶仔細閱讀的信息，可以使用「我知道了」來增加對信息重要性的暗示和用戶的心理預期，但也要注意不要濫用。
二、「確認」 vs. 「確定」
在彈窗設計時，「確認」和「確定」是比較容易被混淆的兩個按鈕文案，兩者都可以和「取消」按鈕組成二選一的按鈕組合，所以很多產品設計者容易分不清兩者之間的差別而亂用，從而造成對用戶認知的負擔。
確認 vs. 確定
a. 在Confirm彈窗場景中，「確定」對應的場景是用戶進行了某項「刪、改」這個層級的不可逆操作，但這種操作只涉及某條信息的修改、刪除、狀態永久改變等變化，並沒有提交更多附加信息到伺服器。
「確認」對應的場景是用戶在前置場景中進行了配置、選擇、信息填寫等操作，在點擊提交按鈕時，系統用Confirm彈窗進行二次確認，此時需要用戶意識到自己附加的信息會改變系統狀態。
在Confirm彈窗裡「確認」和「確定」
b. 在「排序」、「篩選」等側邊彈窗場景裡，用戶雖然在選擇Action按鈕前執行了很多操作配置，但此時並不是二次確認彈窗，所以此時更適合用「確定」按鈕來執行當前選擇。
c. 表單頁的Aciton按鈕可以使用「確定」，此時用「確定」比「提交」按鈕應用場景的普適性更佳。
表單Action按鈕更適合用「確定」
所以，「確定」按鈕一般來說，適用範圍和場景比「確認」要多，「確認」現在更多的使用場景是配合主Action動作一起組合使用。這時候，「確認提交」、「確認還款」就比「確定提交」、「確定還款」語境和語氣更佳合理。
最後，很多時候在有些場景裡，使用「好的」比使用「確定」更加合理。
有些場景「好的」更加合理
接上文，繼續來看一下其他容易被混淆使用的彈窗按鈕文案。
三、「保存」 vs. 「完成」
「保存」和「完成」按鈕，在實際使用中也是比較容易被混淆的一對。
保存vs. 完成
一般來說，「保存」更適合用於用戶認為信息存儲於本地的各類信息的Action按鈕。雖然這些信息也會被同步提交到伺服器，但在用戶的心智模型裡，這些信息是在用戶客戶端存在的，可以被離線查看和使用的（只是用戶心智模型，而非工程實現模型，實際可能不能離線查看）。
保存按鈕
而「完成」主要是用於用戶心智模型認為所做的操作是做出了選擇，而這些選擇的結果影響的是客戶端的顯示，而非永久性地改變當前操作文件本身。
完成按鈕的使用
我們知道，工程實現模型是要符合用戶心理預期，符合用戶的心智模型，所以「完成」按鈕一般的使用場景應該是用於那些選擇或編輯操作不會對編輯範圍產生永久性影響的場景。
如群組搜索範圍，如電商的購物車內容，編輯購物車內的物品，並不會對這些SKU本身產生任何永久性影響，此時如果使用「保存」按鈕而非「完成」按鈕，就會產生一定的場景錯置感，用戶在點擊「保存」按鈕時就會產生微妙的猶豫和和不確定感。
而在那些需要用「保存」來保護用戶編輯的內容，使之產生安定感降低焦慮的場景中，如果錯用「完成」，也會對用戶心智模型帶來一定的衝擊和影響。這種影響是非常細微的甚至是難以量化的，但在這些場景中，使用「保存」應比「完成」能帶來更多確定性，降低認知成本。
比較典型的如iOS系統的圖像、通訊錄編輯後Action按鈕和知乎的個人信息Action按鈕，個人認為在這些Action按鈕使用時「保存」比「完成」更符合場景要求和用戶心智模型。
在某些場景下，「完成」是否符合用戶心理預期？
iOS在某些場景中，如拍照和截屏，用「Done」按鈕來完成一個使用場景，在這些使用場景中，用戶可能會附加編輯，也可能不會。所以這些場景中「Done」是涵蓋了「Save」的使用場景的，但這也就導致了iOS系統在某些場景下「Done」的濫用，這也是產品在做Localization工作時需要注意的問題。
iOS在某些場景下把「保存」合併到「完成」裡
四、「提交」vs.「發送」vs.「發布」
接下來，再來討論一下幾個跟問卷、交流、用戶反饋、用戶評價、社區等相關度較高的按鈕文案。
這幾個按鈕文案分別是：「提交」、「發送」、「發布」。
「提交」「發送」「發布」
在使用「提交」作為彈窗按鈕文案時，適用的場景主要包括彈窗本身自帶表單的，同時將用戶編輯的信息單向傳送至伺服器或服務中心進行審核等情況。不是說在這些場景下伺服器或服務中心不會對用戶提交行為進行反饋，而是這種反饋是異步（asynchronism）的，或有一定選擇的。
「提交」文案使用場景
「提交」按鈕文案的用戶的心智模型如下圖所示：
提交心智模型
在使用「發送」作為彈窗按鈕文案時，適用的場景是一種平等的交流場景，或期待對方能快速給出反饋的情況。
雖然發送後接收方不會做出必然反饋或快速反饋的承諾，但用戶的心智模型相比「提交」而言，是在期待一種更快速，更及時的回覆的。有些意見反饋頁為了增加即時性的感覺，甚至把反饋界面設計成聊天界面以緩解用戶期待反饋是的焦慮感，提升用戶體驗。
「發送」應用場景
「發送」按鈕文案用戶的心智模型圖如下：
發送心智模型
所以相較於「提交」，使用「發送」在某些場景下，如提交問題反饋時，可以起到適當減輕用戶等待焦慮，減少跳出率等作用。但前提是要提高客服反饋的速度以及每件必復，以符合用戶的心理預期，如果提供的反饋非常慢或者是選擇性回復，就不能用「發送」按鈕文案。
至於「發布」這個彈窗按鈕文案，一般不會在前面兩種應該使用「提交」和「發送」按鈕文案的場景中被混用。因為發布的使用場景範圍比較窄，一般用戶用戶填寫的信息發布於公共區域，且用戶在點擊這個按鈕的同時，認可系統的這種行為。
蘋果撰寫評論用「發送」不合理
其實目前在網際網路行業，為了防止垃圾信息營銷或不良信息控制或敏感信息控制，發布的內容需要人工審核或機器人審核後才顯示也基本成為了標配。這時候彈窗按鈕的文案究竟應該是「發布」還是「提交」（儘量不要使用「發送」），就需要看場景需要了。
在某些場景下，如果系統想要減少或消除用戶對於發布信息需要審核這個行為的感知，就應當使用「發布」按鈕。有些系統在同時還會在本地生成用戶提交信息的「鏡像」出現在發布區域，但實際上該信息僅發布用戶可見，真正的用戶的發布信息還在伺服器端等待審核，但通過這些方式可以緩解用戶焦慮，提升產品使用的劉暢感。
如果系統想要明確告知用戶發布的信息需要系統進行審核後才能顯示，且這種審核可能是異步的，或發布的內容可能是選擇性的。那麼，此時就適合使用「發送」按鈕以用文案的方式對審核行為進行暗示和隱喻。但這種場景一定是非常少的，所以這種使用要比較謹慎。
以下例子的使用文案就存在明顯問題：
「提交」使用場景不符
這幾個按鈕文案因為使用場景近似，所以在有些情況下經常容易被混用，釐清了各自不同的使用場景，就可以用來作為今後彈窗按鈕文案規範的指導，至少在使用類似文案時，可以多問自己一句：「這個文案有歧義嗎？」
五、「放棄」vs.「撤銷」vs.「取消」
最後的也是最重要的，是一組比較有消極色彩的Action按鈕，它們是「放棄」、「撤銷」和「取消」。
「放棄」、「撤銷」、「取消」彈窗按鈕的場景作用
在彈窗場景中，這幾個按鈕文案有很多時候被混淆使用了，甚至有時候因為文案的含混不清而導致用戶操作失誤，可能會造成比較大的用戶體驗問題。
首先來釐清三者不同的使用場景：
1. 撤銷
「撤銷」適用於用戶已經提交或提交待審核的操作的撤回操作，此操作在彈窗提示確認之前已經發生。確認彈窗是在用戶需要進行撤回這個操作時發生的，有彈窗二次確認本身就說明這個操作比較重要，如果用戶撤銷，會回到用戶提交操作之前的狀態。
「撤銷」操作的使用場景
2. 放棄
「放棄」適用於用戶正在某個分支場景編輯信息，用戶放棄會返回主流程而用戶在分支場景裡所做的一切操作和信息輸入都不會被保存。
「放棄」操作的使用場景
放棄操作因為會將用戶當前支路上填寫的信息全部清空，所以一定要定義清晰，且最好在彈窗提示文案上，也明確告知用戶這樣的放棄操作可能會帶來的後果，讓用戶對自己的行為的後果有明確的心理預期。
3. 取消
「取消」這個彈窗按鈕文案能且只能用於解散當前彈窗且不附帶其他附加操作這樣的使用場景，只有明確清晰定義了這樣的使用方式，才能最大程度上減小用戶認知負擔，增加任務明確性。
日常互動設計中最經常遇到的就是「放棄|撤銷」和「取消」兩者之間的使用不規範從而導致的問題，我曾經見過如下的取消當前操作彈窗按鈕文案，導致我完全無法確定按鈕後續的動作：
「取消」文案不恰當使用
這是最最嚴重和極端的一種錯誤使用方式。
比這種使用方式稍微好一些的使用方式可能也意識到用「取消」作為主Action的按鈕來執行一個撤銷或放棄行為天然會和作為解散彈窗而存在的「取消」衝突，從而把作為解散專用的「取消」用「再想想」來替代。
這樣的確會減少一些認知成本，但為什麼不從一開始就規範「取消」的使用場景呢？
「取消」被誤用的場景
所以，這種需要撤銷一個已執行操作行為的場景下，把「撤銷」文案錯用為「取消」，就會帶來一些用戶使用上的困擾。
所以，將每個彈窗按鈕文案的使用場景和適用範圍都明確清晰地定義清楚，並在互動設計中一以貫之地執行這樣的規範，就能最大程度上減少用戶誤解，增加界面易用性。
（全文完）
本文由 @德升 原創發布於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議