PROJECT 08 / AUTOMOTIVE HMI
An authoring tool for in-vehicle interfaces
Defining the interaction model for a greenfield node-based authoring environment for automotive dashboards and in-vehicle UI, a zero-to-one product line for Unity.
- Role
- Senior Product Designer, founding UX
- Where
- When
- 2021 to 2023
CONTEXT
A new vertical, built from nothing
Unity had spent a decade as a games engine, and was pushing the same real-time technology into a new market: automotive. Carmakers were replacing analog dashboards with software-defined interfaces, and they needed a way to author them. Unity's answer was an HMI authoring tool, a node-based environment for building dashboards and in-vehicle UI.
This was zero to one. There was no existing product to polish, and no established mental model for the customer to bring. I was defining the interaction model for a greenfield tool in a vertical Unity had not shipped in before.
SCOPE, ONE TOOL, ITS CORE SYSTEMS
I owned the concepts that made the tool coherent, across roughly 35 design tickets.
DATA BINDING & NODE GRAPH
- Binding status visualization in the inspector
- Graph and binding interaction specification
- Subgraph interactions and binding graph wireframes
AUTHORING WORKFLOWS
- State management and transitions
- Timeline animation editing
- Visual style editor and variant management
PREVIEW & DEPLOY
- Preview behavior and multi-display management
- Deployment and build GUI design
- Remote debugging and network sync
COMPLEXITY
- Smart Inspector and Pro Mode concepts
- Visualizing complex data
- Search and hierarchy navigation
KEY DECISIONS
The calls that shaped the product, and what each one cost.
THE NODE GRAPH AS THE MENTAL MODEL
Tension
In-vehicle UI is built from many systems talking to each other, and a flat form-based tool could not express how data flows between them.
Decision
Built the authoring model around a node graph, with binding status shown in the inspector and graph outputs made legible, so the flow of data is the thing the user manipulates.
Tradeoff
A graph is harder to learn than a form. For the audience this tool serves, people wiring real vehicle systems together, the graph is the honest representation of what they are actually doing.
COMPLEXITY AS A FIRST-CLASS CONCERN
Tension
A vehicle interface has more states, variants and systems than a game menu, and the tool could easily drown users in that complexity.
Decision
Designed complexity management in from the start: a Smart Inspector concept, a Pro Mode, and explicit patterns for visualizing and filtering dense data.
Tradeoff
It meant designing for experts and newcomers at once, which is harder than designing for one. Getting that balance wrong was the biggest risk, so it got design attention early rather than as an afterthought.
PREVIEW AND DEPLOY ARE PART OF THE TOOL
Tension
Most authoring tools stop at authoring, and leave preview and deployment to someone else. But a dashboard can only be evaluated in its multi-display, in-vehicle context.
Decision
Made preview, multi-display management and deployment first-class parts of the tool, so a designer sees the interface as the driver would before it ships.
Tradeoff
It expanded the product's surface beyond pure authoring. That is the difference between a tool that makes pictures and a tool that makes products.
IN THE TOOL
OUTCOME
I defined the interaction model that made the tool coherent across roughly 35 design tickets, and the vertical grew from a greenfield bet into a real Unity solution, with the HMI product line and partnerships that followed.
This is the work I point to for zero-to-one design. There was no reference product, no inherited mental model, and no customer who already knew how to use it. The design had to invent the thing it was teaching.