按鈕，無論是在 Web 還是 App 上都被廣泛地使用，而很少有設(shè)計師會注意到按鈕當(dāng)中的細(xì)節(jié)，導(dǎo)致在設(shè)計過程中出現(xiàn)一些低級的錯誤，使得用戶在完成任務(wù)的過程中產(chǎn)生阻礙，無法順利達(dá)成目的。
在許多優(yōu)秀的產(chǎn)品中，關(guān)于按鈕的設(shè)計已經(jīng)有了一套相應(yīng)的規(guī)范去執(zhí)行。作為設(shè)計師，應(yīng)該總結(jié)這些規(guī)范，并產(chǎn)出一套適用于自家產(chǎn)品的設(shè)計規(guī)則。這也是我寫「按鈕規(guī)范」系列文章的目的。
今天主要先與各位聊聊「取消按鈕」的設(shè)計思路。
關(guān)于「取消」，大多數(shù)人對其理解還停留在 PC 端，認(rèn)為「取消」的目的就是讓用戶停止操作上的流程。但時至今日，「取消按鈕」的設(shè)計已經(jīng)有許多解法與思路，如果不仔細(xì)研究與分析，可能會忽略一些用戶行為上的細(xì)節(jié)。
所以我們從下面三個大點來聊聊「取消按鈕」的設(shè)計：
-
按鈕中的「召喚行為」（理清按鈕設(shè)計的概念）
-
其背后的控制權(quán)（關(guān)于按鈕的權(quán)重信息）
-
「取消按鈕」的正確解法（重點）
按鈕中的「召喚行為」
通常，我們在產(chǎn)品中會為了達(dá)成某種指標(biāo)，需要在界面上引導(dǎo)用戶去完成我們希望其完成的操作。且這類操作是可以達(dá)成某種目的的，我們把這類操作稱為「召喚行為」，即從元素的角度引導(dǎo)用戶完成任務(wù)。
這類「召喚行為」最常出現(xiàn)的，是在按鈕設(shè)計的過程中。
用戶如何將元素理解為按鈕？就是通過對形狀和顏色的控制，使該元素看起來像一個按鈕。
它唯一的作用就是讓用戶點擊，并且是主動讓用戶點擊。
我們經(jīng)常在各類設(shè)計中見到這樣的按鈕設(shè)計，或許還有更多樣式，如：
它們的目的一致，都是召喚用戶進(jìn)行點擊，至于類型的選擇一般根據(jù)功能界面的上下文情況進(jìn)行判斷。
其重要程度也是以此順序排列：凸起 > 扁平 > 邊框 > 文本。
這類設(shè)計的結(jié)果就是：無需讓用戶思考要點哪里，而是直接判斷下一步是否進(jìn)行。幫助用戶簡化一個思考點。
注：因為判斷是否進(jìn)行的操作還取決于功能本身以及文案的提示，與我們今天要聊的不是一回事。所以我們跳過這塊，直接聊「召喚行為」與「取消按鈕」的關(guān)系。
這段內(nèi)容各位只要記?。?strong style="outline:0px;margin:0px;padding:0px;">按鈕的行進(jìn)與回退，基本遵循「召喚行為」的思路來設(shè)計。
這個概念知道了，我們就可以對后面的內(nèi)容繼續(xù)進(jìn)行拆解了。
背后的控制權(quán)
接下來我們從多個角度來挖一下「取消按鈕」的設(shè)計，分析其不同地位。
a. 安全性后退
「取消」在多數(shù)情況下，意為安全性地后退，并將界面恢復(fù)到原有的內(nèi)容上，不對界面與功能本身造成破壞，防止對系統(tǒng)進(jìn)行不必要地更改的「安全措施」。
所以正常來說，「取消按鈕」不是「召喚行為」。以至于通常在設(shè)計上會被弱化，以表示該按鈕在功能的流程中，不是主要的，且是提供給用戶作為回退余地的操作。
如：
在這張圖里，「登錄」是「召喚行為」，所以突出顯示。根據(jù)風(fēng)格定義，用了扁平按鈕。而取消在這個場景里屬于「安全性后退」的操作，于是將其弱化。
這是多數(shù)產(chǎn)品采用的設(shè)計方式。
比如美團(tuán)的這個頁面：
產(chǎn)品希望用戶登錄，就會強(qiáng)化「登錄」行為的按鈕，弱化「回退」行為的按鈕。
同樣，我們在微信朋友圈的設(shè)計里也能見到這樣的設(shè)計：
我們總是希望用戶持續(xù)操作下去，但也要給用戶提供回退的行為，所以在這些設(shè)計中，「取消按鈕」會被弱化，「行進(jìn)按鈕」會被強(qiáng)化，因為「取消按鈕」在這里不是產(chǎn)品人員期望的「召喚行為」。
這是一直以來的設(shè)計共識，但如今也發(fā)生了些許變化?！溉∠粹o」也開始具備「召喚行為」的屬性。
b. 強(qiáng)化「取消按鈕」
當(dāng)我們不希望用戶退出某個界面，或停止某個流程時，往往會選擇將「取消按鈕」強(qiáng)化。
如：
或：
通過對字體的加粗，以暗示用戶不要輕易退出。在這個流程里，「取消按鈕」具備了「召喚行為」屬性。
也有產(chǎn)品通過改變「取消按鈕」的文案，讓其具備「召喚行為」的屬性，使得用戶在此過程中輕易不要退出該流程：
這里的「繼續(xù)選座」就是「取消」，因為這里的「取消」成了「召喚行為」，所以通過改變文案的方式，確保用戶留下來繼續(xù)進(jìn)行流程中的任務(wù)。
但是不可取的是，這里的「返回」反而給了用戶一種需要思考的壓力。返回？是留在這里，還是退出去？思考幾秒后，反應(yīng)過來，是退出去。這樣的文案與只有在看到「繼續(xù)選座」后進(jìn)行對比，才能反應(yīng)過來具體是什么意思，除非是用戶具備操作習(xí)慣，知道「右邊」是「行進(jìn)」操作，才能很快理解。（當(dāng)然還有個問題，我們在第三各模塊來說明）
但是多數(shù)用戶還是得思考一下，所以要改，最好兩者文案都能改了，否則思考的「停頓」會讓用戶產(chǎn)生厭惡感。
且在一些產(chǎn)品界面里，為了避免用戶在流程中終止行為，甚至?xí)D(zhuǎn)移「取消」與「行進(jìn)」兩者的位置，如：
之前截圖了某個產(chǎn)品的界面，寫文這天發(fā)現(xiàn)已經(jīng)改回來，這里就沒放了。
各位謹(jǐn)記，最好不要這樣進(jìn)行設(shè)計，因為用戶在 App 的操作上已經(jīng)習(xí)慣左邊取消，右邊行進(jìn)，調(diào)換位置雖然能暫時解決用戶的退出行為，但容易產(chǎn)生誤操作，與用戶的期望不同，導(dǎo)致在產(chǎn)品體驗上會被用戶排斥。
所以到這里，先給一個結(jié)論，即在 App 的設(shè)計上，行進(jìn)操作在右，回退操作在左，召喚屬性根據(jù)場景對按鈕做突出處理。
但是「取消按鈕」真的應(yīng)該具備召喚屬性么？不著急，我們第三模塊再細(xì)聊。下面我們先聊聊 Web 與 App 的之間的差異。
c. Web 與 App 的位置差異
我們現(xiàn)在見到越來越多的 Web 端產(chǎn)品，也開始遵循 App 產(chǎn)品的設(shè)計，把「取消按鈕」放在左邊，「召喚行為」按鈕放在右邊。
但在早期，Web 的「取消按鈕」基本是放在右邊，原因是鼠標(biāo)的移動路徑是根據(jù)眼動規(guī)則來，我們的視線會首先與文案聚焦到「召喚行為」的按鈕上，也就是左邊，這時候鼠標(biāo)輕而易舉地隨之而來。
而手指行為的操作，會以右為前進(jìn)導(dǎo)向，且右手手勢因為便捷性，也會以右為確認(rèn)操作。否則單手持機(jī)，且行進(jìn)路徑長的話，用戶想進(jìn)行確認(rèn)操作會相對比較吃力。
這就是 Web 與 App 在按鈕位置上的主要區(qū)別。
那會有同學(xué)問到說 Web 的「取消」到底是放在左邊還是右邊？這里我說點自己的想法。
如果根據(jù)眼動規(guī)則與鼠標(biāo)的操作模式來說，Web 「取消按鈕」當(dāng)然是放在右邊更為合適。但如今人們已經(jīng)習(xí)慣了移動產(chǎn)品的「右行進(jìn)，左取消」屬性，且在界面上的視覺終點一般是在右邊，能引導(dǎo)用戶進(jìn)行召喚行為。
但這不具備指導(dǎo)性原則，如果要拆開說，里面還有很多說法。
比如 windows 和 macOS 的設(shè)計規(guī)范里「取消按鈕」的位置完全是相反的。win 的取消在右，macOS 的取消在左。
兩套體系的按鈕位置相互矛盾。這件事本身也說明，只要你在你的 Web 產(chǎn)品里規(guī)范好自己的設(shè)計體系，就沒有對錯之分。不要一會兒這個「取消」在左邊，一會兒那個「取消」又在右邊，給用戶造成認(rèn)知障礙即可。
但是！我更推崇 macOS 的設(shè)計規(guī)范。原因在于成熟度與一致性。
主觀因素：眾所周知，蘋果是更擅長做設(shè)計的公司，體驗過 Mac 的朋友應(yīng)該能理解我說的這句話。一般來說，我只聽過從 Win 切換到 Mac 的，沒有說從 Mac 切換到 Win 的，除了少部分因為工作需求需要同步使用的。
客觀因素：移動產(chǎn)品的普及，已經(jīng)有相當(dāng)成熟的設(shè)計體系支持行進(jìn)按鈕右側(cè)化設(shè)計，統(tǒng)一 Web 或 PC 產(chǎn)品只會讓用戶的操作行為更方便。
這就是我本小節(jié)想聊的，關(guān)于 Web 與 App 按鈕設(shè)計的差異。
「取消按鈕」的正確解法
我相信，只要是平時稍微有認(rèn)真觀察的同學(xué)，都能知道我上述聊的內(nèi)容。我個人也不認(rèn)為這些內(nèi)容具備任何需要總結(jié)的價值。但是如果不寫出來，就沒辦法說明我接下來要聊的內(nèi)容，也是我這篇文章的重點部分。
通過上述內(nèi)容，我以不同類型的按鈕案例來解釋「取消按鈕」的控制權(quán)。各位可以看出，即使是不同類型的「取消按鈕」，在權(quán)重上的道理也都是一樣的。
但我上面舉的所有產(chǎn)品功能的例子，都不是最佳設(shè)計方案，包括微信。
那如何設(shè)計才是最佳方式呢？取消按鈕真的具備召喚行為？
a. 界面層與彈框?qū)?/strong>
其實嚴(yán)謹(jǐn)點來說，界面層的「取消按鈕」與彈框?qū)拥摹溉∠粹o」的意義是不同的。
雖然都是安全性后退，但是前者多了一層含義：放棄屬性。
還是微信朋友圈的界面：
這里的「取消按鈕」有兩個狀態(tài)，一是用戶剛點進(jìn)來，無任何操作，點擊取消，解散該頁面；二是進(jìn)來之后，附帶操作行為，這時候點擊取消，不僅僅是解散當(dāng)前頁面，還包括「放棄當(dāng)前編輯的狀態(tài)」。
所以會彈出第二層彈窗：
這時候無論點擊「保留」還是「不保留」都是取消，退出當(dāng)前編輯頁面，不對系統(tǒng)產(chǎn)生變更行為，但都屬于放棄了當(dāng)前操作。
無非就是微信通過加粗「保留」來告訴用戶，這里的召喚行為是它而已。
所以這層「取消」的含義，不僅僅是取消，還多了一步是否把你放棄的內(nèi)容保留下來的邏輯。
因此在這層含義上，「取消按鈕」也需要特殊處理。
如果說微信這里的「取消按鈕」在設(shè)計上沒有突出其特殊性，那 Twitter 同樣的例子，就比微信高明很多：
同樣是發(fā)布行為，Twitter 在「取消按鈕」上選用了品牌色。因為在其編輯狀態(tài)下點擊取消，會出現(xiàn)與微信同樣的情況：
而 Twitter 的高明之處不僅僅在其對于「取消按鈕」的樣式處理，還在于其對是否「保留」做了明確的設(shè)計區(qū)分：微信的保留等于 Twitter 的保存草稿，不保留等于刪除。而在通用型設(shè)計規(guī)范里，刪除內(nèi)容在樣式上應(yīng)該區(qū)別于發(fā)布以及取消。
更甚者是，其彈出的這個彈框中，還保留了真正意義上的「取消」，即解散行為。在 Twitter 的這個設(shè)計上，兩個取消雖然都叫取消，但是通過顏色進(jìn)行區(qū)分，來表示它們之間在邏輯上的差異，這才是我說的高明之處 —— 對每個按鈕的處理都恰到好處。
類似的還有微博，但是微博對于「取消按鈕」的類型差異沒有做出區(qū)分，原因在于它為了弱化界面層的取消，與彈框?qū)拥娜∠麡邮奖３至艘恢隆?
雖然沒什么太大問題，但從嚴(yán)格的邏輯上來說，這兩者取消是存在歧義的。只是用戶已經(jīng)習(xí)慣且理解了，所以沒要造成使用的負(fù)擔(dān)。
微信的彈框雖然避免了這層歧義，但在操作上還是不夠直觀，我每次發(fā)微信朋友圈，點取消彈出「保留」與「不保留」我都要停頓一下謹(jǐn)慎地進(jìn)行選擇，生怕自己點錯。
當(dāng)然，這里面還有關(guān)于顏色的說法。
這時候再對比 Twitter 的界面就能看出設(shè)計師之間的差距了。
b. 彈框?qū)印溉∠诡伾牟町?/strong>
上面提到的許多例子中，還存在一個類似的問題：它們大多選用 iOS 自帶的彈框直接做為操作對象。
我始終覺得在 iOS 提供的彈框中，兩個操作的按鈕顏色保持一致是不對的。
粗細(xì)有時候很難被直觀感受，而顏色可以在第一時間被感知。
比如前面提到的這個案例：
理想情況下，即使用戶知道右邊是行進(jìn)，左邊是取消，但彈出這個彈框的時候，不免還是需要再次閱讀一遍進(jìn)行確認(rèn)。
但如果改個顏色，好像就更好理解（當(dāng)然文案也是問題，但優(yōu)先級弱于顏色），畢竟彈框也是設(shè)計的一部分：
需要注意的是，用戶既然已經(jīng)選擇取消，就盡量明確的告知用戶，不要為了留存而留存，以至于模糊化該彈窗的選擇結(jié)果。
所以召喚行為，并不是強(qiáng)迫用戶去做，而是遵循用戶的「旨意」去提供選擇。這里的「返回」才是真正的召喚行為，而「取消」并不具備召喚屬性。硬生生的給「取消」附上召喚屬性，只會讓用戶在操作時摸不著頭腦。
包括下圖，我常常因為在使用 App 時，彈出這樣的彈框，而不能在第一時間進(jìn)行正確的點擊，選擇退出當(dāng)前的 App。
這樣例子還有很多。
但是我覺得做得好的，應(yīng)該是這樣的：
或：
這就是刻板印象造成的結(jié)果。我們應(yīng)該學(xué)會適當(dāng)?shù)厥褂每丶?，并根?jù)自己的產(chǎn)品對其進(jìn)行優(yōu)化。而不是一味跟風(fēng)。
綜上所述：界面層的取消，為了表示其作用性的不同，且界面元素眾多，突出顏色是沒問題的；但彈框?qū)拥娜∠c確認(rèn)在顏色上沒做區(qū)分，直接用不太明顯的粗細(xì)效果讓用戶聚焦于這兩個內(nèi)容的選擇上，其實是不友好的設(shè)計。
如果對 iOS 設(shè)計規(guī)范有足夠的了解的同學(xué)就能知道：它們在彈框控件上給出的兩個選擇都不是真正意義上的召喚行為按鈕，只是常規(guī)內(nèi)容，且更適用于產(chǎn)品開發(fā)，而不是設(shè)計指導(dǎo)。
如果你仔細(xì)觀察 macOS 的設(shè)計，就能發(fā)現(xiàn)他們?yōu)榫邆湔賳拘袨榈陌粹o位置與顏色都做了特殊處理，并不是簡單的同色系，或用粗細(xì)表示。如圖：
雖然用 macOS 來反駁 iOS 似乎不太合理，但我只是想說明在設(shè)計結(jié)果上，我們應(yīng)該有自己的思考。
就這個問題，我在 Twitter 上咨詢了前 Apple，后創(chuàng)辦了 UXM 的產(chǎn)品設(shè)計師 Anthony。原因是，他曾經(jīng)也就「取消按鈕」的顏色提出過一些個人看法。
在我說了這些內(nèi)容之后，他跟我說的第一句話是：
Hi Dai — While Apple is very good at design, they are not perfect.（Apple 非常擅長設(shè)計，但它們并不完美。）
接著他繼續(xù)說道：你這套理論非常棒，所以你完全可以按它去給自己的產(chǎn)品構(gòu)建一套設(shè)計規(guī)范，并不一定要遵循 Apple。
借著這個機(jī)會，我還跟他聊了許多其他內(nèi)容。而這件事本身再一次驗證了我的想法：越牛逼的人越謙虛，且平易近人。
哦，不是，跑題了，應(yīng)該是：不存在完美的設(shè)計規(guī)范，設(shè)計師在成長過程中并不一定要循規(guī)蹈矩，受到規(guī)則的限制，認(rèn)為設(shè)計就該如此。而是學(xué)會獨立思考，突破屏障，去挖掘更深層次的內(nèi)容。
看完這篇文章，再去翻一翻 Google Material Design Guidelines，就會有一種「哇哦！原來如此！」的感觸了。
小結(jié)
所以我這篇文章的內(nèi)容結(jié)論是：
-
位置固定，左回退，右行進(jìn)；
-
顏色區(qū)分，左淺色，右深色；
-
召喚行為不是用戶想做的事，而是我們應(yīng)該要讓用戶做的事，但不是強(qiáng)迫，所以正常情況下，「取消按鈕」通常不具備召喚屬性。
可能有人會覺得，這么一個小問題，不至于用這么長一篇文章來說明，不過人么，就是存在這樣那樣的區(qū)別。我認(rèn)為需要就可以了。
本來這篇文章還有一段關(guān)于「手勢按鈕尺寸」的內(nèi)容，不過到目前為止，文章內(nèi)容太長了，所以我暫時去掉了，會在之后的文章里分享給大家。
當(dāng)然，到此為止，我聊的內(nèi)容基本適用于通用場景，且適用于大部分的產(chǎn)品設(shè)計，但在一些特殊場景下的按鈕位置、顏色，也會有不同設(shè)計方式，這就要根據(jù)具體問題來具體分析。
我這里只是把「取消按鈕」的設(shè)計差異、細(xì)節(jié)提供給大家，以便幫助各位在工作中有更深入的思考，而不是想當(dāng)然的說就是放左邊或右邊，或者就應(yīng)該是什么顏色等等。包括對待其他內(nèi)容也一樣。
藍(lán)藍(lán)設(shè)計( www.cqzjtgb.com )是一家專注而深入的界面設(shè)計公司，為期望卓越的國內(nèi)外企業(yè)提供卓越的UI界面設(shè)計、BS界面設(shè)計 、 cs界面設(shè)計 、 ipad界面設(shè)計 、 包裝設(shè)計 、 圖標(biāo)定制 、 用戶體驗 、交互設(shè)計、網(wǎng)站建設(shè) 、平面設(shè)計服務(wù)。