做产品，我为什么如此小题大做：同一个提醒，为什么有时必须弹，有时不该弹？
我曾经要求把一个提示直接弹出来。过了一阵，又抱怨它为什么一打开 App 就弹。
听起来前后矛盾，但两次使用的情境不同。
这件事发生在 FooCloud 的 iOS 下载过程中。下载遇到同名文件，需要用户决定覆盖、跳过，或者保留两份。相关下载任务会等这个决定。
最初，界面通过顶部提示告诉用户有冲突，需要点击才能打开处理面板。我担心那个提示看起来更像一条通知：告诉你发生了什么，却没有充分表达“这里需要你操作”。
用户刚发起下载，正在等它往下走。如果这时必须作出选择，我倾向于把处理面板直接摆到面前，让问题和可用的动作一起出现。
于是，新冲突开始自动弹出。接着，另一个问题出现了：重新进入 App，也可能被旧冲突拦住。
旧问题确实还在，但这次打开 App，我未必是回来处理它的。也许只是想找另一个文件，也许想上传一份新资料。之前那个任务，为什么有资格抢在我这次的意图前面？
图 1：依据实际调整整理的情境示意，非产品截图；不表示用户一定按这三个步骤操作。
这次反复让我意识到，提醒设计里有两个不同的判断：这件事是否需要用户知道，以及它是否值得立刻打断用户。
需要知道的信息，并不天然拥有打断的资格。
经典可用性原则要求系统状态可见，让人知道发生了什么。但可见可以通过位置、标记、进度、文字等多种方式实现，弹窗只是其中一种。关于系统状态可见性
当用户正在前台进行下载，一个新冲突挡住了这次任务，直接处理有明确的上下文：刚刚的操作为什么停下来了，要做什么才能继续。
当用户重新回来，旧冲突与当前意图的关系就弱了。系统知道它尚未解决，却不知道用户此刻是否打算解决。把“尚未完成”一律翻译成“现在就处理”，很容易越俎代庖。
FooCloud 最后的安排，是区分这两类情况：前台新产生的冲突可以自动展示；已经存在的冲突保留在相应条目上，由用户主动打开。
这也意味着，要把“留在那里”做得足够明确。一个不自动弹出的提醒，如果被藏到没人发现的角落里，也没有完成任务。
因此，冲突入口和发生问题的文件、文件夹放在一起。文件的警告在下载按钮旁边；文件夹的警告使用原来图标的位置，名称仍然可以点进去浏览。
图 2：当前条目结构的局部示意，非产品截图。文字标注用于解释操作分工，实际列表不显示这些注释。
两种条目没有机械地使用同一个位置。我更在意的是，人能把警告和具体对象联系起来，同时继续完成浏览或下载这些原本的动作。
这种安排也有代价：用户不一定立刻看到列表里的旧冲突。如何让标记容易发现、容易点到，仍然需要在真实列表里检查。减少自动弹出，并不等于可以降低提醒本身的可发现性。
这次打磨还牵出了另一个词：取消。
曾经讨论过“稍后决定”，但这句话很容易让人产生不同理解。它到底是关闭面板，让没有冲突的文件继续下载，还是把整个相关任务留在原地等待？
如果产品只能做到其中一种，含糊的文案就可能让另一种期待落空。
最终，我要求这里的取消有明确结果：结束这次下载任务，已经下载好的文件保留。以后要重新下载，就重新选择目录、发起任务。它不能给人一种“先放着，回来会自然接着走”的暗示。
一个弹窗什么时候出现，和人如何离开它，其实属于同一个问题：产品是否尊重用户对当前任务的控制。
我愿意为此来回调整。新冲突出现时，直接弹出可能是在帮人接住刚刚的操作；旧冲突在再次启动时扑上来，却可能妨碍下一件事。
判断一个提醒，我会先把那一刻补完整：用户刚做了什么，什么被挡住了，如果此时不打断，他还能从哪里找到它。
时机对了，同一个面板才有可能从干扰变成帮助。