Critical prompts cannot rely on merely appearing on screen

What it is

A common acceptance criterion for judging whether a prompt is "designed correctly" is that it appears on screen — it renders, its color is salient enough, its position is within the visible viewport. But that is only existence in the engineering sense; it does not mean the user will actually notice it. If a piece of critical information (an error message, a legal notice, a safety warning) satisfies only "it appears on screen," the risk of it being missed is already baked in at the design-acceptance stage.

Why it happens

"Appears on screen" answers exactly one question — were the pixels drawn? It answers neither of the two questions that actually matter: does the user have spare attentional capacity right now (which depends on the primary task's current perceptual load), and even if gaze sweeps across that region, does the signal get processed to a reportable level (which depends on whether attention was genuinely allocated there, not just that the eyes passed over it). Each question maps to an independent failure path; failing either one means the prompt gets missed.

What makes this worse is that the failure is invisible during design review: when a designer looks at their own mockup, their perceptual load is zero and their gaze necessarily lands on the prompt — the act of reviewing itself manufactures the illusion that "this prompt will definitely be seen," precisely when the real usage context satisfies neither of the two preconditions that made the review pass.

Where it stops holding

• This entry only addresses whether a prompt will be seen at all — not whether, once seen, it is understood or complied with. Those are downstream concerns with different solutions and should not be handled with the same toolkit.
• It does not apply to information users are expected to actively search for (help documentation, optional settings), because the design goal there was never "guarantee it is seen" but "make it findable when needed."

Applying it

Acceptance checks for critical prompts should include at least the following:

• Assess the primary task's perceptual load at the moment the user would encounter the prompt. High-load scenarios (urgent operations, multi-step flows) cannot be fixed just by making text bigger or contrast higher — consider interrupting the primary task directly (a forced modal prompt rather than a dismissible non-modal one).
• Place the prompt near the user's current fixation point, rather than assuming users will actively scan elsewhere on the interface to find it.
• For information that must be acknowledged, require an action that can only be completed after the content has genuinely been processed — for example, requiring a scroll-to-bottom before the confirm button activates, rather than a dialog that can be dismissed the instant it appears. This turns "was it processed" into a verifiable behavior instead of resting on the weaker standard of "was it displayed."
• Avoid throwing multiple critical prompts at the user at once. Simultaneous prompts dilute the attentional resource each can claim; stagger them instead of dumping them all at once.
• Verification: do not accept "I can see it during design review" as evidence — the reviewer's perceptual load is inherently zero, so this test will always pass. Use a detection test set in a real task context instead: have users perform the primary task while observing whether they spontaneously report the prompt and can recall its content, separately verifying that attention was allocated there and that the signal reached a reportable processing level.

Related

• Same group: A5.05.1 Attention occupied elsewhere means even obvious objects go unseen · A5.05.2 Being in the visual field is not the same as being seen
• Nearby: A5.09 Cognitive tunneling · A10.14 Forcing functions and interlocks
• Search terms: critical alert design · forced interaction · acknowledgment pattern · modal interruption