Claude-Code-Game-Studios/.claude/skills/ux-design/references/sections-hud.md

Section-authoring guidance, loaded by /ux-design for the ACTIVE MODE ONLY. Never load the other two — one mode applies per invocation.

Section Guidance — HUD Design Mode

In this file:

• Section A: HUD Philosophy
• Section B: Information Architecture
• Section C: Layout Zones
• Section D: HUD Element Specifications
• Sections E–L: HUD States, Information Hierarchy, Visual Budget, Feedback & Notification, Platform Adaptation, Accessibility, Tuning Knobs, Acceptance Criteria

HUD design follows a different order from UX spec mode. Begin with philosophy; do not touch layout until the information architecture is complete.

Section A: HUD Philosophy

Ask the user to describe the game's relationship with on-screen information in 1-2 sentences.

Offer framing examples to help:

• "Nearly HUD-free — atmosphere requires unobstructed immersion (e.g., Hollow Knight, Firewatch)"
• "Minimal but present — only critical information visible, everything else contextual (e.g., Dark Souls)"
• "Information-dense — all decision-relevant data always visible (e.g., Diablo IV, StarCraft II)"
• "Adaptive — HUD density responds to combat state, exploration mode, menus (e.g., God of War)"

This philosophy becomes the design constraint for every subsequent HUD decision. If a proposed element conflicts with the stated philosophy, surface that conflict.

---

Section B: Information Architecture

Complete this before any layout work. Do not skip it.

Step 1 — Full information inventory: Pull all information from GDD UI Requirements sections gathered in Phase 2. Present the full list: "These are all the things your game systems say they need to communicate to the player on screen."

Step 2 — Categorization: For each item, ask the user to categorize it:

Category	Description
Must Show	Always visible, player needs it for core decisions
Contextual	Visible only when relevant (in combat, near interactable, etc.)
On Demand	Player must actively request it (toggle, hold button)
Hidden	Communicated through world/audio, never on-screen text

Use AskUserQuestion to step through items in groups of 3-4, not all at once. This is the most consequential design decision in the HUD — do not rush it.

Conflict check: If the information philosophy (Section A) says "nearly HUD-free" but the Must Show list is growing long, surface the conflict explicitly:

"The current Must Show list has [N] items. That may conflict with the HUD-free philosophy. Options: reduce the Must Show list, revise the philosophy, or define a hybrid approach where HUD is absent in exploration and present in combat."

---

Section C: Layout Zones

Only after the information architecture is approved, design layout zones.

Base layout on:

• Which items are Must Show (they drive the permanent zone decisions)
• Where player attention naturally goes during gameplay (center-screen for action games, corners for strategy games)
• Platform and aspect ratio targets

Offer 2-3 zone arrangements. Include rationale based on the HUD philosophy and the categorization from Section B.

---

Section D: HUD Element Specifications

For each element in the layout, specify:

• Element name and category (Must Show / Contextual / On Demand)
• Content displayed
• Visual form (bar, number, icon, counter, map)
• Update behavior (real-time, event-driven, player-queried)
• Contextual trigger (if not always visible)
• Animation behavior (does it pulse when low? Fade in? Slam in?)

Work element by element. Reference the interaction pattern library if relevant patterns exist for status displays, resource bars, or cooldown indicators.

---

Sections E–L: HUD States, Information Hierarchy, Visual Budget, Feedback & Notification, Platform Adaptation, Accessibility, Tuning Knobs, Acceptance Criteria

These parallel the UX spec's States, Interaction, and Accessibility sections. The guidance you need is below — do not load sections-ux-spec.md; one mode file applies per invocation. For the HUD, apply it as follows.

HUD States by Gameplay Context (states over time). Cover at least exploration, combat, dialogue/cutscene and paused — /ux-review checks for all four. Beyond the happy path, capture what changes the HUD mid-gameplay and present it as a table for approval:

State / Variant	Trigger	What Changes
Default	Normal play	—
Low-resource	Health/ammo/etc. below threshold	[element pulses, recolors, …]
Empty / no-data	Element has nothing to show	[hidden, or placeholder]
[etc.]	[trigger]	[changes]

Ask specifically: what causes the HUD to change density mid-gameplay (combat vs. exploration), and what fades, pulses, or slams in on each transition?

Information Hierarchy. Give every element in HUD Element Specifications a priority tier — MUST KEEP, SHOULD KEEP, CAN HIDE or ALWAYS HIDE — with the reason, and what carries its information when it is hidden (a sound, a diegetic cue, or nothing). This is the order the Visual Budget below drops elements in.

Visual Budget. State the maximum number of simultaneous HUD elements and the maximum share of the screen the HUD may cover, and which elements are dropped first when a state would exceed it.

Feedback & Notification Systems. One row per transient notification type (pickup, XP gain, objective update, achievement) — trigger system, screen position, duration, max simultaneous, priority and queue behavior: what happens when two arrive at once, which are held during combat, and which are never queued. /ux-review checks that every notification has queue/priority behavior defined.

Platform Adaptation. Does mobile/console require different element sizes or positions? Note per-platform overrides — touch targets, safe-area insets, and whether any element moves or is dropped on a given platform.

Accessibility. Cross-reference design/accessibility-requirements.md if it exists, then walk this checklist for the HUD:

• Gamepad/keyboard focus order for any interactive HUD element
• Text contrast and minimum readable font sizes at gameplay distance
• Color-independent communication (no state conveyed by color alone — a low-health cue must not be red-only)
• Reduced-motion alternative for any pulsing/flashing HUD animation
• Screen-reader considerations for non-text indicators

If no accessibility tier has been defined for this project, note the gap in the HUD design's Open Questions section (WCAG-AA is a reasonable baseline) and continue without stopping.

Tuning Knobs. List every player-adjustable HUD setting — overall scale, opacity, per-element show/hide, subtitle size — with its range and default.

Acceptance Criteria. At least 5 checkbox criteria a QA tester can verify without reading another document — /story-done closes HUD stories against them. Cover at least: safe-zone margins on every target platform, the correct elements in each gameplay context above, the visual budget (screen share in exploration and in combat), one accessibility criterion for the committed tier, and notification queueing. Section 12 of .claude/docs/templates/hud-design.md has worked examples.