How to Design a One-Level Game Interface and Navigation Tools (HUD, Menus and Maps)

A one-level interface is the complete set of screens and on-screen elements a player needs to play a single level of a game: a way to start, a heads-up display (HUD) during play, a pause option, and a clear end screen for winning or losing. Navigational tools are the parts of the interface that help players find their way – both through the menus (buttons, tabs, back arrows, level select) and through the game world (maps, mini-maps, compasses, waypoints and signposts). Both are forms of graphic design: arranging type, icons, colour and space so information is quick to read.

This is a hands-on lesson that puts earlier theory to work. Review The Game UI Design Process and How to Tell Good UI From Bad UI and How to Wireframe a Game User Interface before you start.

Part 1: Designing a one-level interface

Treat one level as a mini-game with a beginning, middle and end. Plan these screens and states:

Screen or stateWhat it needsGraphic design tips
Title / startGame title, “Play” button, optional settings and credits.One dominant button; the title uses the game’s key colours and font.
Level introLevel name and goal (“Collect 20 shells before sunset”).Short text plus an icon; fade out after 2–3 seconds or on a tap.
Gameplay HUDOnly essential information: lives or health, score or progress, timer, pause button.Place at the edges and corners; use icons with numbers; consistent colours.
Pause menuResume, restart, settings, quit.Darken the game behind the menu; “Resume” selected by default.
Win screenCelebration, score, stars or rewards, “Next” or “Replay”.Animated reward, big readable score, clear next step.
Lose screenEncouraging message, reason for losing, “Try again”.Friendly tone; show how close the player got.

Graphic design basics for game interfaces

  • Typography: use one display font for titles and one very readable font for everything else. Keep text short and large enough for the platform.
  • Icons: draw simple, bold icons with the same line thickness and style. Test that each is recognisable at small sizes.
  • Grid and alignment: line elements up on an invisible grid and keep equal margins around the screen edges (a “safe area”, important on TVs and phones with notches).
  • Colour and contrast: use the game’s palette, but make sure text and important icons have strong contrast with the background.
  • Theme: the frames, buttons and fonts should look like they belong to the game world – driftwood buttons for a beach game, glowing panels for a space game.

Part 2: Designing navigational tools

Menu navigation

  • Keep menus shallow: players should reach any option in two or three steps.
  • Always provide a Back button in the same place, and support the controller’s back button or the Escape key.
  • Show the current selection clearly with a highlight, outline or animation.
  • Use breadcrumbs or titles (“Settings › Audio”) so players know where they are.
  • Make it work with every input the game supports: touch, mouse, keyboard and controller.
Game menu with a grid of character icons, a selected kart preview and stat bars
Figure 1 – The kart selection screen in SuperTuxKart: a grid of characters, a highlighted current choice, stat bars and clear buttons along the bottom. Image: QwertyChouskie, CC BY-SA 4.0, via Wikimedia Commons.

In-world navigation

  • Maps and mini-maps show the player’s position, goals and explored areas.
  • Compass bars and waypoints point towards objectives.
  • Environmental signposting guides without any HUD: lights, paths, colour, open doors and landmarks draw players forward.
  • Breadcrumb trails – coins or collectables placed along the intended route – quietly show the way.
Blue map of connected rectangular rooms and corridors drawn on a light background
Figure 2 – An automap from the free game Meritous. Explored rooms are drawn automatically as the player moves, helping them navigate a large maze. Image: Lancer-X/ASCEAI, CC BY-SA 3.0, via Wikimedia Commons.

Game director Masahiro Sakurai explains why menus should express the personality of your game world, not just list options:

Example

For a single beach level called Shell Seeker, a student designs: a title screen with a driftwood “Play” button; a level intro card (“Find 20 shells before the tide comes in”); a HUD with a shell counter (top-left), a tide timer drawn as a rising wave (top-right) and a pause button; a pause menu on a wooden sign; a win screen with up to three starfish for speed; and a lose screen saying “The tide won this time – you found 16 shells!”. For navigation she adds a small mini-map in the bottom-right corner showing shell locations the player has already spotted, and places seagulls that circle above hidden shells as in-world signposts.

Exercise

  1. Choose a level idea and list every screen and HUD element it needs, using the table above.
  2. Draw the full one-level interface: title, level intro, HUD, pause, win and lose screens. Apply at least three graphic design tips.
  3. Design a menu flow with a Back button and breadcrumbs, and one in-world navigational tool (mini-map, compass or signposting).
  4. Build the screens in Scratch, Construct or any tool (or as linked slides) and ask someone to navigate them without help. Record where they got stuck.

Next: Designing Game Characters for Different Genres: Life Drawing, Skeleton, Muscles and Facial Expressions

