Interface

What this element is

The interface is where hardware and software meet to enable the player's interaction with the game world — Flanagan and Nissenbaum call it the intersection of software and hardware that facilitates a player's game interactions. In the projects studied it spans controllers, tablets, VR hand tracking, and even a brake pedal that doubles as a continue button.

Why it carries values

Interface choices decide who gets to play, how they play, and which behaviours are allowed or forbidden. A menu is never just a menu: it sets the rhythm of the game, embeds your safety or pedagogical priorities into the controls themselves, and — in clinical work — can even determine whether your results are scientifically valid. Interfaces don't just transmit information; they convey values.

Patterns from practice

Simplicity

Simplicity is not minimal aesthetics for its own sake — it is a guarantee that the game will be accessible, clear and empowering. The medical VR developer was blunt: the interface "needs to be as simple as possible in every respect, even at the consequences of some aesthetics" (P1), because the simulation fails if trainees can't figure out and manipulate the equipment. Beauty is expendable; clarity is not.

In clinical games, simplicity collides with a harder constraint: consistency. The early childhood assessment project had to balance making the UI more accessible against not changing it, because altering the interface too much would undermine the comparability that evidence-based practice depends on. Every UI improvement risked invalidating the clinical baseline — an ongoing bind for any serious game that requires clinical testing and approval.

Context

Interface design is always contextual — shaped by users' abilities, the hardware, and the project's pedagogical aims. The developer working with disabled adults and children on tablets embraced a deliberately narrow input set — "swipe, pinch, tap" (P8) — matching the interaction space to users' capabilities rather than building complicated control schemes. Constraint, here, is inclusion.

The learner-driver game tunes every interface component to the driving context: an oversized speedometer, prominent red traffic lights and GPS that cut through clutter within the limits of screen resolution. Most tellingly, progress is linked to the brake pedal — the first thing every student learns is to hit the brake. Safety and caution are literally wired into the controls, making the interface itself a learning tool.

User-centred design

The physiotherapy games show user-centred design as a negotiation between groups who value different things. The developer called "balancing the games" one of the hardest parts, juggling "gaming ability and gaming familiarity," "physical ability," and "stage of recovery" (P2). For patients, the interface supports self-awareness without judgement: the balance heat map "doesn't make any claims" about where they should have been, it simply lets them "be, as a player, more aware" (P2). Avoiding "numbers or percentages" (P2) is a values decision — non-stigmatising feedback and motivational support during rehabilitation.

The physiotherapist-facing interface embodies the opposite system: precision, control, professional efficiency. Clinicians "want the numbers, they want the data, they want as much information as you can give them" — but they're "extremely time poor," so summaries must land "within seconds" with deeper inspection available on demand (P2). The team's decision to maintain "two interfaces for very different users" (P2) is the key move: it accepts that one UI cannot serve lay and expert needs without compromising core values for one group. Patient empowerment and clinical decision-making are treated as parallel goals, not a hierarchy.

Questions to ask your team

1. What's the least experienced, least able user we intend to serve — and can they operate this interface unaided?
2. Where have we chosen aesthetics over clarity? Would we defend that choice if a trainee failed because of it?
3. Which of our learning or safety priorities are built into the controls themselves, and which are only in the content?
4. Does any part of our interface pass judgement on the player — scores, red marks, percentages? Should it?
5. Do our different user groups (learners, teachers, clinicians, carers) actually need different interfaces rather than one compromise UI?
6. If our game needs clinical or regulatory validity, which parts of the interface are now frozen — and does everyone on the team know?
7. When users told us the interface confused them, did we simplify it — or explain it?