b. 强化「取消按钮」
当我们不希望用户退出某个界面，或停止某个流程时，往往会选择将「取消按钮」强化。
如：
或：
通过对字体的加粗，以暗示用户不要轻易退出。在这个流程里，「取消按钮」具备了「召唤行为」属性。
也有产品通过改变「取消按钮」的文案，让其具备「召唤行为」的属性，使得用户在此过程中轻易不要退出该流程：
这里的「继续选座」就是「取消」，因为这里的「取消」成了「召唤行为」，所以通过改变文案的方式，确保用户留下来继续进行流程中的任务。
但是不可取的是，这里的「返回」反而给了用户一种需要思考的压力。返回？是留在这里，还是退出去？思考几秒后，反应过来，是退出去。这样的文案与只有在看到「继续选座」后进行对比，才能反应过来具体是什么意思，除非是用户具备操作习惯，知道「右边」是「行进」操作，才能很快理解。（当然还有个问题，我们在第三各模块来说明）
但是多数用户还是得思考一下，所以要改，最好两者文案都能改了，否则思考的「停顿」会让用户产生厌恶感。
且在一些产品界面里，为了避免用户在流程中终止行为，甚至会转移「取消」与「行进」两者的位置，如：
之前截图了某个产品的界面，写文这天发现已经改回来，这里就没放了。
各位谨记，最好不要这样进行设计，因为用户在 App 的操作上已经习惯左边取消，右边行进，调换位置虽然能暂时解决用户的退出行为，但容易产生误操作，与用户的期望不同，导致在产品体验上会被用户排斥。
所以到这里，先给一个结论，即在 App 的设计上，行进操作在右，回退操作在左，召唤属性根据场景对按钮做突出处理。
但是「取消按钮」真的应该具备召唤属性么？不着急，我们第三模块再细聊。下面我们先聊聊 Web 与 App 的之间的差异。
c. Web 与 App 的位置差异
我们现在见到越来越多的 Web 端产品，也开始遵循 App 产品的设计，把「取消按钮」放在左边，「召唤行为」按钮放在右边。
但在早期，Web 的「取消按钮」基本是放在右边，原因是鼠标的移动路径是根据眼动规则来，我们的视线会首先与文案聚焦到「召唤行为」的按钮上，也就是左边，这时候鼠标轻而易举地随之而来。
而手指行为的操作，会以右为前进导向，且右手手势因为便捷性，也会以右为确认操作。否则单手持机，且行进路径长的话，用户想进行确认操作会相对比较吃力。
这就是 Web 与 App 在按钮位置上的主要区别。
那会有同学问到说 Web 的「取消」到底是放在左边还是右边？这里我说点自己的想法。
如果根据眼动规则与鼠标的操作模式来说，Web 「取消按钮」当然是放在右边更为合适。但如今人们已经习惯了移动产品的「右行进，左取消」属性，且在界面上的视觉终点一般是在右边，能引导用户进行召唤行为。
但这不具备指导性原则，如果要拆开说，里面还有很多说法。
飞特游客
委托设计