Syllabus link: This post is relevant to the CAPE® Animation and Game Design Syllabus, Unit 2: Interactive Design and Game Development, Module 3: Animation for Games – Specific Objective 1 (“design a one level interface”); Specific Objective 2 (“design navigational tools”).

Attributions to media used in this post:

SuperTuxKart kart selection screen 2018.png – QwertyChouskie – CC BY-SA 4.0 (via Wikimedia Commons)

Meritous-automap.png – Lancer-X/ASCEAI – CC BY-SA 3.0 (via Wikimedia Commons)

© 2026 Vedesh Kungebeharry. All rights reserved.

The Game UI Design Process and How to Tell Good UI From Bad UI

Game user interface (UI) design is the planning and creation of everything players use to understand and control a game: menus, buttons, the heads-up display (HUD), icons, prompts, maps and feedback effects. The UI design process is the sequence of steps designers follow to create it. Good UI lets players focus on playing; bad UI gets in the way, confuses or frustrates.

This lesson builds on Module 1’s User Experience (UX) Factors and the Five Key Principles of Interaction Design and How to Wireframe a Game User Interface. Now we look at the process specific to games and at how to judge a UI.

The process of UI design for games

  1. What are the inputs and outputs? List everything the player must do (inputs: move, jump, pause, choose items) and everything the game must tell them (outputs: health, score, objective, danger). Also decide which devices you support – touch, controller, keyboard.
  2. Prioritise. Rank the outputs by importance and frequency. Critical, constantly changing information (health, timer) goes in easy view; rarely used options go in menus.
  3. Find affordances. Choose shapes, icons and behaviours that suggest their function – a glowing door looks enterable, a raised button looks pressable. Use familiar conventions wherever possible.
  4. Give immediate feedback for your inputs. Every press needs a visible and audible reaction within a fraction of a second: a button animates, a sound plays, the character responds.
  5. Reduce everything. Remove anything unnecessary. Can two screens become one? Can a number become a simple bar? Can information appear only when it matters (for example, the ammo counter showing only when you are low)?
  6. Prototype. Build quick wireframes and clickable or playable mock-ups.
  7. Playtest. Watch players use the UI, note where they hesitate, and repeat the process.
Diagram of the Star Fox screen with labels for lives, boss health bar, the player’s ship, shield, accelerator gauge and bombs
Figure 1 – A labelled diagram of the Star Fox interface. Each HUD element – the shield (player’s health), lives, available bombs, accelerator gauge and boss health bar – sits at the edge of the screen so the centre stays clear for flying. Image: Jean-Frédéric, CC BY-SA 4.0, via Wikimedia Commons.

Heuristics of user interface design

A heuristic is a rule of thumb. Jakob Nielsen’s ten usability heuristics are widely used to evaluate interfaces, including game UIs:

HeuristicIn a game
1. Visibility of system statusShow loading progress, whether the game saved, and current health or objectives.
2. Match between system and the real worldUse words and symbols players know: a heart for health, a map icon for the map.
3. User control and freedomAllow players to go back, cancel, skip cut-scenes they have seen and undo mistakes.
4. Consistency and standardsThe same button confirms everywhere; icons keep one meaning.
5. Error preventionAsk “Are you sure?” before deleting a save; grey out actions that are not possible.
6. Recognition rather than recallShow button prompts and item icons instead of making players memorise them.
7. Flexibility and efficiency of useShortcuts and quick menus for experienced players; remappable controls.
8. Aesthetic and minimalist designShow only what matters now; keep the HUD clean.
9. Help users recognise, diagnose and recover from errorsClear messages: “Not enough coins – you need 20 more.”
10. Help and documentationA tutorial, a help menu, and tips that can be revisited.

Guidelines for game UI

  • Keep the centre of the screen clear for gameplay; put HUD elements near the edges.
  • Make text readable from the player’s viewing distance (a TV across the room needs larger text than a phone).
  • Support the platform: full controller navigation on consoles, large touch targets on phones.
  • Use colour, shape and sound together so information is not lost (colour-blind and deaf players).
  • Match the style of the UI to the game’s art and theme, so it feels part of the world.
  • Let players adjust settings: text size, subtitles, volume, control layout.
Diagram of the Lunar Lander screen: a line-drawn lunar landscape, the lander and readouts for score, time, fuel, altitude and speed
Figure 2 – The interface of the arcade game Lunar Lander (1979, labels in French). Even early games displayed key status – fuel, altitude and speed – clearly around the play area. Image: FR, CC BY-SA 4.0, via Wikimedia Commons.

Good and bad UI: examples

