PROJECT 01 / DIGITAL TWIN PLATFORM
A tool to build digital twins
The surface teams use to create, organize, and publish digital twins, one portal over an authoring stack that had been spread across separate tools.
- Role
- Senior Product Designer
- Where
- Unity
- When
- 2022, present
CONTEXT
One portal, many surfaces
A digital twin is not a file. It is an asset pipeline, a build, a deployment target, a set of permissions, and a living record of who changed what, and at Unity each of those lived in a different product. Teams assembling a twin moved between an asset system, a developer portal, a cloud service, a workflow tool and an analytics view, carrying context in their heads across all of them.
My remit was the surface that makes those pieces read as one product: a manager where a twin is a first-class object with an owner, a state, a history and a place to go next. The constraint that shaped everything was that I could not collapse the underlying systems. Asset Manager, Developer Portal, Forma Cloud, Workflow Manager and Analytics each have their own teams, roadmaps and release cadences. The portal had to be a coherent front door to systems that would keep evolving independently behind it.
The framing discipline mattered as much as the interface. I did not create a digital twin. I built the tool other people use to create digital twins, which means the user is a team with a pipeline, not an artist with a scene, and the design has to hold up under handoff, review and audit rather than under a demo.
SCOPE, SURFACES BROUGHT INTO ONE PORTAL
Each surface kept its own team and cadence. The portal is the layer that makes them legible as a single workflow.
AUTHORING & ASSETS
- Asset Manager, source assets, versions, dependencies
- Workflow Manager, the steps a twin moves through
- Digital Twin Manager, the twin as an owned, stateful object
DELIVERY & OPERATION
- Developer Portal, access, keys, integration surface
- Forma Cloud, build, host and serve the running twin
- Analytics, what happens to the twin once it is live
KEY DECISIONS
The calls that shaped the product, and what each one cost.
WORKSPACES AND ROLES AS THE ORGANISING UNIT
Tension
Twins are built by teams, but the tooling underneath assumed an individual creator with a project. Without a shared container, every collaboration question (who can publish, who can archive, who sees this) had to be answered per object.
Decision
Made the workspace the primary container and attached roles to it, so permissions are inherited rather than re-declared. A twin belongs to a workspace first and a person second.
Tradeoff
Solo creators pay a setup cost for a structure they do not need yet, and a twin cannot casually straddle two teams. I took that over a permissions model that would have to be re-explained on every object.
AN EXPLICIT LIFECYCLE INSTEAD OF AN IMPLIED ONE
Tension
Teams were using naming conventions to encode status, copies suffixed final, old, do-not-use. The system had no idea which twin was real, so neither did anyone else.
Decision
Modelled two orthogonal axes rather than one status field: a lifecycle of Active, Transition and Archive for how the twin is maintained, and a release ring of Alpha, Beta and Live for how exposed it is. A twin can be actively maintained and still pre-release, which one combined field could not express.
Tradeoff
Two axes are harder to teach than one badge, and the UI has to make the pairing readable at a glance. In exchange, archiving stopped being a destructive decision and became a reversible state.
THREE VIEWS ONTO THE SAME LIBRARY
Tension
The same set of twins is used for three different jobs: recognising one, comparing many, and inspecting a single one in depth. A single list served none of them well.
Decision
Built the library as one data model with three presentations: a visual gallery for recognition, a dense list for comparison and scanning by state, and a detail view that carries the full record. State, ownership and ring are visible in all three, so the mental model never changes when the presentation does.
Tradeoff
Three views is three surfaces to maintain and keep consistent as fields are added. The alternative, one compromise view, is the more common choice and the reason most asset libraries are unpleasant to use at scale.
OWNERSHIP AND SHARING AS A VISIBLE PROPERTY
Tension
Sharing was where trust broke down. People hesitated to publish because they could not tell who would gain access, and hesitated to archive because they could not tell who still depended on it.
Decision
Surfaced ownership and reach on the object itself rather than behind a dialog, and made every state change say plainly who it affects before it is confirmed.
Tradeoff
It costs persistent space on every card and row, density I had to buy back elsewhere. It is the difference between a tool people use on their real work and one they use on a copy of it.
PROCESS, HANDS-ON R&D
I build twins so I can design for people who build twins
Designing an authoring tool from a requirements document produces an authoring tool that reviews well and works badly. So I build my own twins, in the open, as a standing research practice.
The first is a smart-home twin: a Unity model of a real home wired to Home Assistant over its REST API, where lights, locks and climate sensors have 3D counterparts that reflect live device state. Control runs both ways: selecting a device in the 3D view sends a command back to the physical one. It taught me what the platform has to guarantee about state that arrives late, arrives wrong, or stops arriving.
The second is an immersive social twin: a persistent shared environment authored in Unity and published to VRChat as its runtime, with custom HLSL shaders, spatial audio zones and interactive objects. Persistence is the whole point: object state and spatial layout survive between sessions, so people return to a place rather than regenerate one. It taught me what publishing actually means when a twin has an audience already standing inside it.
Neither is a portfolio piece. They are the reason I can argue about lifecycle states with engineers from the position of someone who has been burned by not having them.
IN THE TOOL
OUTCOME
The platform is in active development and I own the portal surface within it. The durable result so far is structural: a twin is now an object with an owner, a maintenance state and a release state, expressed the same way in every view, which is what lets separate teams ship against it without renegotiating the model each time.
I am not publishing adoption figures for this work. Nothing here has a number I can trace to a source I would defend, and the alternative, a plausible percentage, is exactly the thing the rest of this site is built to prevent.