UI设计中“取消按钮”的使用分析详解

按钮，无论是在Web还是App上都被广泛地使用，而极少有设计师会留意到按钮当中的细节，导致在设计过程中发生一些低级的出错，使得用户在完成任务的过程中形成制约，无法成功达成目的。

在许多优秀的产品中，关于按钮的设计早已有了一套相应的完善去执行。作为设计师，应该总结很多规范，并产出一套适用于自家产品的设计规则。这只是我写「按钮规范」系列文章的目的。

现在主要先与大家看看「取消按钮」的设计模式。

关于「取消」，大多数人对其理解还停留在PC端，认为「取消」的目的就是让客户停止操作上的流程。但时目前日，「取消按钮」的设计早已有许多方法与策略，如果不认真探究与预测，可能会忽视一些客户行为上的细节。

然而我们从以下三个大点来看看「取消按钮」的设计：

1.按钮中的「召唤行为」（理清按钮设计的概念）

2.其背后的控制权（关于按钮的权重信息）

3.「取消按钮」的正确方法（重点）

按钮中的「召唤行为」

一般，我们在产品中会为了达成某些指标，需要在界面上鼓励客户去完成我们期望其完成的操作。且这类操作是可以达成某些目的的，我们把这类操作称为「召唤行为」，即从元素的视角引导用户完成任务。

这类「召唤行为」最常发生的，是在按钮设计的过程中。

用户如何将元素理解为按钮？就是借助对外形和形状的控制，使该元素看上去像一个按钮。

它唯一的作用就是让用户点击，并且是主动让用户点击。

我们一直在各种设计中看到这种的按钮设计，或许也有更多样式，如：

他们的目的一致，都是召唤用户进行点击，至于类别的选取一般按照用途界面的上下文情况进行判定。

其重要程度也有以此顺序排列：凸起>扁平>边框>文本。

这类设计的结果就是：无需让客户探讨要点哪里，而是直接判定下一步是否进行。帮助用户简化一个思考点。

注：因为判断是否进行的操作还取决于功能本来以及文案的提醒，与我们最近要聊的不是一回事。所以我们跳过这块，直接聊「召唤行为」与「取消按钮」的关系。

这段内容各位只要记住：按钮的行进与回退，基本依照「召唤行为」的模式来设计。

这个概念清楚了，我们就可以对前面的内容再次进行拆解了。

背后的控制权

接出来我们从多个视角来挖一下「取消按钮」的设计，分析其不同地位。

a.安全性后退

「取消」在多数状况下，意为安全性地后退，并将界面恢复到原有的内容上，不对界面与功用本身产生破坏，防止对系统进行不必要地设置的「安全机制」。

然而正常来说，「取消按钮」不是「召唤行为」。以至于一般在设计上会被凸显，以表示该按钮在功能的步骤中，不是主要的，且是提供给用户成为回退余地的操作。

如：

在这张图里，「登录」是「召唤行为」，所以突出显示。根据样式定义，用了扁平按钮。而更改在这个画面里属于「安全性后退」的操作，于是将其凸显。

这是多数产品采取的设计方法。

例如美团的这个页面：

产品希望客户登录，就会提升「登录」行为的图标，弱化「回退」行为的按钮。

同样，我们在微信同学圈的设计里也能看到这种的设计：

我们总是期望用户大幅操作下去，但也要给客户提供回退的行为，所以在这种设计中，「取消按钮」会被弱化，「行进按钮」会被强化，因为「取消按钮」在此处不是产品人员希望的「召唤行为」。

这是经常以来的设计共识，但目前也出现了些许差异。「取消按钮」也开始具有「召唤行为」的属性。

b.强化「取消按钮」

当我们不期望用户退出某个界面，或中止某个流程时，往往会选取将「取消按钮」强化。

如：

或：

通过对字体的加粗，以暗示用户不要随意退出。在这个步骤里，「取消按钮」具备了「召唤行为」属性。

也是产品通过改变「取消按钮」的文案，让其具有「召唤行为」的属性，使得用户在此过程中随意不要退出该流程：

此处的「继续选座」就是「取消」，因为此处的「取消」成了「召唤行为」，所以借助改变文案的方法，确保客户留出来继续进行步骤中的任务。

然而不可取的是，这里的「返回」反而给了客户一种必须探讨的压力。返回？是留在此处，还是退出去？思考几秒后，反应过来，是退出去。这样的文案与只有在发现「继续选座」后进行对比，才能反应过来具体是哪个意思，除非是用户具有操作习惯，知道「右边」是「行进」操作，才能迅速理解。（也许也有个问题，我们在第三各模块来说明）

然而多数用户还是得思考一下，所以要改，最好它们文案都能改了，否则思考的「停顿」会让用户造成厌恶感。

且在一些产品界面里，为了防止客户在流程中解除行为，甚至会转移「取消」与「行进」两者的位置，如：

之前照片了某个产品的界面，写文这天发现即将改过来，这里就没放了。