Good UIBad UI
Health bar that flashes and beeps when low.Health shown only as a small number in a corner.
Inventory sorted by type with clear icons and names.Long unsorted list of text with tiny font.
Pause menu opens instantly and stops the game.Pause takes several seconds or does not stop the action.
Button prompts match the controller the player is using.Keyboard prompts shown to a controller player.
Objective marker appears when players seem lost.No indication of where to go; objectives hidden in a sub-menu.
Settings let players remap controls and resize text.Fixed controls and tiny text that cannot be changed.
Racing game screenshot with kart on a track and HUD elements in the corners
Figure 3 – An in-race HUD from SuperTuxKart: the race timer, lap and position counter, track mini-map and speedometer sit around the edges, leaving the track clear. Image: QwertyChouskie, CC BY-SA 4.0, via Wikimedia Commons.

This short PixelUX video summarises five UI principles that professional game designers use every day:

Example

A student applies the UI process to a tower-defence game for tablets. Inputs: tap to place towers, drag to scroll, tap to upgrade. Outputs: coins, lives, wave number, tower range. After prioritising, coins and lives go top-left, the wave counter top-right, and tower range only appears while placing a tower (reduce everything). Towers that cannot be afforded are greyed out (affordance and error prevention). Each tower placement plays a “thunk” and a dust puff (feedback). In the first playtest, players could not find how to upgrade towers, so the designer added a small arrow icon that appears above towers when an upgrade is affordable – then tested again.

Exercise

  1. List the inputs and outputs for a game you play, then rank the outputs from most to least important.
  2. Evaluate that game’s UI using Nielsen’s ten heuristics. Give each a score out of 5 and identify its best and worst features.
  3. Find one example of good UI and one of bad UI in any game or app. Explain why using a heuristic or guideline from this post.
  4. Redesign one bad UI screen using the seven-step process. Sketch the before and after versions.

Next: Game Camera Views: Static, Scrolling, Parallax, First-Person, Third-Person, Isometric and Top-Down

Syllabus link: This post is relevant to the CAPE® Animation and Game Design Syllabus, Unit 2: Interactive Design and Game Development, Module 2: Game Design and Development – Specific Objective 14 (“state the process of User Interface design for games”); Specific Objective 15 (“distinguish between good and bad user interface design for games”).

Attributions to media used in this post:

Star Fox interface (English).png – Jean-Frédéric – CC BY-SA 4.0 (via Wikimedia Commons)

Lunar Lander (1979 video game) Interface (French).png – FR – CC BY-SA 4.0 (via Wikimedia Commons)

SuperTuxKart in-race (2018).png – QwertyChouskie – CC BY-SA 4.0 (via Wikimedia Commons)

© 2026 Vedesh Kungebeharry. All rights reserved.

How to Wireframe a Game User Interface: Best Practices for Designing Interactions

A wireframe is a simple, black-and-white sketch of a screen that shows where things go and how they work, without colours, final art or detailed graphics. In game design, wireframes are used to plan the user interface (UI): the title screen, menus, the heads-up display (HUD), pop-ups and the game-over screen. Best practices for designing interactions are the proven habits and questions designers use so that those screens are clear, fast and comfortable to use.

Wireframing comes after you understand your players and the principles from User Experience (UX) Factors and the Five Key Principles of Interaction Design. It comes before you spend hours on pixel art or code, because moving a box on paper takes seconds and moving finished artwork takes days.

Questions to consider when designing for interaction

Before you draw a single box, work through these questions (adapted from the U.S. government’s usability.gov guide to interaction design). Each one is a best practice in disguise.

QuestionBest practice it leads to
What can a user do with a mouse, finger, controller or keyboard to interact with this screen?Design for the real input device: big touch targets on phones, full controller navigation on consoles.
What about the appearance of an element gives the user a clue about what it does?Use clear affordances and signifiers: buttons look pressable, selected items are highlighted.
Do error messages tell the user how to fix the problem and why it happened?Prevent errors where possible and give helpful, friendly recovery messages.
What feedback does the user get after an action?Give immediate feedback with sound, animation or a change on screen.
Are elements of a reasonable size and easy to reach?Respect ergonomics: place frequent actions where thumbs and fingers naturally rest.
Are familiar or standard formats used?Follow conventions (pause in the top corner, settings behind a gear icon) so nothing must be relearned.
What information helps the user before they act?Show previews, tooltips and clear labels so actions are predictable.
How long does it take between an action and a response?Keep response times short; show a loading indicator when you cannot.

