「确定」和「取消」按钮谁左谁右？

对于「确定」和「取消」按钮摆放位置的一个思考，到底谁左谁右才对呢？不知同为射鸡师的你们是否也有同样的困惑呢？

在许多优秀的产品中，关于按钮的设计已经有了一套相应的规范去执行。作为设计师，应该总结这些规范，并产出一套适用于自家产品的设计规范。

苹果不论移动或电脑设备，确定按钮都放在右边。

ios的移动设备确定按钮的放置位置

PC端和安卓端，恰恰相反确定按钮都放在左边。

安卓的移动设备确定按钮的放置位置

然而Android4.0后变更为“取消/确定”，这似乎违背了多年来的坚持。

此次更改意味着什么呢？有人会觉得这是叛徒行为，毁掉多年来win培养的用户习惯。那么我们来仔细分析一下不同的放置位置到底有何不同？

1、阅读视线的顺序造成视线无意识回跳

我们按照从左到右的阅读习惯，最终视觉点会停留在右侧上。可以更快速的方便我们作出选择。而并非像WP一样绕一圈。

古腾堡法则指人们在浏览页面的时候，视觉都趋向于从上到下，从左到右的眼动规律。左上角是视觉的第一落点区，而右下角是视觉最终落点区。用户的视觉中心往往在页面的左上方，而结束浏览时视线往往落在右下角，所以合理利用这个法则可以帮助用户更好地获取内容并采取行动。

那么根据这个法则就不难解释为何安卓继4.0之后为何将确定更改到右下角的位置。显然最终的视觉落脚点很大程度上影响着用户的操作。所以说确定放在右下角是更为合理的。

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

用户如何将元素理解为按钮？

就是通过对形状和颜色的控制，使该元素看起来像一个按钮。

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

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

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

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

这段内容各位只要记住：按钮的行进与回退，基本遵循「召唤行为」的思路来设计。

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

a. 安全性后退

「取消」在多数情况下，意为安全性地后退，并将界面恢复到原有的内容上，不对界面与功能本身造成破坏，防止对系统进行不必要地更改的「安全措施」。

在这张图里，「登录」是「召唤行为」，所以突出显示。根据风格定义，用了扁平按钮。而取消在这个场景里属于「安全性后退」的操作，于是将其弱化。

这是多数产品采用的设计方式。

比如美团的这个页面：

产品希望用户登录，就会强化「登录」行为的按钮，弱化「回退」行为的按钮。

同样，我们在微信朋友圈的设计里也能见到这样的设计：

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

这是一直以来的设计共识，但如今也发生了些许变化。「取消按钮」也开始具备「召唤行为」的属性。

b. 强化「取消按钮」

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

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

在 App 的设计上，行进操作在右，回退操作在左，召唤属性根据场景对按钮做突出处理。

但是「取消按钮」真的应该具备召唤属性么？不着急，我们第三模块再细聊。下面我们先聊聊 Web 与 App 的之间的差异。

c. Web 与 App 的位置差异

我们现在见到越来越多的 Web 端产品，也开始遵循 App 产品的设计，把「取消按钮」放在左边，「召唤行为」按钮放在右边。

但在早期，Web 的「取消按钮」基本是放在右边，原因是鼠标的移动路径是根据眼动规则来，我们的视线会首先与文案聚焦到「召唤行为」的按钮上，也就是左边，这时候鼠标轻而易举地随之而来。

而手指行为的操作，会以右为前进导向，且右手手势因为便捷性，也会以右为确认操作。否则单手持机，且行进路径长的话，用户想进行确认操作会相对比较吃力。

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

那会有同学问到说 Web 的「取消」到底是放在左边还是右边？

如果根据眼动规则与鼠标的操作模式来说，Web 「取消按钮」当然是放在右边更为合适。但如今人们已经习惯了移动产品的「右行进，左取消」属性，且在界面上的视觉终点一般是在右边，能引导用户进行召唤行为。

但这不具备指导性原则，如果要拆开说，里面还有很多说法。

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

两套体系的按钮位置相互矛盾。这件事本身也说明，只要你在你的 Web 产品里规范好自己的设计体系，就没有对错之分。不要一会儿这个「取消」在左边，一会儿那个「取消」又在右边，给用户造成认知障碍即可。

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

但我上面举的所有产品功能的例子，都不是最佳设计方案。

那如何设计才是最佳方式呢？取消按钮真的具备召唤行为？

a. 界面层与弹框层

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

虽然都是安全性后退，但是前者多了一层含义：放弃属性。

还是微信朋友圈的界面：

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

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

上面提到的许多例子中，还存在一个类似的问题：它们大多选用 iOS 自带的弹框直接做为操作对象。

我始终觉得在 iOS 提供的弹框中，两个操作的按钮颜色保持一致是不对的。

粗细有时候很难被直观感受，而颜色可以在第一时间被感知。

比如前面提到的这个案例：

理想情况下，即使用户知道右边是行进，左边是取消，但弹出这个弹框的时候，不免还是需要再次阅读一遍进行确认。

但如果改个颜色，好像就更好理解（当然文案也是问题，但优先级弱于颜色），毕竟弹框也是设计的一部分：

需要注意的是，用户既然已经选择取消，就尽量明确的告知用户，不要为了留存而留存，以至于模糊化该弹窗的选择结果。

包括下图，我常常因为在使用App时，弹出这样的弹框，而不能在第一时间进行正确的点击，选择退出当前的App。

这样例子还有很多。

但是我觉得优秀案例应该是这样的：

我们应该学会适当地使用控件，并根据自己的产品对其进行优化。而不是一味地跟风。

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

2、颜色区分，左浅色，右深色；

3、取消和确定孰轻孰重？

比如上一步和下一步毫无疑问是上一步放置在左边，下一步放置在右边。那么通常情况下下一步的操作频率明显比上一步的操作频率要高。那么如果按照这个逻辑，取消／确定这种放置位置就更为合理。有朋友问取消和确定哪个更重要？通常还是以实际的操作频率的基准来看的。实际操作中遇到这种情况，往往还是确定按钮的操作频率要高很多。所以确定放置在右侧，取消放置在左侧并没有什么不妥。

当然无论我们怎么样放置一定要遵循系统逻辑的一致性，比如在同一个APP里，取消和确定的操作位置要保持统一，不要换来换去，不然很容易造成用户的误操作。

欢迎扫描关注我的微信公众号。热爱设计，关注用户体验，分享设计思考。