Building the Foundations of a Scalable Design System
Overview
As the company scaled, I saw first-hand how fragmented our design and development had become. UI patterns drifted, handoffs were inconsistent, and teams were constantly re-solving the same problems. I stepped in to lead the early groundwork of a design system that could bring alignment - not just in visuals, but in how we worked across design and engineering.
Process
I kicked things off with a full UI audit and started working closely with the design team to define shared foundations - typography, colours, spacing, and reusable patterns. Alongside this, I designed and built a custom CSS architecture and internal platform to document and distribute the system. But this wasn't just about frameworks - it was about embedding myself in teams, collecting feedback, and helping make adoption as smooth as possible.
Outcome
The MVP design system launched with immediate adoption across core product teams. It gave designers and developers a shared foundation to build from, improved consistency, and sped up delivery. While simple by design, it set the stage for future scaling and helped teams shift toward more standardised, collaborative ways of working.
The Problem: Design Wasn't Scaling with the Product
Our visual language had become inconsistent. Design files didn't match what was being built, and developers often implemented the same UI elements in different ways. There was no central reference, and no shared process for reuse - just workarounds and duplication.
I wasn't brought in to add documentation - I was there to help fix the system by designing one that could actually be used.
Auditing What We Had, Designing What We Needed
I started with a deep audit - across screens, Figma files, and live code. I catalogued everything from global styles to repeated patterns and edge-case components. That surfaced a lot of noise, but it also revealed where the common ground was.
Working with the design team, I helped define the foundational pieces: tokens, type, colour, spacing, layout patterns. These weren't abstract principles - they were chosen based on real UI, real constraints, and real needs across the customer-facing product.
The design audit wasn't just about cataloguing inconsistencies - it was about identifying what teams actually needed to build with confidence.
A System Built to Fit the Way Teams Work
I designed and built a custom internal site to house the design system, along with a CSS architecture + components that allowed for modular, incremental adoption. This wasn't a top-down rollout - it was something I shaped in the open, through conversations, pairings, and hands-on implementation.
I joined stand-ups, tested assumptions directly with developers, and embedded myself in teams as they started using the system. That meant catching edge cases early, adapting styles based on feedback, and making sure the system could flex without falling apart.
By designing for how people actually worked - not just how we wanted them to-we built something teams were excited to adopt
Built for Adoption, Not Just Aesthetics
The system served multiple roles:
- Designers got clear, shared styles and usage guidance
- Developers got lightweight, modular CSS components they could drop in with minimal ramp-up
- Marketing teams had access to consistent assets like logos and type across channels
But the real power came from keeping it simple and useful. I wasn't chasing pixel-perfect abstraction. I was building a foundation that worked in messy, everyday reality.
Iteration, Not Isolation
Even though I owned the system's build and structure, I didn't do it behind closed doors. I shared work early, tested in real products, and treated feedback as a core part of the process.
One of the most useful signals came from hearing directly from devs who said they could move faster, with fewer bugs and less back-and-forth. That was the point-create something that felt like it belonged, not something imposed.
The system didn't have to be perfect to be useful - it just had to meet people where they were and help them move forward together.
Reflections
This wasn't about delivering a polished styleguide. It was about setting direction - building the first layer of trust and consistency between design and development.
By staying close to teams and designing for adoption, not just aesthetics, we turned the early version of the system into something real. It made delivery faster. It made decisions easier. And it helped the product and the people working on it scale more smoothly.