各位注意，最好不要这么进行设计，因为客户在App的操作上早已习惯左边取消，右边行进，调换位置仍然能暂时缓解用户的退出行为，但容易造成误操作，与客户的希望不同，导致在产品体验上会被用户排斥。

然而到此处，先给一个结论，即在App的设计上，行进操作在右，回退操作在左，召唤属性根据画面对图标做突出处理。

然而「取消按钮」真的应当具有召唤属性么？不急于，我们第三模块再细聊。下面我们先看看Web与App的之间的差异。

c.Web与App的位置差异

我们今天看到越来越多的Web端产品，也开始顺应App产品的设计，把「取消按钮」放在前面，「召唤行为」按钮放在左边。

但在初期，Web的「取消按钮」基本是放到前面，原因是鼠标的移动模式是按照眼动规则来，我们的视野会首先与文案聚焦到「召唤行为」的按钮上，也就是右边，这之后鼠标轻而易举地逐渐而来。

而手指行为的操作，会以右为前行导向，且右手手势由于方便性，也会以右为确定操作。否则单手持机，且行进模式长的话，用户想进行确定操作会相对比较吃力。

这就是Web与App在按钮位置上的主要区别。

那会有朋友问到说Web的「取消」到底是放到前面还是后面？这里我说点自己的看法。

如果按照眼动规则与鼠标的操作方式来说，Web「取消按钮」当然是置于左侧更为适合。但目前他们终于习惯了移动产品的「右行进，左取消」属性，且在界面上的视觉终点通常是在后面，能鼓励用户进行召唤行为。

但这不具有指导性方法，如果要拆开说，里面也有诸多说法。

包括windows和macOS的设计规范里「取消按钮」的位置完全是相反的。win的取消在右，macOS的取消在左。

两套机制的按钮位置互相冲突。这件事本来也表明，只要你在你的Web产品里完善好自己的设计模式，就没有对错之分。不要一会儿这个「取消」在上面，一会儿那个「取消」又在后面，给用户产生思维障碍即可。

然而！我更推崇macOS的设计完善。原因在于成熟度与一致性。

主观原因：众所周知，苹果是更擅长做设计的公司，体验过Mac的同事必须能理解我说的这句话。一般来说，我只听过从Win切换到Mac的，没有说从Mac切换到Win的，除了少个别由于工作意愿需要同步使用的。

客观原因：移动产品的普及，已经有非常成熟的设计模式支持行进按钮右侧化设计，统一Web或PC产品只会让顾客的操作行为更方便。

这就是我本小节想聊的，关于Web与App按钮设计的变化。

「取消按钮」的正确方法

我坚信，只要是以前稍微有仔细观察的朋友，都能了解我上述聊的内容。我个人也不觉得这种内容具有任何必须总结的价值。但是即使不写下来，就没办法说明我接下去要聊的内容，也是我这篇文章的重点部分。

通过上述内容，我以不同类别的图标案例来解释「取消按钮」的控制权。各位可以断定，即使是不同类别的「取消按钮」，在权重上的道理也都是一样的。

但我里面举的所有产品功能的举例，都不是最佳设计方案，包括微信。

那怎么设计才是最佳方法呢？取消按钮真的具有召唤行为？

a.界面层与弹框层

虽然严谨点来说，界面层的「取消按钮」与弹框层的「取消按钮」的含义是不同的。

然而都是安全性后退，但是后者多了一层意思：放弃属性。

还是微信朋友圈的界面：

此处的「取消按钮」有两个状况，一是用户刚点进来，无任何操作，点击取消，解散该页面；二是进来以后，附带操作行为，这之后点击取消，不只是是解散当前页面，还包含「放弃当前编辑的状况」。

然而会弹出第二层弹窗：

这之后无论点击「保留」还是「不保留」都是更改，退出当前编辑页面，不对平台形成变更行为，但都属于放弃了当前操作。

无非就是微信通过加粗「保留」来告诉顾客，这里的召唤行为是它而已。

然而这层「取消」的涵义，不只是是取消，还多了一步是否把你抛弃的内容保留下来的逻辑。

此外在这层意思上，「取消按钮」也必须特殊处理。

如果说微信这里的「取消按钮」在设计上没有突显其特殊性，那Twitter同样的举例，就比微信高明这些：

同样是公布行为，Twitter在「取消按钮」上采用了品牌色。因为在其编辑状态下点击取消，会发生与微信同样的状况：

而Twitter的高明之处不只是在其针对「取消按钮」的风格处理，还在于其对能否「保留」做了确立的设计区别：微信的保留等于Twitter的保存草稿，不保留等于删除。而在通用型设计完善里，删除内容在风格上需要区分于公布并且更改。

更甚者是，其跳出的这个弹框中，还保留了真正意义上的「取消」，即解散行为。在Twitter的这个设计上，两个取消虽然都叫取消，但是通过颜色进行区别，来表示他们之间在逻辑上的差别，这才是我说的高明之处——对每个按钮的处理都恰到好处。

