Why the system had to exist
Every product team was solving the same visual problem from scratch. Buttons with five different border radii. Three interpretations of the same status badge. Design inconsistency was slowing shipping velocity and eroding user trust.
0
Products sharing one Figma library
0
Core components, all states documented
0 wks
From zero to v1, while shipping product
Three challenges that forced the system
Consistency
Products started looking inconsistent — five different button radii, three interpretations of the same status badge.
Collaboration
Constant back-and-forth between designers and developers. No single source of truth meant every handoff needed renegotiating.
Ease of Use
Teams built custom solutions for patterns that should have been reusable. Effort spent reinventing, not building.
The constraint was the brief: no dedicated systems team, no runway to pause product work. The system had to be designed in the gaps, documented enough to survive handoff, opinionated enough to actually reduce decisions.
Approach
Token-first
Every colour, spacing step and shadow is a named token. Swap the token, update every instance.
Component contracts
Each component ships with defined props, states and usage rules. No ambiguity in handoff.
Built while shipping
Tokens and components introduced incrementally alongside real features — not in a silo.
Documentation as design
The Figma file is the doc. Annotations live inside frames, not in a Notion page nobody reads.
Design systems start with strong foundations.
They define how components look, behave, and scale across the entire product.
What’s inside
A unified system of reusable foundations and components that brings clarity, consistency, and structure to every interface.
Color System
Semantic tokens and palettes for scalable themes and clear visual hierarchy.
Lato
Bold · Semi Bold · Regular
Typography
A flexible type system with predefined roles and scales for readable interfaces.
Spacing & Radius
Structured spacing and corner rules that keep layouts balanced and predictable.
Icons
A unified icon set at a single stroke weight. Every icon at 20×20 dp.
Grid System
Responsive grids for consistent layouts across screen sizes and breakpoints.
sm
md
lg
Shadows & Blurs
Depth and elevation styles that add clarity, focus, and visual rhythm.
Atomic Design Principles
A modular approach that breaks interfaces into reusable pieces, making their structure clear and connected.
Design Tokens
Core variables that define colours, typography, spacing.
Atoms
The smallest UI parts: icons, buttons, and input fields.
Molecules
Groups of atoms forming simple components.
Organisms
Larger components made of molecules and atoms.
Templates
Layouts showing how components connect within a structure.
Screens
Final screens assembled from components with real content.
Color System
A flexible palette of semantic and functional colours that keeps interfaces consistent, clear, and expressive across the entire product.
Neutral
Backgrounds, text, surfaces, separators.
Brand
Primary interactive elements: CTAs, links, active states.
Error
Negative states, destructive actions, validation errors.
Success
Positive confirmation, completed states, available status.
Warning
Cautionary states, pending actions, time-sensitive alerts.
Token flow — tap a layer to trace the chain
Raw hex values live in the primitive layer. They are never used directly in components.
Lato
Typography
The typographic system defines text styles as design tokens and explains how titles and body text should be applied.
Ag
Bold
Ag
Semi Bold
Ag
Regular
H1 Desktop
47px · Bold
H2 Desktop
37px · Bold
H3
29px · SemiBold
H4
21px · SemiBold
Body Large
17px · Regular
Body
15px · Regular
Caption
13px · Regular
Label
11px · Medium
Spacing & Radius
A consistent spacing and radius scale creates visual rhythm and predictable layouts. Each value exists as a reusable token.
2px
4px
6px
8px
12px
16px
20px
24px
32px
40px
48px
64px
Border Radius Scale
sm
4px
md
8px
lg
12px
xl
16px
2xl
24px
full
999px
Iconography
A unified icon library at a single stroke weight. Every icon exports at 20×20 dp. Mixing icon styles is the fastest way to make a UI feel cheap.
Components
Smart components adapt automatically to states, themes, and content — reducing manual work and maintaining consistency across every screen.
Handoff gaps live in the unstated. If hover is not designed, engineering invents it. If loading is not specified, it gets cut. Documenting every state per component upfront costs hours. Fixing state inconsistencies in production costs weeks.
Buttons
Four variants: primary, secondary, tertiary, ghost. Every state documented. No one-off styles.
Input Fields
Seven states, three sizes. Error and helper text are baked in — not detached text layers.
Checkbox, Radio & Toggle
Indeterminate state explicitly handled — a gap most teams discover in production.
Dropdown & Select
Multi-select, single-select, searchable. Inherits input anatomy: same tokens, same spacing.
Tabs & Navigation
Line and pill variants. Active state uses the accent token — swap the theme and every tab updates.
Date & Time Picker
Travel-critical. Range selection, blocked-date states, time picker — the most-requested in v1.
System in Production
The system only matters if it shows up in production. Here’s how foundations and components assemble into the AirIQ booking flow.
Search
Date picker, passenger selector, airport autocomplete — all system components. The booking entry point assembles in half the time it used to.
Results
Status badges (Direct / Economy / Delayed) are tokens. Grid rhythm is the layout system. Sorting controls use Dropdown. Zero custom overrides.
Booking
The traveller detail form is Input, Dropdown and Checkbox in sequence. One component library, one form, consistent across every device width.
Confirmation
Typography scale and colour tokens carry the hierarchy. The success state reuses the Badge component — semantic colour, different meaning.
The question I asked for every AirIQ screen: “Is this a component or a custom?” If it needed to be custom, that was a signal the system had a gap. I plugged it.
Impact
A design system is not a deliverable — it’s a multiplier. These are the results after three months in production.
Before
5+ button styles across product screens
Ad hoc spacing — every designer eyeballed it
Icon library split across three Figma files
No documented component states
Onboarding new designers took 2+ weeks
After
4 button variants, every state documented
8pt grid enforced via auto-layout
Unified icon library, one stroke weight
States and usage rules live inside components
New designers contribute by day 3
0%
Faster screen assembly
for screens built entirely from library components
0 wks
From 0 to v1
while simultaneously shipping product
Adoption beats perfection
A system no one uses is a system that does not exist. Ship an imperfect v1 fast, iterate based on real usage — not theoretical completeness.
Tokens are the real leverage
Components can be rebuilt. Tokens are load-bearing. Getting naming conventions right early saved weeks of migration work later.
Next case study
Air IQ: B2B Flight Booking→Thanks for sticking around ✌️
Building a design system is mostly invisible work — until it isn’t. Hope this gave you a glimpse of what goes into making consistency feel effortless.
Say hi ↗