Wireframes to prototype: how game UI actually gets designed

The stages, and what each one is for

1. 01

   The screen list

   Every screen and every state, counted. Nothing is designed yet. This is what makes the work schedulable and priceable, and it is covered in from core loop to screen list.

2. 02

   Greybox wireframes

   Structure only: what is on the screen, how it is grouped, what is primary. No colour, no artwork, real text where possible. Fast to make and faster to throw away, which is exactly what you want at this stage.

3. 03

   The flow prototype

   The wireframes wired together so screens can be walked through. This is where navigation problems appear, and where a controller flow can be tested before an engineer has built anything.

4. 04

   One screen to final quality

   A single screen taken all the way: type, colour, iconography, states, motion. This establishes the visual language and is the moment to argue about art direction, once, on one screen rather than on thirty.

5. 05

   The component kit

   The reusable parts extracted from that screen: buttons, panels, rows, tabs, modals, with every state. Everything after this is assembly, which is why it is far cheaper than it looks.

6. 06

   Production screens

   The rest of the list, built from the kit, with the states filled in and the handoff annotations attached.

Why the ugly stage is the cheap stage

The cost of a change rises steeply with fidelity, and the steepest rise is between the wireframe and the finished screen.

So the whole purpose of the early stages is to make the expensive decisions while they are still cheap: what is on the screen, what the player does first, where things live. Those are structural questions, and grey boxes answer them better than finished art does, because nobody is distracted.

What a wireframe should and should not contain

• Real content, not lorem ipsum. The longest item name you have, the biggest number, the actual button labels. Placeholder text is always shorter than the truth and it hides every layout problem.
• Hierarchy, expressed in size and position, not in colour. If the primary action is not obvious in grey, it will not be obvious in colour either.
• Every element that will exist, including the ones nobody likes to draw: the scrollbar, the count, the empty state, the back control.
• Notes on behaviour: what stretches, what happens with no data, where focus starts.
• Not artwork. No final icons, no key art, no colour beyond one greyscale ramp and possibly one marker for the accent.
• Not final copy, but close enough to be honest about length. The words get their own pass, per the words in your game.

Prototyping a controller flow before anything is built

This is the part teams do not expect to be possible in a design tool, and it is the highest-value hour in the whole process for a console or handheld game.

1. Draw the focus order directly on the wireframe: first focus, then where up, down, left and right go from every element.
2. Wire the prototype to key presses rather than to clicks, so it can be walked with a keyboard standing in for a pad.
3. Walk every screen without touching the mouse. Dead ends, wrong wrap behaviour and screens that secretly need a cursor all surface immediately.
4. Check the back behaviour from every screen, including modals opened from subscreens.
5. Hand the map over as part of the design, which is the deliverable that most changes what gets built, per designing game UI for controllers.

Reviewing a wireframe without reacting to the grey

The most useful thing a client can do at this stage is ask structural questions. These are the ones that pay off.

The right-hand column is not wrong, it is early. All of it gets answered at the visual stage, and asking it now costs the structural review that this stage exists for.

Testing wireframes with players

You can test a prototype long before it is pretty, and the findings are more useful because nothing is distracting the participant.

• Give a task, not a route: "upgrade something", "find out what that item does".
• Watch where they click before they click correctly. That is where they expected it to be.
• Note vocabulary mismatches. If they say inventory and the screen says stash, the label is wrong.
• Five people is enough to find most structural problems, per how to run a playtest that tells you something.
• Do it before the visual stage, because after it the same problems cost ten times as much to fix.

One screen to final, before the other thirty

The single most valuable process rule I use. Take one screen all the way rather than taking thirty screens to eighty percent.

• Pick a representative screen, ideally one with a list, a detail area, a primary action and at least one awkward state. Not the main menu, which is atypical.
• Take it to genuinely final: type scale, colour roles, icons, all states, motion notes, the annotated handoff.
• Argue about art direction here, once. Every subsequent screen inherits the answer instead of reopening it.
• Build the kit from it rather than guessing components in advance, so the reusable parts are derived from something real, per prefabs, variants and a Unity UI kit.
• This is also the ideal paid trial, if you are evaluating a designer: one real screen, at real quality, tells you about taste, speed, communication and handoff at once.

Thirty screens at eighty percent is a project with thirty problems. One screen at a hundred percent is a project with a template.

From prototype to handoff

• A prototype is not a spec. It shows appearance and sequence, not what stretches, what the disabled state is, or where focus goes.
• The annotations are the deliverable. Anchors, nine-slice borders, states, navigation order, motion values.
• Keep the prototype alive as the reference, so engineers can walk the flow rather than reconstructing it from stills.
• Everything the package should contain is listed in designing game UI for Unity.

Tools, briefly

I work in Figma, because components and variants map cleanly onto prefabs and because prototyping and handoff live in the same file. The tool matters far less than the discipline: real content, every state, and annotations that describe behaviour rather than appearance. A design done properly in any tool beats a design done loosely in the fashionable one.

What you actually see, week by week

For a typical small project, so the shape of it is not a surprise.

The schedule logic behind those weeks, and how it changes with screen count, is in how long does it take to design a game's UI.