What to send your UI designer: the brief and asset checklist

Why the brief moves the price

Every unknown in a brief is priced as risk, because it has to be. If I do not know whether you need controller support, I either ask, which costs a day, or I assume, which costs one of us money later. Ten unknowns and the quote is a range wide enough to be useless to you.

None of this is a negotiation tactic on either side. A specific brief simply lets a designer commit, and committing is what you are actually buying.

The ten fields

Copy these into an email. Most take one line. The whole thing takes about twenty minutes and it is the highest-return twenty minutes in the hiring process.

The screen list is the brief

If you write nothing else, write this. A screen list turns "a full UI" into a number of things, and a number of things can be scheduled, priced and finished. Most teams underestimate their own list by roughly a third, because the boring screens are invisible until someone counts them. How to derive one from your own design is in from core loop to screen list.

• Front end: splash, main menu, new game, load and save, settings across several tabs, credits, quit confirmation.
• In-game: HUD in each mode, pause, map, inventory, character or loadout, quest or objectives, dialogue if you have it.
• Systems: shop, progression or upgrades, crafting, collections, leaderboards, achievements, whatever your game is actually about.
• Flow states: loading, results and end of run, level up, death or fail, unlock and reward, tutorial prompts.
• Platform and edge states: controller disconnect, save failure, storage full, network loss, patch notes, age gate, legal screens. These are the ones nobody lists and every project needs, especially on console.
• Components underneath all of it: buttons, toggles, sliders, tabs, tooltips, modals, notifications, item cards. These are where the reuse lives.

What to attach

Attachments answer questions faster than paragraphs. The best briefs I get are short and heavy.

1. A build, or a five-minute gameplay video. Nothing else tells a designer as much. A rough build beats a polished trailer, because trailers hide the interface.
2. Three to five reference games, with a sentence each on what specifically you like. "The way Persona uses motion" is useful. "Something like Destiny" is not, because that could mean the type, the density, the animation or the colour, and those are four different projects.
3. Your logo and key art, in vector if it exists. If the logo is a raster export at 800 pixels, say so now rather than in week four. If it needs work, that is its own conversation: see game logo design.
4. Fonts, with licences. More on this below, because it is the most common expensive surprise in the whole process.
5. Any existing UI, including the placeholder, especially the placeholder. It shows what the systems actually need on screen.
6. A style guide or brand rules if the game or studio has them.
7. Screenshots at your real target resolutions, including the smallest one you support.
8. The list of supported languages, because text expansion changes layout decisions from the first screen.

Fonts and licences, the expensive surprise

A desktop font licence usually does not cover embedding a font in a shipped game, and game licences are priced separately, sometimes per title and sometimes per platform. This surfaces late, after a hundred screens are drawn in a face you cannot legally ship, and the fix is either a licence you did not budget for or a re-typesetting pass across the whole game.

• Tell your designer what you already own and what it covers.
• If you own nothing, say that. There are excellent open-licence families, and I would rather design in one from day one than migrate later.
• Check bundled fonts. A font that came with a design tool or a template is often not licensed for redistribution inside a game binary.
• Check every language you ship. A font with no Cyrillic or CJK coverage means a fallback face, and a fallback face that looks nothing like the original undoes your typography in exactly the markets you paid to enter.

Name one decision maker

This is the field that most affects a schedule and it costs nothing. Design work does not stall because it is hard, it stalls waiting for an answer, and it goes backwards when two people give different answers a week apart.

• One name has final say. Others can comment, and that is fine and useful.
• A feedback window. Two working days is normal. Longer is fine if it is agreed in advance rather than discovered.
• Consolidated feedback, in one document or one thread, not five messages across three tools.
• Feedback on the problem, not the pixel. "This screen feels slow to read" gives me the whole solution space. "Make the title 4px bigger" gives me one fix and hides the actual issue.

The four things that make a brief worse

1. Hiding the budget. The common belief is that naming a number gets you charged that number. In practice a range lets a designer tell you what fits inside it, and withholding it means the quote is scoped to everything you asked for, which is usually more than you wanted to buy.
2. Sending a folder instead of a brief. Four hundred files in a drive is not context, it is homework. Ten well-chosen attachments beat all of it.
3. Asking for a free test screen. A paid trial screen is completely reasonable and I recommend it: pick one real screen, pay for it, judge everything from that. An unpaid one selects for whoever is least busy, which is not the signal you want.
4. Describing the solution instead of the problem. "We need a radial menu" might be right, but if the actual problem is that players cannot find their consumables, there may be a cheaper answer that ships sooner.

A brief you can copy

This is the shape of a message that gets a firm quote back the same day. It is deliberately short.

• Game: Ashfall, a top-down survival roguelike. Runs of about 25 minutes, base building between runs.
• Platforms: PC first, Steam Deck at launch, console six months later.
• Engine: Unity 6, our two engineers implement.
• Scope: 18 screens, list attached. Full HUD, main menu, inventory, crafting, base view, end-of-run, settings.
• Stage: Playable vertical slice, placeholder UI throughout.
• Deadline: Publisher demo on 12 March, so everything needs to be in the build by 1 March.
• Budget: Around $14,000, some flexibility for the HUD if it needs more.
• Decision maker: Me, replying within two working days.
• What exists: Logo in vector, art direction locked, two placeholder screens, no fonts licensed yet.
• Attached: Build, a five-minute video, three references, the screen list, our colour palette.

A designer cannot commit to a schedule for a project they cannot see the edges of. The brief is where you draw the edges.

What you should get back

A brief that good deserves a response that specific. If it comes back vague, that is information about the designer as much as about the project.

• A price or a tight range, with what is in it and what is not.
• A schedule with dates, working backwards from your deadline rather than forwards from today. The reasoning is in how long game UI design takes.
• A list of what they need from you and when, including the build, the content and the sign-offs.
• The deliverables, named. Source files, exported assets, annotated specs, a component library, controller navigation maps. What a full handoff contains is covered in designing game UI for Unity.
• Questions. Good ones. A designer with no questions after reading a real brief has not read it.