“取消按钮”逻辑设计
共 4291字，需浏览 9分钟
·
2021-01-29 06:11
按钮，无论是在 Web 还是 App 上都被广泛地使用，而很少有设计师会注意到按钮当中的细节，导致在设计过程中出现一些低级的错误，使得用户在完成任务的过程中产生阻碍，无法顺利达成目的。
关于「取消」，大多数人对其理解还停留在 PC 端，认为「取消」的目的就是让用户停止操作上的流程。但时至今日，「取消按钮」的设计已经有许多解法与思路，如果不仔细研究与分析，可能会忽略一些用户行为上的细节。
所以我们从下面三个大点来聊聊「取消按钮」的设计：
按钮中的「召唤行为」（理清按钮设计的概念）
其背后的控制权（关于按钮的权重信息）
「取消按钮」的正确解法（重点）
按钮中的「召唤行为」
通常，我们在产品中会为了达成某种指标，需要在界面上引导用户去完成我们希望其完成的操作。且这类操作是可以达成某种目的的，我们把这类操作称为「召唤行为」，即从元素的角度引导用户完成任务。
这类「召唤行为」最常出现的，是在按钮设计的过程中。
用户如何将元素理解为按钮？就是通过对形状和颜色的控制，使该元素看起来像一个按钮。
它唯一的作用就是让用户点击，并且是主动让用户点击。
我们经常在各类设计中见到这样的按钮设计，或许还有更多样式，如：
它们的目的一致，都是召唤用户进行点击，至于类型的选择一般根据功能界面的上下文情况进行判断。
以此顺序排列：凸起 > 扁平 > 边框 > 文本。
这类设计的结果就是：无需让用户思考要点哪里，而是直接判断下一步是否进行。帮助用户简化一个思考点。
注：因为判断是否进行的操作还取决于功能本身以及文案的提示，与我们今天要聊的不是一回事。所以我们跳过这块，直接聊「召唤行为」与「取消按钮」的关系。
这段内容各位只要记住：按钮的行进与回退，基本遵循「召唤行为」的思路来设计。
背后的控制权
a. 安全性后退
「取消」在多数情况下，意为安全性地后退，并将界面恢复到原有的内容上，不对界面与功能本身造成破坏，防止对系统进行不必要地更改的「安全措施」。
「取消按钮」不是「召唤行为」。以至于通常在设计上会被弱化，以表示该按钮在功能的流程中，不是主要的，且是提供给用户作为回退余地的操作。
如：
在这张图里，「登录」是「召唤行为」，所以突出显示。根据风格定义，用了扁平按钮。而取消在这个场景里属于「安全性后退」的操作，于是将其弱化。
比如美团的这个页面：
产品希望用户登录，就会强化「登录」行为的按钮，弱化「回退」行为的按钮。
同样，我们在微信朋友圈的设计里也能见到这样的设计：
我们总是希望用户持续操作下去，但也要给用户提供回退的行为，所以在这些设计中，「取消按钮」会被弱化，「行进按钮」会被强化，因为「取消按钮」在这里不是产品人员期望的「召唤行为」。
这是一直以来的设计共识，但如今也发生了些许变化。「取消按钮」也开始具备「召唤行为」的属性。
b. 强化「取消按钮」
当我们不希望用户退出某个界面，或停止某个流程时，往往会选择将「取消按钮」强化。
如：
或：
通过对字体的加粗，以暗示用户不要轻易退出。在这个流程里，「取消按钮」具备了「召唤行为」属性。
也有产品通过改变「取消按钮」的文案，让其具备「召唤行为」的属性，使得用户在此过程中轻易不要退出该流程：
这里的「继续选座」就是「取消」，因为这里的「取消」成了「召唤行为」，所以通过改变文案的方式，确保用户留下来继续进行流程中的任务。
且在一些产品界面里，为了避免用户在流程中终止行为，甚至会转移「取消」与「行进」两者的位置，如：
之前截图了某个产品的界面，写文这天发现已经改回来，这里就没放了。
先给一个结论，即在 App 的设计上，行进操作在右，回退操作在左，召唤属性根据场景对按钮做突出处理。
c. Web 与 App 的位置差异
我们现在见到越来越多的 Web 端产品，也开始遵循 App 产品的设计，把「取消按钮」放在左边，「召唤行为」按钮放在右边。
但在早期，Web 的「取消按钮」基本是放在右边，原因是鼠标的移动路径是根据眼动规则来，我们的视线会首先与文案聚焦到「召唤行为」的按钮上，也就是左边，这时候鼠标轻而易举地随之而来。
而手指行为的操作，会以右为前进导向，且右手手势因为便捷性，也会以右为确认操作。否则单手持机，且行进路径长的话，用户想进行确认操作会相对比较吃力。
这就是 Web 与 App 在按钮位置上的主要区别。
比如 windows 和 macOS 的设计规范里「取消按钮」的位置完全是相反的。win 的取消在右，macOS 的取消在左。
两套体系的按钮位置相互矛盾。这件事本身也说明，只要你在你的 Web 产品里规范好自己的设计体系，就没有对错之分。不要一会儿这个「取消」在左边，一会儿那个「取消」又在右边，给用户造成认知障碍即可。
主观因素：众所周知，苹果是更擅长做设计的公司，体验过 Mac 的朋友应该能理解我说的这句话。一般来说，我只听过从 Win 切换到 Mac 的，没有说从 Mac 切换到 Win 的，除了少部分因为工作需求需要同步使用的。
客观因素：移动产品的普及，已经有相当成熟的设计体系支持行进按钮右侧化设计，统一 Web 或 PC 产品只会让用户的操作行为更方便。
「取消按钮」的正确解法
我相信，只要是平时稍微有认真观察的同学，都能知道我上述聊的内容。我个人也不认为这些内容具备任何需要总结的价值。但是如果不写出来，就没办法说明我接下来要聊的内容，也是我这篇文章的重点部分。
但我上面举的所有产品功能的例子，都不是最佳设计方案，包括微信。
a. 界面层与弹框层
其实严谨点来说，界面层的「取消按钮」与弹框层的「取消按钮」的意义是不同的。
虽然都是安全性后退，但是前者多了一层含义：放弃属性。
还是微信朋友圈的界面：
这里的「取消按钮」有两个状态，一是用户刚点进来，无任何操作，点击取消，解散该页面；二是进来之后，附带操作行为，这时候点击取消，不仅仅是解散当前页面，还包括「放弃当前编辑的状态」。
所以会弹出第二层弹窗：
这时候无论点击「保留」还是「不保留」都是取消，退出当前编辑页面，不对系统产生变更行为，但都属于放弃了当前操作。
所以这层「取消」的含义，不仅仅是取消，还多了一步是否把你放弃的内容保留下来的逻辑。
因此在这层含义上，「取消按钮」也需要特殊处理。
如果说微信这里的「取消按钮」在设计上没有突出其特殊性，那 Twitter 同样的例子，就比微信高明很多：
同样是发布行为，Twitter 在「取消按钮」上选用了品牌色。因为在其编辑状态下点击取消，会出现与微信同样的情况：
而 Twitter 的高明之处不仅仅在其对于「取消按钮」的样式处理，还在于其对是否「保留」做了明确的设计区分：微信的保留等于 Twitter 的保存草稿，不保留等于删除。而在通用型设计规范里，删除内容在样式上应该区别于发布以及取消。
类似的还有微博，但是微博对于「取消按钮」的类型差异没有做出区分，原因在于它为了弱化界面层的取消，与弹框层的取消样式保持了一致。
虽然没什么太大问题，但从严格的逻辑上来说，这两者取消是存在歧义的。只是用户已经习惯且理解了，所以没要造成使用的负担。
微信的弹框虽然避免了这层歧义，但在操作上还是不够直观，我每次发微信朋友圈，点取消弹出「保留」与「不保留」我都要停顿一下谨慎地进行选择，生怕自己点错。
这时候再对比 Twitter 的界面就能看出设计师之间的差距了。
b. 弹框层「取消」颜色的差异
上面提到的许多例子中，还存在一个类似的问题：它们大多选用 iOS 自带的弹框直接做为操作对象。
我始终觉得在 iOS 提供的弹框中，两个操作的按钮颜色保持一致是不对的。
粗细有时候很难被直观感受，而颜色可以在第一时间被感知。
比如前面提到的这个案例：
理想情况下，即使用户知道右边是行进，左边是取消，但弹出这个弹框的时候，不免还是需要再次阅读一遍进行确认。
但如果改个颜色，好像就更好理解（当然文案也是问题，但优先级弱于颜色），毕竟弹框也是设计的一部分：
需要注意的是，用户既然已经选择取消，就尽量明确的告知用户，不要为了留存而留存，以至于模糊化该弹窗的选择结果。
包括下图，我常常因为在使用 App 时，弹出这样的弹框，而不能在第一时间进行正确的点击，选择退出当前的 App。
这样例子还有很多。
但是我觉得做得好的，应该是这样的：
或：
这就是刻板印象造成的结果。我们应该学会适当地使用控件，并根据自己的产品对其进行优化。而不是一味跟风。
综上所述：界面层的取消，为了表示其作用性的不同，且界面元素众多，突出颜色是没问题的；但弹框层的取消与确认在颜色上没做区分，直接用不太明显的粗细效果让用户聚焦于这两个内容的选择上，其实是不友好的设计。
如果对 iOS 设计规范有足够的了解的同学就能知道：它们在弹框控件上给出的两个选择都不是真正意义上的召唤行为按钮，只是常规内容，且更适用于产品开发，而不是设计指导。
虽然用 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，就会有一种「哇哦！原来如此！」的感触了。
购买后公众号回复：迭代，进入读者群
点击加入我的社群⬇️⬇️⬇️
2020年底福利｜我整理的产品经理PRD、原型资料下载