Building one design language for a platform that had grown in every direction at once
Design systems
Multiplatform
Component library
Sketch
Token architecture
Lead Designer (co-owner)
4,5 years
Web, iOS, Android
Sketch, Miro
3 designers, 20 developers
CONTEXT AND PROBLEM
The platform had grown faster than the rules could keep up
The event management platform had been built iteratively over several years. Each sprint added new screens, new flows, new components. Nobody was doing anything wrong, but the cumulative effect was a UI that had quietly fragmented. Buttons looked different across pages. Spacing was eyeballed. The same UI element existed in four slightly different versions across the codebase, with no clear owner and no single source of truth.
For designers, this meant every new screen required rediscovering what already existed and deciding which version to use. For developers, it meant building the same thing multiple times and not knowing which implementation to follow. For the product, it meant a platform that felt inconsistent in ways users couldn’t name but definitely felt.
I was brought in as one of two owners of the design system. My job was to audit what existed, establish the rules, build the library, and make sure 20 developers could actually use it.
RESEARCH
You can’t fix what you haven’t mapped
Before touching Sketch, I ran a full UI audit across all three platforms. I pulled screenshots of every screen in the product, printed them on Miro, and started grouping. What looked like one button was actually six: different corner radii, different font sizes, different padding, different hover states. Same story for inputs, modals, and navigation patterns.
6
button variants found in the wild before consolidation
0
shared token system before the project started
~40
%
of existing components had platform-specific divergence
3
separate Sketch files with no shared library
”Every time I started a new screen I had to look at five different places to figure out which button was the right one. Half the time I just picked the one that looked closest.
Designer, pre-system audit interview
The audit took three weeks. At the end of it I had a clear map of what existed, what was duplicated, what needed to be standardised, and what could be retired. That map became the backlog for everything that followed.
DESIGN PRINCIPLES
Four rules the whole system is built on
Platform-aware, not platform-specific
Components share design intent across web, iOS and Android, but respect each platform’s native patterns where it matters.
Useful before it’s complete
Ship the highest-value components first. A partial system that teams actually use beats a perfect system still in progress.
One source of truth
Every component lives in one place. No more “which version is the right one?” If it’s in the library, it’s the right one.
Developers are users too
Every component ships with usage notes, dos and don’ts, and clear naming. If a developer has to guess how to use it, the documentation failed.
DESIGN PROCESS
From scattered files to a shared library
1
Full UI audit across all three platforms
Three weeks in Miro, pulling every screen from web, iOS and Android and grouping components by type. The goal was to see the full picture before making any decisions. What I found was worse than expected, which made the priority order much clearer.
Three weeks in Miro, pulling every screen from web, iOS and Android and grouping components by type. The goal was to see the full picture before making any decisions. What I found was worse than expected, which made the priority order much clearer.
2
Token foundation first
Before a single component was designed, I established the token layer: colour, typography, spacing and radius. Tokens had to work across all three platforms, which meant being explicit about where web, iOS and Android shared values and where they had to diverge. Every subsequent component decision traced back to a token.
Before a single component was designed, I established the token layer: colour, typography, spacing and radius. Tokens had to work across all three platforms, which meant being explicit about where web, iOS and Android shared values and where they had to diverge. Every subsequent component decision traced back to a token.
3
Core components, prioritised by usage
I ranked components by how often they appeared across the product. Buttons, inputs, modals, navigation patterns, cards. These shipped first. Each one went through a review cycle with both designers and developers before being published to the shared library.
I ranked components by how often they appeared across the product. Buttons, inputs, modals, navigation patterns, cards. These shipped first. Each one went through a review cycle with both designers and developers before being published to the shared library.
4
Developer handoff and documentation
A component without documentation is a component nobody uses correctly. For each one I wrote usage guidelines, naming conventions, variant descriptions, and edge cases. I ran two workshops with the dev team to walk through the library and collect questions I hadn't thought to answer.
A component without documentation is a component nobody uses correctly. For each one I wrote usage guidelines, naming conventions, variant descriptions, and edge cases. I ran two workshops with the dev team to walk through the library and collect questions I hadn't thought to answer.
5
Migration plan for existing screens
The hardest part wasn't building the system. It was getting existing screens onto it without breaking the product. I worked with the dev team to prioritise migration by feature area, starting with the most visible and highest-traffic screens. We didn't aim for 100% adoption on day one. We aimed for momentum.
The hardest part wasn't building the system. It was getting existing screens onto it without breaking the product. I worked with the dev team to prioritise migration by feature area, starting with the most visible and highest-traffic screens. We didn't aim for 100% adoption on day one. We aimed for momentum.
6
Ongoing maintenance and contribution model
A design system without maintenance is a design system on a countdown. I set up a contribution process: any designer or developer could propose a new component or a change, with a clear review flow to decide whether it belonged in the system or stayed product-specific. Two owners meant nothing fell through the cracks for long.
A design system without maintenance is a design system on a countdown. I set up a contribution process: any designer or developer could propose a new component or a change, with a clear review flow to decide whether it belonged in the system or stayed product-specific. Two owners meant nothing fell through the cracks for long.
RESULT
A system teams actually used
Measured 6 months after the core library shipped:
200+
components in the shared library
across web, iOS and Android
-60%
time spent on component decisions per sprint
↓ self-reported by design team
~80%
of new screens built entirely from the library
6 months post-launch
0
new button variants introduced outside the system
after library adoption
”I used to spend half a day figuring out what already existed before I could start designing. Now I open the library, find what I need, and I'm building by lunch.
Designer, 6-month post-launch interview
TAKEAWAYS
What I took away from this project
- The audit is the project. You can’t design a system for a product you haven’t fully mapped. The three weeks I spent in Miro before touching Sketch were the most valuable three weeks of the whole thing. Everything that came after was faster because the audit had already answered the hard questions.
- A design system is a social contract as much as a technical one. Getting 20 developers to use it required more than good components. It required trust. That meant shipping documentation that actually answered their questions, running workshops instead of just sending a link, and being responsive when something in the library didn’t work for their use case.
- Ship useful before you ship complete. I’ve seen design systems stall for months while teams debate the perfect token naming convention or the ideal component API. The teams that made the most progress were the ones that shipped the highest-value components first, got feedback, and iterated. A perfect system nobody uses is worth nothing.