APP UI设计中取消按钮使用详解 | 细节分析

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

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

但是！我更推崇 macOS 的设计规范。原因在于成熟度与一致性。

主观因素：众所周知，苹果是更擅长做设计的公司，体验过 Mac 的朋友应该能理解我说的这句话。一般来说，我只听过从 Win 切换到 Mac 的，没有说从 Mac 切换到 Win 的，除了少部分因为工作需求需要同步使用的。

客观因素：移动产品的普及，已经有相当成熟的设计体系支持行进按钮右侧化设计，统一 Web 或 PC 产品只会让用户的操作行为更方便。

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

「取消按钮」的正确解法

我相信，只要是平时稍微有认真观察的同学，都能知道我上述聊的内容。我个人也不认为这些内容具备任何需要总结的价值。但是如果不写出来，就没办法说明我接下来要聊的内容，也是我这篇文章的重点部分。

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

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

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

a. 界面层与弹框层

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

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

还是微信朋友圈的界面：

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

所以会弹出第二层弹窗：

这时候无论点击「保留」还是「不保留」都是取消，退出当前编辑页面，不对系统产生变更行为，但都属于放弃了当前操作。

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

所以这层「取消」的含义，不仅仅是取消，还多了一步是否把你放弃的内容保留下来的逻辑。

因此在这层含义上，「取消按钮」也需要特殊处理。

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

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

而 Twitter 的高明之处不仅仅在其对于「取消按钮」的样式处理，还在于其对是否「保留」做了明确的设计区分：微信的保留等于 Twitter 的保存草稿，不保留等于删除。而在通用型设计规范里，删除内容在样式上应该区别于发布以及取消。

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