Scaling a Design System Without Slowing Teams Down

Scaled, documented, and operationalised a design system across multiple teams, with measurable drops in inconsistency and time spent in meetings.

The library existed, the problem was the gap between what it said and what teams were actually building – two primary teams (Concept and Design) working in parallel, drifting apart without realising it, and spending more time in clarification meetings than they should have been.

The handoff process existed but wasn't clear enough to run consistently. Within the context of the new library, I helped (along with my colleagues) define how components should be handed off, making sure the documentation was detailed enough that engineering had what they needed without having to chase anyone for answers. Not a reinvention, but enough of a clarification to remove most of the friction.

Design documentation and engineering documentation were drifting from each other – small gaps, but enough to cause confusion at handoff. I used AI to check one against the other at regular intervals, catching misalignment before it compounded. The result was fewer surprises at handoff and less time spent in back-and-forth between design and engineering trying to reconcile two versions of the same truth.

I ran working sessions, and basic and advanced trainings, throughout the whole project. These were recurring, not occasional. Teams brought actual problems from their day-to-day work, we solved them together, and the system kept improving because of it. That's what turned adoption from theoretical to real. Alongside that, I ran onboarding sessions for new team members, getting them up to speed on the system and handoff process without needing to slow anyone else down.

In six months we shipped the new library and integrated the new handoff process. My workshops and sessions kept doubts and questions from snowballing – fewer inconsistencies, better quality work coming out of both teams, less time lost to meetings that existed only because the process around the system wasn't clear. The teams kept running it after the project ended. That's usually the part that tells you whether you actually solved the problem or just managed it for a while.