PROJECT 02 / EDITOR TOOLING
An official way to rearrange the Editor toolbar
A supported customization API for the Editor's most-used surface, replacing years of unofficial workarounds built on internal APIs.
- Role
- Senior Product Designer, sole designer
- Where
- Unity
- When
- Shipped in Unity 6.3
CONTEXT
The most-used strip of pixels in the Editor, and nobody owned it
The Unity Editor's main toolbar is the first thing a creator touches and the last thing anyone had designed. Over the years it accumulated third-party workarounds: studios wired custom buttons into it through undocumented internal APIs because there was no supported way to do it. That left Unity unable to change the toolbar without breaking tools it had never sanctioned, and left creators with an entry point that was cluttered, inconsistent and unsupported.
The brief was to replace that with an official customization API for a platform used by millions of creators, and to do it without making the default Editor worse for everyone who never customizes anything. Every element that becomes customizable is also an element that can be removed, hidden or reordered into an unrecognisable state, which is a support burden and a first-run problem at the same time.
MY ROLE
Sole designer, end to end: problem framing, research, prototyping, the rules for what ships enabled by default versus opt-in, the telemetry plan for measuring whether the API actually displaced the workarounds, design documentation, and handoff to engineering. The work ran in Unity's UXML and USS systems rather than only in Figma, and it introduced an internal governance model for toolbar real estate where none had existed, the standing question of who is allowed to put something in front of every creator, and on what grounds.
PROCESS, DESIGN EXPLORATIONS
How do you say "this is editable now"?
Customization needs a mode, and a mode needs to announce itself. I explored a distinct edit-mode highlight over the whole toolbar, drag handles that appear on hover, and access through a context menu.
The highlighted mode won because it borrows a pattern Unity creators already read fluently: the Editor changes colour when its state changes. Hover handles were the most discoverable in isolation and the worst in practice: they made a toolbar people use constantly feel unstable under the cursor. The context menu was the cheapest to build and the easiest to never find.
DESIGN EXPLORATIONS
PROCESS, USER TESTING
Six moderated 45-minute sessions with Unity developers, spanning indie game developers through enterprise simulation engineers, run on an interactive Figma prototype that simulated the Editor closely enough that participants behaved as though it were real. The sessions tested discoverability, learnability and, the one that actually mattered, whether people felt confident enough to change a toolbar they depend on daily.
The response to the capability itself was positive: participants described adding custom tools as opening many possibilities, and read the drag-and-drop anchor points as useful guides rather than decoration.
TESTING, WHAT CHANGED
Participants were positive about the capability and consistently defeated by the details. Three findings changed the design.
THE CONTROLS PEOPLE WANTED MOST WERE BURIED
Feedback
Participants looking to reposition the play controls went hunting through a nested menu, and several assumed the controls simply were not customizable.
Learning
Discoverability in a tool people use every day is not about whether the affordance exists, it is about whether it is where the intent already is. Nesting the most-wanted controls signalled they were off limits.
Change
Surfaced the most-used controls directly in the toolbar's edit mode instead of behind a nested menu.
THERE WAS NO OBVIOUS WAY BACK OUT
Feedback
Once in customization mode, participants hesitated. Some clicked around the edges looking for a done state; others were unsure whether their changes had already applied.
Learning
An unfamiliar mode with an unclear exit reads as risky, and risk is fatal in a tool where people are protecting a working setup. Confidence to enter depends entirely on confidence to leave.
Change
Gave the mode multiple ways in and out, including Escape and clicking outside, so exiting is never a thing you have to find.
"EDITOR UTILITIES" MEANT NOTHING
Feedback
The label confused half the participants, who read it as a developer feature unrelated to the toolbar in front of them.
Learning
In an Editor full of extension points, a generic label reads as somebody else's feature. The name has to describe the thing under the cursor.
Change
Renamed "Editor Utilities" to "Editor Controls".
FINAL DESIGN
The shipped design puts the most-used controls in reach without nesting, gives the customization mode a clear visual state and several exits, and defines default versus opt-in placement so a supported API does not become an unmanaged land grab on every creator's screen. It shipped in Unity 6.3.
The governance model outlasts the feature. Unity now has a stated position on who may occupy toolbar real estate and how that is decided, which is the part that keeps the toolbar from returning to the state that started this.
OUTCOME
Measured against the legacy workarounds the API was built to replace.
- increase in adoption of the new customizable toolbar API over the legacy methods
- +20%adoption of the new toolbar API
NEXT STEPS
The feature shipped; the follow-on is governance and telemetry.
- Improved toolbar telemetry to watch how the API displaces the old workarounds
- Internal team guidance on how to use the toolbar responsibly
- An approval plan for which default elements internal teams may add