Ways of Working · Clinical Trial Platforms · T-Systems
Rebuilding how a team
delivers
The design system and prototype engine I built to replace handoff with a single, living source of truth, in a regulated clinical environment.
a PDF, or a Figma link
a build the team pulls from
down from weeks
the standard handoff
At a glance
Design reached engineering through static handoff, so interaction detail was lost and UX arrived late. Leadership wanted the team to use AI but gave no direction on what to automate.
I set the direction, then built it. The strategy, the single source of truth, the prototype engine, the front end, and the rollout to the team.
- Unify the fragmented design system into one source of truth before building anything on top of it.
- Make the prototype a working replica of the product shell, so it carries the real interaction rather than a picture of it.
- Run it on branches: a sandbox to test accessibility and changes, and a build branch engineering pulls production code from.
Handoff became one shared URL, now the standard engineering handoff across four module teams. Design turnaround dropped from weeks to days, planning got sharper, and both product owners and end customers backed the new way of working.
Context
Design kept getting lost on the way to build.
On clinical trial platforms, work moved from design into engineering through static handoff: mockups, PDFs, and prototype links. Engineering rarely drove those prototypes, so interaction detail got read as optional. What shipped was often a partial version of what was designed, with the unclear parts filled in by assumption.
This is an old problem between design and development, and it followed me across teams. UX usually arrived late, or after the decisions were already made. The fix was never going to be a better mockup. It had to be a different way of working.
The Mandate
A mandate for AI, and no direction.
Leadership wanted the team to do something with AI. There was backing for that, but no view on which path to take or what was worth automating. I took it as mine to work out.
I wrote the plan first: what to change, in what order, and why, before touching any tooling. The sequence mattered more than the tools. Automate the wrong step and you speed up a broken process. I decided the foundation had to come before anything that generated screens.
Foundation
First, one source of truth.
The design system was fragmented. Patterns and decisions lived in different places, none of it easy to maintain or reference. I pulled it into a single source of truth: accessible, maintainable, and holding the real decision patterns behind the product.
Then I updated the design tokens in the product itself, so the design system and the live product spoke the same language. Without that foundation, nothing built on top would stay consistent. This was the unglamorous work that made everything after it possible.
The Engine
A prototype engine the whole team can drive.
On that foundation I built a prototype engine, hosted internally alongside the design system. Anyone on the team can use it. It produces a working replica of the actual product shell that the team can click through, so what people review is the real interaction, at the real fidelity.
Sandbox work gets pushed into the shared prototype, so the version everyone sees is always the current one. I layered dedicated skills onto the engine to keep its output aligned with the system, and structured the whole thing so a designer works in the product, not next to it.
A working shell, not a picture
The prototype is a replica of the live application. People navigate it the way they will use the product, so the interaction is understood, not imagined.
One place, always current
Sandbox work is pushed into the shared prototype. There is one version to look at, and it is the latest one, so nobody hunts for the newest file.
Built on the source of truth
Output draws on the unified design system, so screens stay on system by default instead of drifting and needing a cleanup pass.
Skills to hold the line
Dedicated skills sit on top of the engine to keep what it produces aligned with the patterns and tokens, without a manual review every time.
Delivery
The handoff became a link.
Now nobody shares a mockup, a PDF, or a Figma link. We share one URL, the actual product structure. The engine runs on branches: a sandbox where I test accessibility and other improvements before they go anywhere, and a branch the development team pulls from directly, taking the production ready front end straight out of the artifact the design was built in.
Everyone sees the same current state, so there is no chasing and no manual follow-up to find the latest version. Because you navigate the real thing, the interaction flow is not open to interpretation, and the old gap where design was never fully implemented is closed. Critique happens on the live artifact instead of a flat image.
Impact
What changed
The work is live and still young, so these are the changes the team is seeing now, described without numbers I cannot stand behind. The delivery figures are my own read from inside the team.
Weeks became days
Design work that ran fifteen to twenty days, sometimes a month, now reaches a ready state in a few days.
Developers build from the design
Engineering pulls the production front end straight from the build branch, which removed a rebuild step and gave the team time back. This was one of the biggest wins.
A safe place to test
A separate sandbox branch holds accessibility work and other improvements, so changes are tested before they reach anyone.
The full experience, built in
Interactions are built end to end, so what people review and estimate against is the complete flow, with the interaction detail already in place.
Sharper planning, no chasing
Teams estimate accurately against the real thing, one current URL removes manual follow-up, and nothing about the interaction is left to assumption.
Adopted across four teams
Four module teams, more than 25 people, now use the shared prototype as the standard engineering handoff. Product owners backed the change, and in a recent customer session we presented through it instead of static mockups, on work that had no UX before and had been reworked. The response turned around and they asked to see more.
Where this goes next
The same shift is starting to reach testing. Because the prototype is the real interaction rather than a static picture, QA can read behaviour straight from it, write test cases against the actual flow, and map end to end coverage to something concrete instead of a document. That work is underway, and the direction is a shorter path from a design decision to a tested build.
What I Learned
Four things I took from leading this.
Set the direction when none is given
The mandate was vague on purpose. Someone had to decide what to automate and in what order, and I treated that as the job rather than waiting for a clearer brief. That decision is where the value was, more than any single tool.
Fix the foundation before you automate
Automating on top of a fragmented system would have scaled the mess. Unifying the source of truth first was slow and unglamorous, and it was the reason everything built on top stayed consistent.
Adoption is the real test
Getting people to trust one shared link over habits they had held for years was harder than building the thing. A tool nobody opens changes nothing, so I designed the workflow around how the team actually works.
Managing and making were the same job
The source of truth only works if the decision patterns behind it are right, and the shell only earns trust if the interaction detail holds up. Leading this and doing the craft were not separate roles here.
The tooling matters less than the fact that a team changed how it works. I had a vague mandate, set the direction, and got people to deliver from one living artifact instead of a pile of static files. Craft carried all of it.
All visuals on this page are schematic diagrams, not product screenshots. The work is described without proprietary implementation detail or patient data.