类似的也有微博，但是微博对于「取消按钮」的类别变化没有作出区别，原因在于它为了削弱界面层的更改，与弹框层的更改颜色保持了一致。

然而没什么太大弊端，但从严格的逻辑上来说，这二者取消是存在歧义的。只是用户早已习惯且理解了，所以没要产生使用的负担。

微信的弹框其实避免了这层歧义，但在操作上而是不够直观，我经常发微信同学圈，点更改弹出「保留」与「不保留」我都要停顿一下谨慎地进行选择，生怕自己点错。

其实，这里面也有关于色彩的表述。

这之后再对比Twitter的界面能够看出设计师之间的差别了。

b.弹框层「取消」颜色的差异

后面提及的许多实例中，还存在一个类似的难题：它们大多采用iOS自带的弹框直接做为操作对象。

我一直认为在iOS提供的弹框中，两个操作的按钮形状维持一致是不对的。

粗细有之后很难被直观展现，而色彩可以在第一时间被感知。

包括上面提及的这个实例：

理想状况下，即使用户了解右边是行进，左边是更改，但弹出这个弹框的之后，不免还是必须重新阅读一遍进行确定。

但即使改个色彩，好像就更好理解（也许文案也是难题，但优先级弱于颜色），毕竟弹框也是设计的一部分：

需要切记的是，用户即使早已选择更改，就尽量明确的告知客户，不要为了留存而留存，以至于模糊化该弹窗的选择结果。

然而召唤行为，并不是逼迫用户去做，而是遵从用户的「旨意」去提供选择。这里的「返回」才是真正的召唤行为，而「取消」并不具有召唤属性。硬生生的给「取消」附上召唤属性，只会让用户在操作时摸不着头脑。

比如下图，我一直由于在使用App时，弹出这样的弹框，而不能在第一时间进行恰当的点击，选择退出当前的App。

这种举例还有好多。

然而我认为做得好的，应该是这种的：

或：

这就是刻板印象导致的结果。我们必须学会适当地使用控件，并按照自己的产品对其进行改进。而不是一味跟风。

综上所述：界面层的更改，为了表示其作用性的不同，且界面元素很多，突出色彩是没问题的；但弹框层的更改与确定在色彩上没做区别，直接用不太显著的粗细效果让用户聚焦于这两个内容的选择上，其实是不友好的设计。

如果对iOS设计完善有足够的认识的朋友能够了解：它们在弹框控件上给出的两个选择都不是真正含义上的召唤行为按钮，只是常规内容，且更适用于产品研发，而不是设计指导。

如果你认真观察macOS的设计，就能看到它们为具有召唤行为的图标位置与色彩都做了特殊处理，并不是简洁的同色系，或用粗细表示。如图：

然而用macOS来讽刺iOS似乎不太合理，但我也是想表明在设计结果上，我们必须有自己的反思。

就这个问题，我在Twitter上咨询了前Apple，后创办了UXM的产品设计师Anthony。原因是，他当时也就「取消按钮」的样式提出过一些个人意见。

在我说了很多内容后来，他跟我说的第一句话是：

HiDai—WhileAppleisverygoodatdesign,theyarenotperfect.（Apple非常擅长设计，但他们并不完美。）

接着他再次说道：你这套理论十分棒，所以你完全可以按它去给自己的产品建立一套设计完善，并不必定要遵循Apple。

借着这个机会，我还跟他聊了许多其它内容。而这件事本来再一次验证了我的看法：越牛逼的人越自信，且平易近人。

哦，不是，跑题了，应该是：不存在完美的设计完善，设计师在蜕变过程中并不必定要循规蹈矩，受到规则的限制，认为设计就该如此。而是学会独立构想，突破屏障，去开掘更深层次的内容。

看完这篇文章，再去翻一翻GoogleMaterialDesignGuidelines，就会有一种「哇哦！以前那么！」的感触了。

小结

然而我这篇文章的内容结论是：

位置固定，左回退，右行进；

色彩区分，左白色，右红色；

召唤行为不是用户想做的事，而是我们必须要让顾客做的事，但不是逼迫，所以正常状况下，「取消按钮」通常不具有召唤属性。

或许有人会认为，这么一个小问题，不至于用如此长一篇文章来表明，不过人么，就是存在这么那样的差别。我觉得必须就可以了。

原本这篇文章也有一段关于「手势按钮尺寸」的内容，不过到现今为止，文章内容太长了，所以我暂时去掉了，会在后来的文章里分享给你们。

其实，到此为止，我聊的内容基本适用于通用场景，且适用于大个别的产品设计，但在一些特殊画面下的图标位置、颜色，也会有不同设计方法，这还要按照详细问题来准确预测。

我这里也是把「取消按钮」的设计变化、细节提供给你们，以便帮助大家在工作中有更深入的探讨，而不是想当然的说就是放上面或左边，或者就必须是哪个颜色等等。包括对待其它内容也一样。

那这篇文字就到此处了，谢谢阅读。