OVERVIEW
Scaling design consistency for a complex product.
MY ROLE
Product Designer
TIMEFRAME
2023
LOCATION
Vancouver/Boston
CONTEXT
Small team, complex products, decision fatigue.
Radix Labs was a ~12-person startup building a suite of tools for lab scientists. As one of two designers, I was embedded directly with the engineering team, with no design leadership above me.
It started as a tiny, nagging feeling- the same button appearing five different ways, even background colours that seemed to be ever so slightly different. Every new feature I worked on was a negotiation with existing UI. Do I match what’s here, or over there?
🚨
Patterns and components multiplied all over the codebase with no shared language between design and engineering, with every new feature inheriting the inconsistency of the last.
PROBLEM
Diagnosing the inconsistency issue
Going through every live screen in production, I found nine versions of the same button, font inconsistencies, and different filter interactions.
The key finding was the gap between Storybook components and what was live in production. Many features were built in parallel, small decisions made independently, and the distance between them grew without anyone noticing.
I pulled the most concrete examples together and walked the team through what I’d found.
APPROACH
A leaner scope for a leaner team
The simpler fix was a visual QA pass - go through the product, clean up the most obvious issues and move on. However, the audit made it clear that most of the inconsistencies (buttons, colour, typography) were foundational.
Without a shared foundation, the same decisions would get made differently again in six months. This made Atomic Design a natural fit. Focusing on atoms first kept the scope lean while delivering the majority of the consistency gains, and a small team needed a system it could actually maintain.
FOUNDATIONS
Building clear foundations with design tokens
While staying true to Radix Labs existing brand guidelines, I focused early effort on the foundations of typography, colour, and spacing defined as design tokens rather than static values. Getting these right before touching a single component was what would make the system maintainable long-term. To inform the token architecture, I referenced industry-leading design systems including Shopify Polaris, Atlassian Design System, and Salesforce Lightning.
I worked directly with engineers to co-create our design tokens, our colourspaces, and our typography. A shared Airtable served as both documentation and as a project management tool as the system grew.
Atoms, molecules, and organisms
Atoms like buttons, inputs, and badges were defined with their full range of variants and states, each referencing the token system rather than hardcoded values. Molecules and organisms came next as sample implementations- enough to demonstrate how atoms combined into real UI patterns without overextending the scope for a team our size.
As I designed and documented each component, engineers were building them directly into the codebase, finally aligning Storybook and production UI. The shared Airtable tracked progress for both sides, with atoms getting checked off as they moved from design to implementation.
DOCUMENTATION
Ensuring a system sticks and scales
For a team our size, elaborate documentation would have been its own maintenance burden so I focused on what engineers and future designers actually needed in their day-to-day.
Component specs lived in Figma, capturing variants, states, and token references. Engineers were referencing it actively during the build phase, which meant documentation was being stress-tested in real time rather than written for a hypothetical future user.
OUTCOMES
Enabling speed, collaboration, and product quality
Although not measured in metrics, this small but mighty project’s impact was visible in what the team no longer had to think about.
