game-ui-ux-framework

name	game-ui-ux-framework
description	Methodology reference for video-game UI/UX design and implementation. Covers the UI design-space model (diegetic / spatial / meta / non-diegetic), the UI technology landscape and how to choose a system, data-driven UI architecture, accessibility grounded in real standards (WCAG 2.2, Game Accessibility Guidelines, Xbox Accessibility Guidelines, the APX model), localisation and fonts, a competency rubric with portfolio gates, and a curated library of free learning materials. Use alongside the game-ux-designer persona when you need a decision tool, a technology comparison, concrete accessibility acceptance criteria, or a study path — not just a stance.
license	MIT
compatibility	Portable reference skill for agents that support markdown skills or prompt files. Works best alongside UI mocks, the project's engine choice, accessibility targets, localisation matrices, and playtest notes.
disable-model-invocation	true
metadata	{"owner":"game-delivery","version":"2.0.0","language":"en-GB","category":"game-ux","tags":["game-ux","ui","hud","design-space","diegetic-ui","data-driven-ui","accessibility","localisation","ui-performance","methodology"],"intents":["diegesis-placement","ui-technology-selection","data-driven-ui-architecture","accessibility-criteria","localisation-planning","competency-assessment"],"output_types":["design-space-map","technology-recommendation","ui-architecture-decision","accessibility-criteria","learning-path"]}

Game UI/UX Framework

Methodology reference for designing and implementing game UI that makes play easier and turns the front-end into a design opportunity, not just a layer of friction. Use when you need a structured decision tool — where a UI element should live relative to the fiction, which UI technology fits the goal, how UI should be wired to game state, what accessibility actually requires, and what to study next.

This reference is engine-agnostic in its principles and names real systems only as a landscape. The actual per-project engine choice belongs in the consuming project's CLAUDE.md, not here.

---

1. The UI design space

Game UI is not a single layer. The most useful model places every element on two axes (after Fagerholt & Lorentzon, Beyond the HUD, popularised by Marcus Andrews):

• Fiction — does the element exist within the game's story/world, or is it for the player only?
• Space (geometry) — is the element rendered in the game's 3D space, or drawn flat on the screen?

This yields four categories:

Category	In the fiction?	In the 3D space?	What it is	Examples
Non-diegetic	No	No	Classic flat overlay drawn for the player	Minimap, ability cooldowns, score, most settings menus
Diegetic	Yes	Yes	UI that characters could see and that lives in the world	Dead Space spine health bar, in-world wrist devices, holographic displays the avatar reads
Spatial	No	Yes	Drawn in 3D space but the character is not aware of it	Waypoint markers, objective pings, enemy outlines, footstep trails
Meta	Yes	No	Part of the fiction but flat on the screen	Blood/cracks on the screen for damage, rain on a "camera lens", HUD framed as a helmet visor

The core conclusion: immersion is earned, not assumed

The most important research finding for this work is that immersive/diegetic UI is not automatically better. A diegetic health bar is only a win if it still reads at game speed. Player-preference research on integrated vs overlay UI finds no necessary link between transparent/diegetic UI and involvement — and that players often overlay UI precisely because it communicates information more clearly and faster.