YAS — Design System Integration

Every new client meant a new design file. Over time, the company had accumulated 11 separate app files, each with its own components, naming conventions, and assets — most of them variations of the same elements, built and rebuilt from scratch each time.

The consequences compounded quietly. Designers spent significant time managing and syncing near-identical files. When team members changed, there was no reliable way to know which file was current. And because only designers knew where things lived, every other department — marketing needing visuals, account managers preparing client materials — had to come to us directly. The design team had become an unnecessary bottleneck.

I proposed the project myself, with a deliberately modest goal: not a perfect design system, but a practical one. Something that engineers, marketers, and account managers could actually navigate and use without needing a designer to translate it for them.

Using atomic design as my framework, I built from the ground up — defining typography, spacing, colour, and iconography first, then systematically working up to components, documenting naming conventions, states, and usage guidelines for each. The north star throughout was consistency and clarity, not comprehensiveness.

Auditing 11 apps didn't just surface redundancies — it surfaced design bugs. Some were app-specific. Others ran across the entire product line.

One stood out: a client had requested a single vivid red as their primary colour, removing the secondary colour entirely. No one had raised a concern at the time. But red was also the colour used for error states — meaning users could easily misread a primary action as a warning. The product still functioned, and the client had signed off, so there was no urgent fix to make.

But I could document it. I added a notes layer to the design system — capturing edge cases like this one as annotated guidelines. The goal wasn't to reopen closed decisions, but to make sure future client onboarding conversations were better informed, and future designers wouldn't make the same call without knowing the tradeoffs.

When the first version was ready, I presented it at a company all-hands. The framing mattered to me: this wasn't a tool for designers. It was infrastructure for everyone.

Marketing could find assets without filing a request. Account managers could pull materials before a client meeting without looping in the design team. Engineers had a single reference point for component specs. The design system was less a design deliverable and more a communication platform — one that happened to be built by a designer.

The response from engineering was particularly strong. Across departments, the shift was noticeable: less back-and-forth, fewer requests for files that should have been findable, more autonomy for the people who needed the assets most.

This project taught me that design systems aren't really about design. They're about how organisations share knowledge and reduce friction. The visual and component work was the easier half — the harder part was understanding what each team actually needed from a shared system, and building something that served all of them without requiring a designer in the room.

Looking back, I'd invest more time earlier in interviewing the non-design stakeholders — engineering, marketing, KAM — before building. I made reasonable assumptions about what they needed, and most of them were right. But their direct input would have made the system more robust from day one.