Information should appear and fade with the current phase

What it is

HUD visibility need not be constant: different game phases need different information—exploration needs no ability cooldowns, dialogue needs no minimap or ammo counter. Phase-adaptive visibility shows each HUD element only in the phases where it is relevant (ability bar fades in on combat entry, fades out after), turning constant information density into context-sensitive density. This is the core instrument for resolving the conflict between information completeness and visual field cost.

Why it happens

Phase-adaptive display works because information's decision value is phase-bound. An element's value = the probability it influences decisions in the current phase—ammo count drives decisions at high frequency during shooting (reload timing) and at zero during dialogue; displaying it in zero-probability phases is pure occupancy with no return. The design of phase-switch signals determines adaptive visibility's usability: fades (rather than abrupt appearance/disappearance) keep players aware of where information went, so it is never "missing when needed"; trigger conditions must be reliable (a wrong combat detection popping the ability bar during dialogue or dropping it mid-fight is worse than persistent display). Granularity needs layering: whole-HUD show/hide is coarse (photo mode, immersion mode), while per-element phase binding is fine (ability bar follows combat, objective hints follow quest updates)—fine-grained adaptation is the everyday design.

Where it stops holding

Adaptive display does not suit all information. High-frequency critical information (health) must stay persistent or near-persistent—health has value outside combat (lingering poison, trap warning), and re-summoning delay is unacceptable in emergencies. Toggle frequency needs control: in areas where combat and exploration oscillate rapidly (dense encounter zones), elements flickering repeatedly create visual noise and "instability," requiring hysteresis (show immediately on combat entry, hide several seconds after combat exit). Players' trust in adaptive display depends on learnable patterns: within a few hours players should grasp "what appears when"; unpredictable toggling (uninferrable triggers) draws "the UI is fighting me" complaints. Screenshot and streaming users also value a full persistent HUD (showing operational state), so provide a global HUD toggle that overrides all adaptive behaviour.

Applying it

• Define a phase-binding table for every HUD element (which phases show it, trigger conditions, transition duration), keeping high-frequency critical info (health, objective) persistent or merely minimised.
• Use 200-400 ms fades for transitions and add hysteresis to combat detection (hide 3-5 seconds after combat ends) to avoid boundary oscillation.
• Verification: watch tested players after phase switches for position-searching behaviour ("where did my ability bar go") and check whether hidden-to-visible response is timely on sudden encounters. Frequent searching or laggy response means the triggers or transitions need adjustment.

Related

• Same group: W5.07.1 HUD elements occupy the visual field · W5.07.3 Immersion and information completeness trade off
• Nearby: W5.01 Heads-up displays and information layout · I2.03 Pacing and tempo control · F1.01 Interface information density
• Search terms: contextual HUD · adaptive interface · dynamic HUD · combat UI