按钮规范系列 - 「取消按钮」的设计详解 | 细节分析

按钮，无论是在 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。原因是，他曾经也就「取消按钮」的颜色提出过一些个人看法。

在我说了这些内容之后，他跟我说的第一句话是：

Hi Dai — While Apple is very good at design, they are not perfect.（Apple 非常擅长设计，但它们并不完美。）

接着他继续说道：你这套理论非常棒，所以你完全可以按它去给自己的产品构建一套设计规范，并不一定要遵循 Apple。

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

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

看完这篇文章，再去翻一翻 Google Material Design Guidelines，就会有一种「哇哦！原来如此！」的感触了。

小结

所以我这篇文章的内容结论是：

1. 位置固定，左回退，右行进；
2. 颜色区分，左浅色，右深色；
3. 召唤行为不是用户想做的事，而是我们应该要让用户做的事，但不是强迫，所以正常情况下，「取消按钮」通常不具备召唤属性。

可能有人会觉得，这么一个小问题，不至于用这么长一篇文章来说明，不过人么，就是存在这样那样的区别。我认为需要就可以了。

本来这篇文章还有一段关于「手势按钮尺寸」的内容，不过到目前为止，文章内容太长了，所以我暂时去掉了，会在之后的文章里分享给大家。

当然，到此为止，我聊的内容基本适用于通用场景，且适用于大部分的产品设计，但在一些特殊场景下的按钮位置、颜色，也会有不同设计方式，这就要根据具体问题来具体分析。

我这里只是把「取消按钮」的设计差异、细节提供给大家，以便帮助各位在工作中有更深入的思考，而不是想当然的说就是放左边或右边，或者就应该是什么颜色等等。包括对待其他内容也一样。

那这篇文字就到这里了，谢谢阅读：）

微信公众号： 呆呆U理