Designing game UI for Unity: a handoff that actually gets built

Why designs get rebuilt instead of built

When a developer says a design "did not work in Unity", it is almost always one of five things, and all five are preventable at the design stage.

1. It was designed at one resolution with no instruction about what happens at any other.
2. Panels were delivered as flat images, so a container that needs to grow with its content cannot.
3. Only the default state exists. No hover, pressed, disabled, focused, selected.
4. No controller navigation was specified, so the developer invents an order and it feels wrong.
5. Assets were exported inconsistently: mixed densities, baked-in shadows, no padding, names nobody can search.

None of these are Unity's fault, and none require the designer to be an engineer. They require the design to describe behaviour as well as appearance.

Design at a reference resolution

Unity's Canvas Scaler is normally set to Scale With Screen Size with a reference resolution, most commonly 1920 × 1080 for PC and console. The design should be built at that same resolution so the numbers in the file mean something in the engine.

The Screen Match Mode setting then decides what happens when the real aspect ratio differs: matching width, matching height, or a blend between them. That is a decision worth making deliberately with your developer, because it determines whether an ultrawide monitor gets more visible area or a larger interface.

• Agree the reference resolution before designing, not after.
• Design in whole pixels at that resolution. Half-pixel values become soft edges once scaling is applied.
• Check your layout at 16:10, 21:9 and 4:3 if you support them, and at the smallest resolution you allow.
• For mobile, design for the safe area, not the full rectangle. Notches and gesture bars will eat the edges.

Anchors: design for resize, not for one screenshot

Every element in Unity has anchors that determine what it stays attached to when the canvas changes size. This is the single most valuable thing a design can specify, and it takes about ten minutes to annotate a whole screen.

Write it on the design. A single line per element, "anchored top-right, fixed size, 32px margin", removes an entire category of guesswork and the rework that follows it.

Nine-slice: your corner radius is a spec, not a picture

A button that has to work at several widths should not ship as several images. In Unity a sprite gets border values in the Sprite Editor and the Image component is set to Sliced: the corners stay fixed, the edges stretch along one axis, and the middle fills. One small asset covers every size.

• Export the smallest tile that contains the full corner, plus a few pixels of the straight edge.
• Tell the developer the border values in pixels: top, right, bottom, left. They are a design decision, not a guess.
• Keep corners in the corners. A gradient or highlight running across the whole button breaks when the middle stretches.
• Do not bake shadows into a sliced sprite unless the shadow is uniform on all sides.
• Flag anything that must tile rather than stretch, such as a repeating texture, because that is a different Image setting.

Exports, naming and atlases

Fonts and TextMeshPro

Unity's TextMeshPro renders text from a generated font asset rather than the font file directly, which has practical consequences for design.

• Supply the actual font files, plus the licence. A design showing a font nobody can legally embed is a problem discovered late.
• Check the licence covers embedding in a game build. Desktop licences frequently do not, and this catches teams out constantly.
• Name exact sizes, weights, line heights and letter spacing. "Slightly tighter" is not implementable.
• Flag every language you will ship in. Non-Latin scripts need their glyphs included, usually through a fallback font asset, and that has to be planned rather than discovered.
• Avoid relying on very thin weights at small sizes, which lose definition once rendered through a font atlas.
• Decide about outlines and shadows early, since they change how the text asset is set up.

States, and how they actually get wired

Unity's Button component has built-in transitions between normal, highlighted, pressed, selected and disabled, either by tint, by swapping sprites, or by animation. Which one your design implies changes the work considerably.

Deliver all five states for anything interactive. Disabled and focused are the two that get skipped, and they are the two that matter most on a gamepad. Also worth knowing: CanvasGroup is how a whole panel gets faded or made non-interactive at once, so if your design has a "dimmed while a modal is open" state, say so, and it is one component rather than fifty colour changes.

Controller navigation in Unity

Unity's EventSystem drives gamepad and keyboard navigation. Each Selectable has a Navigation mode, and the automatic one infers an order from screen positions. It is fine for a simple vertical list and wrong more or less everywhere else.

1. Specify the first selected element for every screen. A menu that opens with nothing selected leaves a controller player pressing directions to find out where they are.
2. Draw the navigation order on the design: which element leads to which in each direction. On anything grid-shaped or irregular, set it explicitly rather than relying on inference.
3. Say what happens at the ends. Does the list wrap around, or stop?
4. Skip disabled elements in the order entirely.
5. Design the focus state to be unmissable, since it is the only thing telling the player where they are. On console it needs to read from across a room.
6. Define the back button and keep its behaviour identical on every screen.

This is the area where late decisions cause full rebuilds, which is why it appears in seven HUD mistakes that make players quit as well. Deciding it during design costs nothing.

Layout groups, and when to stop using them

Unity's Horizontal, Vertical and Grid Layout Groups, usually with a Content Size Fitter, will arrange children automatically. They are genuinely useful for lists, inventories and anything driven by variable data, although past about fifty rows a list wants pooling rather than a layout group, which is its own subject in fast lists in Unity.

They also cost performance, because they force layout rebuilds, and nesting them deeply is a well-known way to make a UI hitch. For a fixed layout that never changes shape, positioning elements directly is cheaper and more predictable. The practical rule: use layout groups where the content is dynamic, and fixed positioning where it is not.

Two related things worth knowing as a designer, because they change what you should ask for: a Canvas rebuilds as a unit, so a small frequently-updating element such as a timer is better on its own Canvas than inside a large static one; and any graphic that does not need to receive clicks should have Raycast Target disabled, which is free performance and something you can flag on the design. Both of those, and the rest of the interface causes of a bad frame time, are in why your Unity menus tank the frame rate.

UGUI or UI Toolkit?

For most game interfaces, UGUI remains the pragmatic choice, and it is what handoff conventions are built around. UI Toolkit is compelling for editor tooling and data-heavy screens. Either way, ask your developer which one they are using before you design, because it changes what a useful handoff looks like. The full comparison, including what Unity's own manual recommends for each case, is in uGUI or UI Toolkit.

The handoff package

1. Source file, organised, with layers named to match the exported assets.
2. A screen list with every state, so nothing is discovered late.
3. Anchor annotations for every element on every screen.
4. Nine-slice borders in pixels for every stretchable graphic.
5. Exported sprites, trimmed consistently, named in a flat searchable scheme, grouped for atlasing.
6. Font files and licence, with exact sizes, weights, line heights and spacing.
7. All five states for every interactive element, with the transition type named.
8. Navigation order and first-selected per screen, plus back behaviour.
9. Colour values as hex, and any alpha values used.
10. Motion spec: durations and easing for transitions that matter.
11. A short spec document tying it together, one page per screen is plenty.

That package is the difference between a developer building your design and a developer interpreting it. It is also what stops the interface drifting during production, which is the quiet way game UI quality erodes. How those components should be structured once they are in the project, so one change lands everywhere, is in prefabs, variants and a Unity UI kit.

Who should do the implementation?

I work in all three shapes depending on the team. What matters is deciding which one you are running before the design starts, because it changes what gets delivered.