Prefabs, variants and a Unity UI kit that survives the project

Every project starts with someone building the first screen. If they build it out of reusable parts, the next thirty screens get faster and cheaper. If they build it as a one-off, the next thirty screens each get built as one-offs too, and the cost of a change in month six is the number of screens you have. Nothing about Unity forces either outcome, which is why it is worth deciding deliberately.

The unit of reuse is the component, not the screen

A screen is a layout of components plus content. That sounds obvious and it is routinely violated: interfaces get built screen by screen, with each screen containing its own buttons drawn from scratch, and a design system that exists only in the Figma file.

A component is a thing that appears more than once: a button, a toggle, a slider, an item card, a modal frame, a tab, a tooltip, a resource counter.
A screen is an arrangement of those, with content filled in at runtime or in the scene.
If a screen contains a control that exists nowhere else, ask whether it should. Usually the answer is that it is a variant of something you already have.
The test: changing the corner radius on every button in the game should be one edit. If it is forty, the kit is not a kit.

Base prefab, then variants

Prefab variants are the feature that makes this work, and they are underused because the difference between a variant and a copy is not visible in a screenshot.

Situation	Do this
Primary, secondary and ghost buttons	One base button prefab, three variants that override colour and border
A button that is wider	Not a variant. Anchor and size it on the instance
An icon button with no label	A variant, because its structure differs
An item card for weapons and one for consumables	One base card, two variants, if the layout is the same
A completely different control	A new base prefab, not a variant of something unrelated

The rule I use: a variant changes appearance or a small structural detail, a new prefab changes what the thing is. Stretching that rule produces variants that override so much they no longer inherit anything useful, which is a copy wearing a variant's name.

Nesting: how deep before it hurts

Nested prefabs are correct in principle and expensive in practice past a certain depth, both for the editor and for whoever has to debug them.

One or two levels is comfortable. A modal prefab containing a button prefab, containing nothing else.
Three is the usual ceiling. A screen containing a panel containing a card containing a button starts producing override chains nobody can follow.
Do not nest for the sake of it. Small decorative groupings do not need to be prefabs; they need to be part of the component they belong to.
Watch instantiation cost. Deep nesting means more objects created per screen open, which is the same problem as canvas rebuild cost arriving from a different direction.

Naming that survives a search

In six months somebody will type a word into the project search and either find the thing or rebuild it. Naming is not tidiness, it is the retrieval system.

Type first, then role, then variant: btn_primary, btn_secondary, btn_icon, card_item, panel_modal, bar_progress.
Sortable beats readable. A flat prefix scheme groups related things in the project window automatically.
Match the design file exactly. If Figma says Button / Primary / Large, the prefab is btn_primary_lg. A one-to-one mapping means a conversation about a design is a conversation about a prefab.
Name objects inside the prefab too. Label, Icon, Background, FocusRing. A hierarchy of GameObject (3) is where handoffs go to die.
Never name by appearance. btn_blue survives until the day the palette changes.

Theming without duplicating

The single most valuable thing a kit can do is let one change land everywhere. uGUI has no built-in equivalent of a stylesheet, so this has to be built, and it is worth the day it takes.

Put the palette in a ScriptableObject. Colours, and ideally spacing and radius values, defined once as data rather than typed into components.
Add a small component that applies a token, so a graphic says "I am the accent colour" rather than storing a hex value.
Use TextMeshPro style sheets for type, so heading, body and caption are named styles rather than repeated font sizes.
Keep the number of tokens small. Five colours and a four-step spacing scale go further than thirty of each, and they are what makes a kit feel designed rather than assembled.
If you are on UI Toolkit, this is free. USS variables and selectors do exactly this natively, which is one of the strongest arguments in uGUI or UI Toolkit.

Mapping a Figma library onto prefabs

When the design library and the Unity kit share a structure, handoff stops being translation. When they do not, every screen is a small negotiation.

In Figma	In Unity
Component	Base prefab
Variant property	Prefab variant, or a state on the component
Colour style or variable	Entry in the theme ScriptableObject
Text style	TextMeshPro style
Auto layout with fixed spacing	Anchored positions, or a layout group where content varies
Component name	Prefab name, character for character

This mapping is most of what makes a handoff buildable, and it is why the design library should be built before the second screen rather than extracted from the twentieth. The rest of the package is in designing game UI for Unity.

