做产品，我为什么如此小题大做：一个 checkbox，为什么移下去又移了回来？
有一次，我让人把一个勾选框往下挪。实际用过以后，又让人把它挪了回去。
两个控件换个位置，来回折腾，看起来确实没什么大不了。但这次往返让我重新想了一件事：界面上的先后，究竟应该跟着阅读走，还是跟着操作走？
事情发生在 FooCloud 的 iOS 下载流程里。下载文件时，如果目标位置已经有同名文件，就需要决定怎么处理：覆盖、跳过，或者两份都保留。
如果正在下载一批文件，总不能每遇到一个同名文件，就让人重新回答一次。因此，面板里还有一个勾选框，可以把选择应用到本次任务后续的同类冲突。
最初，勾选框在上面，几个处理按钮在下面。我提出调换：先展示处理方式，再展示是否批量应用。
从阅读的角度看，这很顺：先知道有什么选择，再决定这个选择管多大范围。
可是用起来，我觉得原来的顺序更自然，于是又改了回去。
图 1：依据历史讨论复原排列关系，非产品截图。为便于比较，文案简化；文件名为示例。
重新审视这个交互，我会这样解释当时那种“不太对劲”的感觉。
这里的“覆盖”“跳过”“保留两份”，都是点下去就执行的按钮。它们并不是先选中，等你把整个面板看完，再按一个“确定”。
两种动作在视觉上可能很像，后果却不同。
如果先看到“保留两份”，觉得合适就点了，这次处理已经发生。放在下面的勾选框，可能还没进入视线。即使按钮没有引起误解，操作也可能早于用户对范围的判断。
这是一种可以从流程里看见的风险。我没有误操作比例来证明它有多常见，也不能说每个人都会这样点。但设计时，没有必要把这一步完全交给用户自己防备。
经典可用性原则里的错误预防，就包含这种考虑：与其等人操作之后再纠正，不如先看看界面的安排能否减少出错机会。Nielsen Norman Group 讨论操作失误时，也强调通过设计帮助用户避免无意的错误。关于错误预防
具体到这里，适用范围会影响按钮执行的后果，那么它就应该在执行之前有机会被看见、被决定。
我把勾选框移回上方，是让界面上的顺序更贴近这条操作链：先决定影响范围，再执行处理。
当然，上方也有上方的问题。用户可能还没看清有哪些处理方式，就先碰到“应用于本次任务”。这个选项到底应用什么，需要后面的按钮和旁边的说明一起解释。
所以，仅仅把框挪上去还不够。它必须说清适用边界：当前任务里的同类冲突，而不是今后所有下载。默认不勾选，也给逐个处理保留了空间。
还有另一种值得比较的做法：把处理方式改成单选项，选好策略和范围，最后统一确认。
图 2：本次分析提出的替代方案，未在 FooCloud 中实施。圆形选择项只记录选择，底部确认按钮才执行。
这样一来，“策略在上、范围在下”就又合理了。用户可以从上往下读完，最后检查一次，再让操作生效。
它的代价也很清楚：每次处理多一个确认步骤，面板里多一种控件。对于经常需要迅速处理单个冲突的人，这一步可能显得拖沓；对于后果更重、需要复核更多条件的操作，这一步又可能值得。
也就是说，同一个勾选框放在哪里，不能脱离按钮如何生效来讨论。
假如我只把两张静态稿摆在一起，很容易围绕对齐、留白、阅读顺序争论半天。可是一旦把手指真正点下去，问题就具体了：这一下之后，用户还来得及改变什么？
当前 FooCloud 保留的是即时处理。因此，我接受先看范围、再点动作的安排，以及它需要额外说明的代价。
这次改回去也提醒了我：设计判断允许被实际使用修正。提出过一个方案，并不意味着之后就要替它辩护到底。
我更愿意在设计这类面板时，把几个动作完整走一遍：哪些是在阅读，哪些是在选择，哪一下开始产生后果。凡是会改变后果的条件，都应该在那一下之前安排妥当。
一个勾选框的上下位置，就这样从排版问题，变成了产品替用户考虑操作后果的问题。