PROJECT 06 / UI TOOLKIT
The visual authoring surface for Unity's UI system
Owning the usability of UI Builder, the visual editor where Unity teams build interface, from embedded tooltips and style workflows to runtime data binding.
- Role
- Senior Product Designer
- Where
- When
- 2020, 2022 to 2025
CONTEXT
A UI system you had to write by hand
UI Toolkit is Unity's UI system, built on UXML for structure and USS for style. It is powerful, and for a long time it was almost entirely hand-authored: building a screen meant writing markup and stylesheets by hand, which put the system out of reach for designers and made iteration slow for everyone.
UI Builder is the visual editor for that system. My remit was its usability, which meant taking a technical, markup-driven surface and making it legible enough that a designer could work in it and a developer would choose it over raw files.
SCOPE, WHAT SHIPPED
The work spanned three problems: making the tool learnable, making styling legible, and making the headline features authorable.
LEARNABILITY
- Tooltip system across every Builder interface
- A tooltip library for the Builder inspector
- Documentation embedded at the point of use
STYLING
- Copy and paste style properties
- Selector-scoped property filtering
- Pseudostate context menus for selectors
- Modern USS property support in the inspector
BINDING & FINDABILITY
- Data binding affordances and context menus
- Non-attribute property binding
- Search in the Builder and the inspector
KEY DECISIONS
The calls that shaped the tool, and what each one cost.
DOCUMENTATION AT THE POINT OF USE
Tension
UI Toolkit's documentation lived on a website, and nobody reads a website while trying to place a control. The tool was full of concepts with no explanation where the confusion happened.
Decision
Built a tooltip system across the Builder and a tooltip library for the inspector, so the explanation for a property sits exactly where the property is.
Tradeoff
Every surface now carries documentation that someone has to write and keep current. It turns the tool into its own manual, which is what makes it learnable at scale.
THE SELECTOR IS THE ORGANISING PRINCIPLE
Tension
A USS property can be inherited from a selector the user did not write, which made styling feel arbitrary: a value would appear greyed out for no obvious reason.
Decision
Made the selector context explicit, with selector-scoped property filtering, pseudostate menus and an active stylesheet view, so the why behind every property is visible.
Tradeoff
It surfaces complexity that a simpler tool would hide. Hiding it is how users end up fighting the cascade, so I surfaced it instead.
BINDING AS AN AFFORDANCE, NOT AN API
Tension
Runtime data binding was a headline UI Toolkit feature, but it existed only in code, so the designers and non-programmers who needed it most could not use it.
Decision
Designed binding as a first-class authoring affordance in the Builder, with tooltips and a context menu, and non-attribute property binding for the cases that did not fit the obvious shape.
Tradeoff
Visual binding is a harder surface to design than a code API. It is also the difference between a feature that exists and a feature people use.
IN THE TOOL
OUTCOME
The work shipped in the shipping Editor, not just in Figma: I carried design fixes through Unity 6.0 and later release-branch ports personally, and runtime data binding became authorable directly in the Builder in Unity 6.0.
The measure that matters for an authoring tool is whether people reach for it on real work. UI Builder went from a markup-adjacent convenience to the surface Unity tells designers to use, and the tooltip, styling and binding work is why.