Project context
The product was a digital twin platform. It let organisations stand up digital twins of their assets and data sources, then share live data across company boundaries, supplier to customer, without handing over control of the underlying systems.
Impact
The throughline is that the UI did not only make the product easier to use, it changed what the company could sell. As Head of UX I was in the weekly leadership meetings where that played out, and the move toward a self-serve market grew in part out of what the design had made possible. Underneath that sat the quieter work: turning design from something the company did occasionally into a function it actually had.
I was asked to build a design practice where none existed
The product is powerful precisely because it is general, and general products are brutal to design for. Every screen has to teach a concept the user has probably never met, to technical people with no patience for being slowed down.
When I joined as Head of UX, the platform was engineering-led. There was no UI to speak of: the product lived in code demos and in the CEO's slide decks, which carried the vision and did the work of explaining what a digital twin even was. That set the commercial limit too: with no interface, the product could be sold to businesses only, and only as a technical preview, since using it took engineers. The CEO also carried a specific picture of what a twin should look like on a screen, a round form on a canvas, and that picture shaped the first interface I built.
My brief was to make design a function the company actually had, a practice and a system it could rely on, not better screens alone.
Learning the platform like a user, not an owner
There was no research to inherit, so I ran the usual first moves: interviews and usability sessions. There was no support-ticket history to mine, because there was no UI to generate it. The people closest to real use were the solution engineers, who ran the show. They built and demoed everything in code, so I learned a lot of it through them and the rest by watching people meet it for the first time.
The users were technical: developers, data engineers, and solution architects at the businesses adopting it, with individuals on the self-serve side. The pattern that mattered ran on two levels. The first was conceptual: people could not form a picture of what a twin actually was. The idea was unfamiliar enough that explaining it was a constant effort across the company, from the CEO's push for video demos to the team demonstrating twins live at events. The second was practical: even once the idea landed, the product was code-bound, so doing anything real with a twin still meant writing code. Understanding it and using it were both walls, and most people hit at least one.
That insight set the design agenda for the next two years: if a twin was the one thing nobody arrived understanding, then the design's job was to make it concrete, a form people could see and build a mental model from, instead of leaving it in code and in their heads.
That agenda produced the product's first real interface. I built it deliberately visual, to make a twin something you could see and operate rather than read in code. The round form came from the CEO's picture of a twin; I took that starting point and worked out the rest with the people who had to read it, the B2B customers in research sessions and the solution engineers internally, turning what the slides had described into a working screen. At the start even this needed separate code written to hook each screen onto the twins.
The onboarding sprint: three days that paid for the practice
The first interface proved a twin could be visual, but it did not make the product usable on its own. The step forward stopped before it reached onboarding, and onboarding was where the cost showed up.
The platform served two kinds of customer, and both onboarded on the back of a person. Business customers got that person directly: we assigned a representative to guide each new account through setup. It worked, but it was a cost and a ceiling, since every new business meant tying up one of our people for days. Individuals got no person at all. Anyone could create an account, open a personal space, and start building digital twins alone, and the analytics showed where that went: sign up, log in once, never return. No complaint, no ticket, just one session and silence.
So the same gap showed up twice. The product could not onboard anyone on its own. For businesses we covered the gap with a dispatched representative, which was expensive and did not scale. For individuals we covered it with nothing, which is why they left.
I ran a three-day participatory blueprinting sprint on both onboarding journeys. In the room: the rest of the design team, the product owner, the project managers, and the engineers who owned the back-stage, alongside three business-customer representatives and five individual users. The business representatives were the most valuable voice there. They had been through the assisted onboarding and could point to the exact steps where a human had to intervene, the moments the product could not carry on its own. (One limit I worked around: individual users who volunteer for a sprint are the engaged ones, not the people who churned, so the individual diagnosis leaned on the behavioural data.)
I put both journeys on one surface: the front-stage steps a customer moved through, the back-stage work that supported each one, the representative's included, and the systems underneath. The business journey, shown below, is where the complexity sat; the individual one was short enough to need little mapping.
The steps customers actually experienced as they set up and connected their first twins.
The work behind each step that made it possible, much of it invisible to the customer.
The platform, data and integrations sitting underneath each front-stage step.
Putting all three layers on one wall is what let the room see where the journey broke, rather than each discipline seeing only its own slice.
What the representative did for a business, absorb the digital-twin learning curve and get the account to its first working twin, was exactly what the product did for no one. Businesses paid for it in our time. Individuals, with no representative, never got there. So the design question was the same on both sides: move the representative's job into the product, so a customer's own people could reach a live twin without one of ours in the room.
• Connecting twins to the customer's systems. This was the heart of it. A customer's twins lived in the platform's cloud, and getting useful data out to the business's own systems meant working at the API level, hand-writing the logic that shaped what each twin produced and where it went. It was low-level work, and it was where accounts stalled. Handling it was most of what the representative was sent to do. The fix was a visual conditions and derived-feed assistant in the UI: a customer picks a source feed, sets the conditions that shape the output, and builds the derived feeds their systems consume, instead of writing that logic in code, so a customer's own team could do it.
• Modelling the first twins. Before any of that, a business had to describe its assets as twins with the right structure, which was technical and easy to get wrong. Bringing the modelling into a guided visual step, with starting points for common asset types, let customers set their twins up without the representative modelling it for them.
• Secure sharing across organisations. The platform existed to share twin data across company boundaries, supplier to customer, and configuring who could see what was fiddly and usually representative-led. Visual controls with sensible defaults let customers set their own sharing safely.
• Confirming it was live. Once a twin was connected, someone had to confirm data was actually flowing and the twin was responding, which the representative did. A clear in-product signal that a twin was live, with simple checks, let a customer's team verify it themselves.
The result split by customer type. On the business side, the first two customers had each needed a representative for more than two weeks to reach a working twin; after the redesign, customers' own teams got there in a couple of days, and a standard onboarding no longer tied up a representative for weeks, which took the cost and the scaling ceiling off the model. On the individual side, the self-serve users the product could now reach without a person in the loop, drop-off through onboarding fell by more than 20%.
A design system the engineers would actually use
A design system built by one person survives only if engineering trusts it more than their own habits. I built and maintained the Figma component library from zero: components with variants, Auto Layout throughout, a file structure that scaled past its author.
The governance was deliberately light: changes went through a shared review before they landed, and most of the adoption happened in paired build sessions with engineers, backed by usage guidelines, with engineers pulling components straight from Figma day to day. The test of the system was never its completeness, it was whether the next feature shipped looking like it belonged to the same product.
The proof came when an engineer built a whole feature without me and it shipped looking like it belonged: the same components, the same patterns, on-system without anyone policing it. After that the system mostly held on its own, with new hires shipping on-system from their first week and the product staying coherent through a later redesign rather than fragmenting.
By the time I left, the library had grown to more than forty components, each with variants and Auto Layout. Once components were reusable, a typical feature took at most three days to build, not the weeks it once did.
The library described above was the product's second design system. The first had its own research behind it and a simpler language, with twins drawn as objects on a canvas, but it kept hitting the problem the whole product had: people could not easily grasp a twin as an abstract round thing on a screen. The onboarding sprint resolved that by changing what the product was about, from twins as objects to data products that people connect and share. The circles became cards and the light theme became dark, and that language carried into the second iteration of the company website, which I also designed.
Embedding the habit, not the artefacts
Artefacts decay; cadence survives. I ran regular design sprints with product and engineering, put usability testing into every release cycle rather than around it, and folded accessibility and research-led thinking into how features were defined. Across the two years that added up to more than forty research sessions, from low-fidelity concept tests before the onboarding sprint to sessions on the shipped interface with a mix of individuals and business customers. I brought designers in and built their judgement on the system and on research rather than handing them tasks to run.
The goal was a practice that did not need me in the room to function: by the end, the designers I had mentored were making the call on new patterns themselves, on-system, instead of waiting for me to decide.
Decisions and trade-offs
Three calls shaped the practice more than any single screen.
System time against roadmap time. As the only designer at the start, every hour on the library was an hour off a feature. I balanced it by building a component only when a second use appeared, so the system grew from real repetition rather than speculation.
Research depth against release tempo. With releases coming regularly, I could not research everything deeply, so I kept research light and frequent and saved the depth for decisions that would be expensive to get wrong. Tempo won most weeks, on purpose.
Polish, deliberately held back. I chose not to refine designs to a high finish before they shipped. A polished screen built on a guess was worth less than a rough one in front of real users, so I shipped at lower fidelity and let real use show me where the polish was worth spending.
What the practice looked like when I left
When I left, the practice was something the company had rather than someone it relied on. The component library was maintained and in everyday use, the research and testing cadence ran without me convening it, and the designers I had hired were carrying the work forward.
Reflection
Founding a function teaches the difference between doing design and installing it. The deeper lesson was about what I was designing in the first place. The hard part was never a screen, it was making an abstraction legible: giving people a way to hold a concept they had never seen. That reframed the job for me as shaping data relationships rather than layouts, and it is the instinct I took straight into enterprise risk work at a global bank.