More best practices for game interfaces

  • Keep it simple. Show only what the player needs right now; hide advanced options in sub-menus.
  • Create a clear hierarchy. The most important information (health, timer, objective) should be the biggest or brightest.
  • Recognition over recall. Show icons and choices instead of expecting players to remember codes or button combinations.
  • Stay consistent. The same button should do the same job on every screen.
  • Keep the play area clear. HUD elements usually sit at the edges and corners so they do not cover the action.
  • Design for everyone. Allow remapped controls, readable text sizes, subtitles and colour-blind friendly signals.
  • Test early. Show your wireframes to players and watch where they hesitate.

Levels of fidelity

Fidelity means how close a design is to the finished product. A low-fidelity wireframe is a quick pencil sketch; a mid-fidelity wireframe is a neat digital layout with grey boxes and real labels; a high-fidelity mock-up adds colour, fonts and art; and an interactive prototype lets people click between screens. Start low and increase fidelity only when the layout works.

Two people at a desk sketching a screen layout on paper beside a computer
Figure 1 – A mentor helps a student sketch a wireframe on paper for a website idea. Sketching by hand is the fastest way to try many layouts before choosing one. Image: Nathan Kit Kennedy, CC0, via Wikimedia Commons.
Grey and white digital wireframe of a web page with navigation, lists and content boxes
Figure 2 – A digital mid-fidelity wireframe: grey boxes, simple lines and real labels show structure and navigation without final artwork. Image: Dereckson, CC BY 3.0, via Wikimedia Commons.

How to wireframe a game UI step by step

  1. List the screens. For a small game: title screen, main menu, level select, gameplay HUD, pause menu, settings, win screen and game-over screen.
  2. Draw a screen-flow diagram. Use arrows to show how the player moves between screens (for example, Title → Main Menu → Level Select → Gameplay → Pause → Main Menu).
  3. Decide what each screen must show. Write a short list of every element and action before drawing.
  4. Sketch several layouts quickly. Draw three or four thumbnail versions of each important screen; choose the clearest one.
  5. Draw the chosen layout neatly. Use boxes with an X for images, lines for text, and label every button. Add notes and arrows to explain interactions (“tap to jump”, “flashes red below 20% health”).
  6. Check it against the principles. Is it consistent, perceivable, learnable and predictable? Does every action give feedback?
  7. Test and revise. Ask someone to “play” the paper screens while you swap pages when they tap. Note where they get stuck.

Useful tools include paper and pencil, free online tools such as Figma, Penpot or draw.io, and dedicated wireframing programs such as Balsamiq. Even PowerPoint or Google Slides can link screens together into a clickable prototype.

This CareerFoundry tutorial walks through a first wireframe from start to finish. It uses an app as the example, but every step applies to game screens too:

Example

Here is a low-fidelity wireframe of the gameplay HUD for a side-scrolling game about collecting seeds to replant a forest. Notes explain each element and the reasons behind its position.

+------------------------------------------------------------+
| [♥ ♥ ♥] Lives SEEDS: 12/30 [II] Pause |
| |
| |
| (play area kept clear) |
| |
| player |
| ___[P]_____________ ______ _____________ |
| |
| [ ← ] [ → ] ( JUMP ) |
+------------------------------------------------------------+
Notes:
- Lives top-left: most important status; hearts flash when one is lost.
- Seed counter top-centre: shows progress towards the level goal.
- Pause top-right: standard position; large 48 px touch target.
- Touch buttons in the bottom corners, where thumbs rest.
- Nothing sits in the middle of the screen, so the action is never hidden.

Exercise

  1. List every screen a simple mobile game of your choice would need, and draw a screen-flow diagram connecting them.
  2. Sketch three different low-fidelity layouts for the gameplay HUD. Choose one and explain your choice using at least three best practices from this post.
  3. Draw a neat wireframe of the pause menu and the settings screen, with notes describing each interaction and its feedback.
  4. Test your paper prototype with a classmate or family member. Record two problems you noticed and how you would fix them.

Next: Elements and Principles of Visual Design for Games and Interfaces (With Gestalt Examples)

Syllabus link: This post is relevant to the CAPE® Animation and Game Design Syllabus, Unit 2: Interactive Design and Game Development, Module 1: Introduction to Interactive Design – Specific Objective 7 (“outline some prominent best practices for designing interactions”); Specific Objective 8 (“employ design principles and best practices to create a wireframe of the user interface (UI) of a game”).

Attributions to media used in this post:

Spokes America Planning a Website 2.png – Nathan Kit Kennedy – CC0 (via Wikimedia Commons)

Wolfplex-Wiki-WorkshopsIdeaList-wireframe-20130929-v02.png – Dereckson – CC BY 3.0 (via Wikimedia Commons)

© 2026 Vedesh Kungebeharry. All rights reserved.