A5.05.3On-screen presence is not a detection guarantee设计
关键提示不能只靠出现在屏幕上
别名: 强制确认 · acknowledgment pattern · critical alert design
概念解释
判断一条提示"设计得对不对"，常见的验收标准是"它出现在了界面上"——渲染出来了、颜色够醒目、位置在可视区域内。但这只是工程意义上的"存在"，不等于用户真的会注意到它。关键信息（错误提示、法律条款、安全警告）如果只满足"出现在屏幕上"这一条，在设计验收阶段就已经埋下了被漏掉的风险。
机制
"出现在屏幕上"只回答了一个问题——像素有没有被绘制出来；它完全没有回答另外两个更关键的问题：用户当前的注意力资源有没有富余（取决于主任务当下的知觉负荷），以及即便目光扫过那个区域，信号有没有被加工到能被报告的层级（取决于注意力有没有真正分配过去，而不只是目光路过）。这两个问题分别对应两条独立的失效路径，只要一条不满足，提示就会被漏看。
更麻烦的是，这条失效在设计评审阶段完全不可见：设计师自己盯着稿子看的时候，知觉负荷是零，目光必然落在提示上——评审这个动作本身就制造了一个"这条提示肯定会被看到"的假象，而真实使用场景里恰恰不满足这两个前提。
边界
- 这条只处理"提示是否会被看见"这一层，不处理看见之后是否理解、是否愿意遵从——那是下游的另一套问题，对策也不同，不能用同一套手段解决。
- 对于本来就要求用户主动搜索的信息（帮助文档、可选设置项），不适用这条，因为这类信息的设计目标本来就不是"确保被看见"，而是"需要时能找到"。
怎么落地
给关键提示做设计验收，至少检查以下几条：
- 判断用户看到它时，当前主任务的知觉负荷处在什么水平。 高负荷场景（紧急操作、多步骤流程）不能只靠加大字号或提高颜色对比来解决，需要考虑直接打断主任务本身（强制模态提示，而不是可以被忽略的非模态提示）。
- 提示位置要在用户当前任务的注视焦点附近，不能假设用户会主动扫视界面其他区域去发现它。
- 对必须被确认的信息，要求一个只有真正处理过内容才能完成的动作——比如要求滚动读完才能点击确认，而不是弹窗一出现就能顺手点掉。这样能把"是否被处理过"变成可验证的行为，而不是停留在"是否被显示过"这个更弱的标准上。
- 避免把多条关键提示同时抛给用户。 同时出现的提示会互相稀释彼此能占用的注意资源，应该分先后处理，而不是一次性堆出来。
- 验证办法：不要用设计评审时"我自己能看到"作为验收依据——评审者的知觉负荷天然是零，这个测试永远会通过。应该用真实任务场景下的检出测试：让用户在专注完成主任务的同时观察提示是否被主动报告、内容能否被复述，分别验证注意力是否被分配过去、信号是否被加工到了可报告的层级。