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

也有产品通过改变「取消按钮」的文案，让其具备「召唤行为」的属性，使得用户在此过程中轻易不要退出该流程：

文章插图
这里的「继续选座」就是「取消」，因为这里的「取消」成了「召唤行为」，所以通过改变文案的方式，确保用户留下来继续进行流程中的任务。
但是不可取的是，这里的「返回」反而给了用户一种需要思考的压力。返回？是留在这里，还是退出去？思考几秒后，反应过来，是退出去。这样的文案与只有在看到「继续选座」后进行对比，才能反应过来具体是什么意思，除非是用户具备操作习惯，知道「右边」是「行进」操作，才能很快理解。（当然还有个问题，我们在第三各模块来说明）
但是多数用户还是得思考一下，所以要改，最好两者文案都能改了，否则思考的「停顿」会让用户产生厌恶感。
且在一些产品界面里，为了避免用户在流程中终止行为，甚至会转移「取消」与「行进」两者的位置，如：

文章插图
之前截图了某个产品的界面，写文这天发现已经改回来，这里就没放了。
各位谨记，最好不要这样进行设计，因为用户在 App 的操作上已经习惯左边取消，右边行进，调换位置虽然能暂时解决用户的退出行为，但容易产生误操作，与用户的期望不同，导致在产品体验上会被用户排斥。
所以到这里，先给一个结论，即在 App 的设计上，行进操作在右，回退操作在左，召唤属性根据场景对按钮做突出处理。
但是「取消按钮」真的应该具备召唤属性么？不着急，我们第三模块再细聊。下面我们先聊聊 Web 与 App 的之间的差异。
c. Web 与 App 的位置差异
我们现在见到越来越多的 Web 端产品，也开始遵循 App 产品的设计，把「取消按钮」放在左边，「召唤行为」按钮放在右边。
但在早期，Web 的「取消按钮」基本是放在右边，原因是鼠标的移动路径是根据眼动规则来，我们的视线会首先与文案聚焦到「召唤行为」的按钮上，也就是左边，这时候鼠标轻而易举地随之而来。
而手指行为的操作，会以右为前进导向，且右手手势因为便捷性，也会以右为确认操作。否则单手持机，且行进路径长的话，用户想进行确认操作会相对比较吃力。
这就是 Web 与 App 在按钮位置上的主要区别。
那会有同学问到说 Web 的「取消」到底是放在左边还是右边？这里我说点自己的想法。
如果根据眼动规则与鼠标的操作模式来说，Web 「取消按钮」当然是放在右边更为合适。但如今人们已经习惯了移动产品的「右行进，左取消」属性，且在界面上的视觉终点一般是在右边，能引导用户进行召唤行为。
但这不具备指导性原则，如果要拆开说，里面还有很多说法。
比如 windows 和 macOS 的设计规范里「取消按钮」的位置完全是相反的。win 的取消在右，macOS 的取消在左。

文章插图

文章插图
两套体系的按钮位置相互矛盾。这件事本身也说明，只要你在你的 Web 产品里规范好自己的设计体系，就没有对错之分。不要一会儿这个「取消」在左边，一会儿那个「取消」又在右边，给用户造成认知障碍即可。
但是！我更推崇 macOS 的设计规范。原因在于成熟度与一致性。
主观因素：众所周知，苹果是更擅长做设计的公司，体验过 Mac 的朋友应该能理解我说的这句话。一般来说，我只听过从 Win 切换到 Mac 的，没有说从 Mac 切换到 Win 的，除了少部分因为工作需求需要同步使用的。
客观因素：移动产品的普及，已经有相当成熟的设计体系支持行进按钮右侧化设计，统一 Web 或 PC 产品只会让用户的操作行为更方便。
这就是我本小节想聊的，关于 Web 与 App 按钮设计的差异。
「取消按钮」的正确解法
我相信，只要是平时稍微有认真观察的同学，都能知道我上述聊的内容。我个人也不认为这些内容具备任何需要总结的价值。但是如果不写出来，就没办法说明我接下来要聊的内容，也是我这篇文章的重点部分。
通过上述内容，我以不同类型的按钮案例来解释「取消按钮」的控制权。各位可以看出，即使是不同类型的「取消按钮」，在权重上的道理也都是一样的。