From core loop to screen list: turning a design into something you can build

The screen list is the design, made countable

Every design decision eventually becomes a surface the player looks at. Listing those surfaces converts a set of intentions into something that can be scheduled, priced and cut, and it does it early enough for the cutting to be cheap.

• It makes scope visible. "We will have crafting" becomes four screens and eleven states.
• It makes cost real. Design work, art, engineering and QA all scale roughly with this list.
• It makes cutting possible. You cannot remove a feature you have not measured.
• It makes hiring possible. A screen list is what turns a vague enquiry into a firm quote, as covered in what to send your UI designer.

Start from the loop, not the feature list

Draw the core loop first: the sequence the player repeats. Then walk it and ask, at every step, what the player has to see or decide.

1. 01

   Write the loop as verbs

   Explore, fight, loot, upgrade, repeat. Or: pick a contract, drive it, get paid, buy a truck. Four to six verbs is usually the whole game.

2. 02

   Give each verb its surface

   A verb the player performs needs a way to do it and a way to see the result. Fight needs a HUD. Upgrade needs a screen. Get paid needs a results moment.

3. 03

   Add the transitions

   Between every pair of verbs there is a moment: a loading screen, a summary, a confirmation, a briefing. These get forgotten and there are more of them than anyone expects.

4. 04

   Then add the systems

   Everything that is not in the loop: settings, saves, collections, stats, social, store. This is where the list doubles.

The four layers

The fourth layer is the one that turns a comfortable schedule into a scramble. It is not optional, most of it is required by platform certification, and it appears on nobody's design document.

Deriving screens from systems

Each system implies a predictable set of surfaces. This is the table I work through with teams, and it is usually where the number doubles.

States are where the scope hides

One inventory screen is not one screen. It is a screen with a set of states, and the state count is a better predictor of effort than the screen count.

• Empty, loading, error, filtered-empty, one item, full, over capacity. Nearly every list-shaped screen has all seven.
• Interaction states: default, focused, selected, pressed, disabled, and focused-while-selected, per designing game UI for controllers.
• Content extremes: the longest item name, the biggest number, the maximum stack, the longest translated string.
• Permission states: locked, unavailable, owned, already equipped, not yet earned.
• A rough rule: a systems screen is three to seven times the work of its default state. Estimating from the default alone is how projects end up a month short.

The screens nobody lists

1. Controller disconnected, required on console and missing from most lists.
2. Save failed, storage full, do-not-power-off, all certification items.
3. Network loss and reconnection, for anything online, including single-player games with a store.
4. First launch: language, accessibility offer, age gate, legal, data consent.
5. Patch notes and version mismatch.
6. Empty states for every list in the game, which is the single most commonly missed category.
7. The end. What a player sees when they finish, or when they have bought everything, or when the season ends.

Cutting

A screen list exists to be cut. The useful sort is frequency against value, and it produces different answers from the one everyone expects.

The pattern that keeps repeating: teams spend their design budget on the main menu, which is seen once per session for four seconds, and reuse a template for the results screen, which is seen forty times an hour and decides whether people retry. The priority order for a small budget is in indie game UI on a budget.

Prototype order

Once the list exists, the order to build it in is not top to bottom.

1. The HUD for the main mode, because it cannot be judged without motion and it will change more than anything else.
2. The session loop screens: start, results, retry. These decide retention and they are small.
3. The one system screen your game is about. The inventory in a survival game, the deck in a card game, the base in a management game.
4. The component kit, once three real screens exist, so the reusable parts are derived from reality rather than guessed. See prefabs, variants and a Unity UI kit.
5. Everything else, assembled from the kit.
6. Platform and error states last, but on the list from day one so they are scheduled rather than discovered.

A worked example

A small run-based roguelike, the kind of project I am sent most often. The team's initial estimate is usually around a dozen screens.

• Loop screens: main menu, run setup, HUD, pause, level up or reward choice, end of run, meta upgrades. Seven.
• Meta screens: unlock collection, stats, achievements, settings across three tabs. Six.
• Moments: loading, new unlock, death, victory, daily challenge. Five.
• Platform and edge: controller disconnect, save error, first launch, legal, patch notes. Five.
• States on the six list-shaped screens: empty, filtered, locked, error, maxed. Call it twenty additional deliverables.
• Components underneath all of it: buttons, cards, tooltips, modals, notifications, sliders, tabs. Eight or so.

That is roughly twenty-three screens, twenty state variants and eight components, against an initial guess of twelve. Nothing was added to the game: it was counted. Doing that counting before the schedule is written is the difference between a plan and an optimistic sentence.

Nobody has ever discovered their screen list was shorter than they thought.

Keeping it alive

• One owner. A list nobody maintains is wrong within a month.
• Review it at every milestone, and add the screens the last month revealed.
• Mark status per screen: designed, built, states done, localised, controller-checked.
• Keep the cut list visible. Things that were cut have a way of returning as surprises.
• Attach it to the brief when you hire. It is the single most useful attachment a studio can send a designer.