UI设计中“取消按钮”的使用分析详解( 三 ) _UI设计

但我上面举的所有产品功能的例子，都不是最佳设计方案，包括微信。
那如何设计才是最佳方式呢？取消按钮真的具备召唤行为？
a. 界面层与弹框层
其实严谨点来说，界面层的「取消按钮」与弹框层的「取消按钮」的意义是不同的。
虽然都是安全性后退，但是前者多了一层含义：放弃属性。
还是微信朋友圈的界面：

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

文章插图
这时候无论点击「保留」还是「不保留」都是取消，退出当前编辑页面，不对系统产生变更行为，但都属于放弃了当前操作。
无非就是微信通过加粗「保留」来告诉用户，这里的召唤行为是它而已。
【UI设计中“取消按钮”的使用分析详解】所以这层「取消」的含义，不仅仅是取消，还多了一步是否把你放弃的内容保留下来的逻辑。
因此在这层含义上，「取消按钮」也需要特殊处理。
如果说微信这里的「取消按钮」在设计上没有突出其特殊性，那 Twitter 同样的例子，就比微信高明很多：

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

文章插图
而 Twitter 的高明之处不仅仅在其对于「取消按钮」的样式处理，还在于其对是否「保留」做了明确的设计区分：微信的保留等于 Twitter 的保存草稿，不保留等于删除。而在通用型设计规范里，删除内容在样式上应该区别于发布以及取消。
更甚者是，其弹出的这个弹框中，还保留了真正意义上的「取消」，即解散行为。在 Twitter 的这个设计上，两个取消虽然都叫取消，但是通过颜色进行区分，来表示它们之间在逻辑上的差异，这才是我说的高明之处 —— 对每个按钮的处理都恰到好处。
类似的还有微博，但是微博对于「取消按钮」的类型差异没有做出区分，原因在于它为了弱化界面层的取消，与弹框层的取消样式保持了一致。

文章插图
虽然没什么太大问题，但从严格的逻辑上来说，这两者取消是存在歧义的。只是用户已经习惯且理解了，所以没要造成使用的负担。
微信的弹框虽然避免了这层歧义，但在操作上还是不够直观，我每次发微信朋友圈，点取消弹出「保留」与「不保留」我都要停顿一下谨慎地进行选择，生怕自己点错。
当然，这里面还有关于颜色的说法。
这时候再对比 Twitter 的界面就能看出设计师之间的差距了。
b. 弹框层「取消」颜色的差异
上面提到的许多例子中，还存在一个类似的问题：它们大多选用 IOS 自带的弹框直接做为操作对象。
我始终觉得在 iOS 提供的弹框中，两个操作的按钮颜色保持一致是不对的。
粗细有时候很难被直观感受，而颜色可以在第一时间被感知。
比如前面提到的这个案例：

文章插图
理想情况下，即使用户知道右边是行进，左边是取消，但弹出这个弹框的时候，不免还是需要再次阅读一遍进行确认。
但如果改个颜色，好像就更好理解（当然文案也是问题，但优先级弱于颜色），毕竟弹框也是设计的一部分：

文章插图
需要注意的是，用户既然已经选择取消，就尽量明确的告知用户，不要为了留存而留存，以至于模糊化该弹窗的选择结果。
所以召唤行为，并不是强迫用户去做，而是遵循用户的「旨意」去提供选择。这里的「返回」才是真正的召唤行为，而「取消」并不具备召唤属性。硬生生的给「取消」附上召唤属性，只会让用户在操作时摸不着头脑。
包括下图，我常常因为在使用 App 时，弹出这样的弹框，而不能在第一时间进行正确的点击，选择退出当前的 App 。