States belong to the component

A button's default, hover, pressed, selected, focused and disabled appearances are properties of the button, not of each screen it appears on. If states are being wired per screen, they will drift, and a player will eventually see two buttons in the same game that respond differently.

Build every state into the base prefab, including the focused state that controllers need, as covered in designing game UI for controllers.
Include focused-and-selected. It is the state everyone forgets and every console player sees.
Keep the transition in the component too, so the timing is identical everywhere.
Do not let a screen override a state colour. If it needs to, that is a variant.

What breaks a kit

One-off edits on instances, made in a hurry, never rolled back into the prefab.
Screen-level prefabs with everything inside them, so nothing can be reused and nothing can be changed globally.
Duplicated variants created because somebody could not find the existing one, which is a naming failure wearing a structure failure's clothes.
Hardcoded colours typed into individual graphics, which quietly ends the theming system.
Art delivered as screens rather than as components, which forces the implementer to invent the structure. This one is the designer's fault, and it is avoidable.
No owner. A kit with nobody responsible for it decays at exactly the rate the team grows.

A UI kit is not a folder of prefabs. It is the promise that one change lands everywhere, and every one-off edit is a small withdrawal from it.

What a kit actually ships with

Deliverable	What it is	Who uses it
Base prefabs	One per control type, every state built in	Engineers assembling screens
Variants	The visual and structural options on each base	Engineers and designers
Theme asset	Colours, spacing, radius as data	Anyone changing the look
Type styles	Named heading, body and caption styles	Everyone
Sprite atlases	Grouped by screen or feature, named to match	Engineers, and the batching profile
A usage page	One screen in the project showing every component and state	New team members, and QA
The design library	The Figma file the prefabs mirror, names matching	Designers, and the next designer

That last-but-one item is worth insisting on: a single scene containing every component in every state. It takes an hour, it catches drift immediately, and it is the fastest way to onboard whoever inherits the project.

Ownership after handoff

A kit is a living thing and it needs a rule about who changes it. The version that works on small teams: anyone can use it, one person approves changes to a base prefab, and new components come from the design library rather than from a screen that needed something.

When should I use a prefab variant instead of a new prefab?

Use a variant when the thing is the same control with a different appearance or a small structural difference: a primary versus a secondary button, a card with an extra badge. Use a new base prefab when it is a different control. If a variant is overriding most of its parent's values, it has stopped inheriting anything useful and should be its own prefab.

How do I stop instance overrides from piling up?

Check the override list on prefab instances as part of review, and treat a long list as a signal rather than a mess to tidy. Repeated overrides of the same value mean a missing variant; one-off overrides of position and size are normal and fine, since that is what instances are for.

Do I need a theming system if the art direction is locked?

Art direction is locked until the first playtest, a publisher note, or a platform requirement changes it. A theme asset costs about a day and turns a repaint from a week into an afternoon. It also makes accessibility work such as a high-contrast option feasible, which is otherwise a rebuild.

Should the designer build the prefabs?

It works well when the designer is comfortable in Unity, and it removes an entire translation step. It works badly when scene ownership is unclear or the project has strict conventions the designer does not know. The middle path most teams use: the designer builds the component kit and a reference screen, engineers assemble the rest.

How does this change on UI Toolkit?

The concepts map directly: base prefab becomes a UXML template, variants become classes or template variations, and the theme asset becomes USS variables. The structure discussion is identical, and the tooling is friendlier because styling at scale is built in rather than something you construct.

What is the minimum kit for a small indie game?

Button with all states, toggle, slider, a panel or modal frame, a list row, an item card, a tab, and a notification or toast. Eight components with their states will build most of a game's interface, and they are the eight that get rebuilt forty times if nobody makes them once.

How much does a UI kit add to the cost of a project?

Building components rather than screens adds a few days at the start and removes considerably more later, which is why I scope it as part of the work rather than an extra. The break-even is somewhere around the eighth screen; past twenty it is not close. The general pricing logic is in the cost article.

Hadjoudj Idris

Game UI/UX Designer, Remote, worldwide

Need this done properly on your game?

Menus, HUDs, a full UI system, or one screen that isn't working. Tell me what you're building and I'll tell you honestly whether I'm the right fit, and what it would cost.

Hire me for your game See case studies

UpworkTop Rated100% Job Success