类似的还有微博，但是微博对于「取消按钮」的类型差异没有做出区分，原因在于它为了弱化界面层的取消，与弹框层的取消样式保持了一致。
虽然没什么太大问题，但从严格的逻辑上来说，这两者取消是存在歧义的。只是用户已经习惯且理解了，所以没要造成使用的负担。
微信的弹框虽然避免了这层歧义，但在操作上还是不够直观，我每次发微信朋友圈，点取消弹出「保留」与「不保留」我都要停顿一下谨慎地进行选择，生怕自己点错。
当然，这里面还有关于颜色的说法。
这时候再对比 Twitter 的界面就能看出设计师之间的差距了。
b. 弹框层「取消」颜色的差异
上面提到的许多例子中，还存在一个类似的问题：它们大多选用 iOS 自带的弹框直接做为操作对象。
我始终觉得在 iOS 提供的弹框中，两个操作的按钮颜色保持一致是不对的。
粗细有时候很难被直观感受，而颜色可以在第一时间被感知。
比如前面提到的这个案例：
理想情况下，即使用户知道右边是行进，左边是取消，但弹出这个弹框的时候，不免还是需要再次阅读一遍进行确认。
但如果改个颜色，好像就更好理解（当然文案也是问题，但优先级弱于颜色），毕竟弹框也是设计的一部分：
需要注意的是，用户既然已经选择取消，就尽量明确的告知用户，不要为了留存而留存，以至于模糊化该弹窗的选择结果。
所以召唤行为，并不是强迫用户去做，而是遵循用户的「旨意」去提供选择。这里的「返回」才是真正的召唤行为，而「取消」并不具备召唤属性。硬生生的给「取消」附上召唤属性，只会让用户在操作时摸不着头脑。
包括下图，我常常因为在使用 App 时，弹出这样的弹框，而不能在第一时间进行正确的点击，选择退出当前的 App。
这样例子还有很多。
但是我觉得做得好的，应该是这样的：
或：
这就是刻板印象造成的结果。我们应该学会适当地使用控件，并根据自己的产品对其进行优化。而不是一味跟风。
综上所述：界面层的取消，为了表示其作用性的不同，且界面元素众多，突出颜色是没问题的；但弹框层的取消与确认在颜色上没做区分，直接用不太明显的粗细效果让用户聚焦于这两个内容的选择上，其实是不友好的设计。
如果对 iOS 设计规范有足够的了解的同学就能知道：它们在弹框控件上给出的两个选择都不是真正意义上的召唤行为按钮，只是常规内容，且更适用于产品开发，而不是设计指导。
如果你仔细观察 macOS 的设计，就能发现他们为具备召唤行为的按钮位置与颜色都做了特殊处理，并不是简单的同色系，或用粗细表示。如图：
虽然用 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，就会有一种「哇哦！原来如此！」的感触了。
所以我这篇文章的内容结论是：
位置固定，左回退，右行进；
颜色区分，左浅色，右深色；
召唤行为不是用户想做的事，而是我们应该要让用户做的事，但不是强迫，所以正常情况下，「取消按钮」通常不具备召唤属性。
可能有人会觉得，这么一个小问题，不至于用这么长一篇文章来说明，不过人么，就是存在这样那样的区别。我认为需要就可以了。
本来这篇文章还有一段关于「手势按钮尺寸」的内容，不过到目前为止，文章内容太长了，所以我暂时去掉了，会在之后的文章里分享给大家。
当然，到此为止，我聊的内容基本适用于通用场景，且适用于大部分的产品设计，但在一些特殊场景下的按钮位置、颜色，也会有不同设计方式，这就要根据具体问题来具体分析。
我这里只是把「取消按钮」的设计差异、细节提供给大家，以便帮助各位在工作中有更深入的思考，而不是想当然的说就是放左边或右边，或者就应该是什么颜色等等。包括对待其他内容也一样。
那这篇文字就到这里了，谢谢阅读：）
FEVTE编注：更多平面设计理论学习请访问飞特网平面设计理论知识栏目，地址：https://www.fevte.com/plan/shejililun/
飞特游客
委托设计