所以我们从下面三个大点来聊聊「取消按钮」的设计：
1.按钮中的「召唤行为」（理清按钮设计的概念）
2.其背后的控制权（关于按钮的权重信息）
3.「取消按钮」的正确解法（重点）

按钮中的「召唤行为」
通常，我们在产品中会为了达成某种指标，需要在界面上引导用户去完成我们希望其完成的操作。且这类操作是可以达成某种目的的，我们把这类操作称为「召唤行为」，即从元素的角度引导用户完成任务。
这类「召唤行为」最常出现的，是在按钮设计的过程中。
用户如何将元素理解为按钮？就是通过对形状和颜色的控制，使该元素看起来像一个按钮。

它们的目的一致，都是召唤用户进行点击，至于类型的选择一般根据功能界面的上下文情况进行判断。
其重要程度也是以此顺序排列：凸起 > 扁平 > 边框 > 文本。
这类设计的结果就是：无需让用户思考要点哪里，而是直接判断下一步是否进行。帮助用户简化一个思考点。
注：因为判断是否进行的操作还取决于功能本身以及文案的提示，与我们今天要聊的不是一回事。所以我们跳过这块，直接聊「召唤行为」与「取消按钮」的关系。
这段内容各位只要记住：按钮的行进与回退，基本遵循「召唤行为」的思路来设计。
这个概念知道了，我们就可以对后面的内容继续进行拆解了。
背后的控制权
接下来我们从多个角度来挖一下「取消按钮」的设计，分析其不同地位。
a. 安全性后退
「取消」在多数情况下，意为安全性地后退，并将界面恢复到原有的内容上，不对界面与功能本身造成破坏，防止对系统进行不必要地更改的「安全措施」。
所以正常来说，「取消按钮」不是「召唤行为」。以至于通常在设计上会被弱化，以表示该按钮在功能的流程中，不是主要的，且是提供给用户作为回退余地的操作。
b. 强化「取消按钮」
当我们不希望用户退出某个界面，或停止某个流程时，往往会选择将「取消按钮」强化。

c. Web 与 App 的位置差异
我们现在见到越来越多的 Web 端产品，也开始遵循 App 产品的设计，把「取消按钮」放在左边，「召唤行为」按钮放在右边。
但在早期，Web 的「取消按钮」基本是放在右边，原因是鼠标的移动路径是根据眼动规则来，我们的视线会首先与文案聚焦到「召唤行为」的按钮上，也就是左边，这时候鼠标轻而易举地随之而来。
而手指行为的操作，会以右为前进导向，且右手手势因为便捷性，也会以右为确认操作。否则单手持机，且行进路径长的话，用户想进行确认操作会相对比较吃力。