Introduction: Why Design Systems Matter

A design system isn't just a component library. It's the single source of truth for your product's design, ensuring consistency, speed, and quality at scale.

Without a design system:

Designers rebuild components repeatedly
Inconsistent UI across product
Developers guess at implementation
Slow feature development
Quality declines as team grows

With a design system:

Components built once, used everywhere
Consistent user experience
Clear developer specifications
3-4x faster feature development
Quality maintained at scale

This guide covers:

When to build a design system
How to structure it effectively
Figma implementation workflows
Developer handoff processes
Scaling across teams
Real examples from production products

Based on: 50+ design systems built at Precode, from startups to enterprises, web and mobile applications.

Part 1: When to Build Your Design System

Signs You Need a Design System

You should build a design system if:

Multiple designers:

2+ designers working on product
Inconsistent component styles
Duplicated work
No single source of truth

Growing product:

30+ unique screens
Multiple features launching
Cross-platform (web + mobile)
Regular new features

Developer handoff issues:

Developers asking spacing questions
Inconsistent implementation
Slow development
Quality issues

Team scaling:

Hiring more designers
Product team growing
Multiple squads
International teams

When NOT to Build One (Yet)

Don't build a design system if:

Early MVP stage:

Under 20 screens
Still validating concept
Features changing rapidly
Solo designer

Limited resources:

No dedicated design time
Urgent features needed
No designer yet
Bootstrap stage

No pattern repetition:

Every screen unique
Creative/agency work
One-off projects
Brochure sites

The rule: Build design system when you're rebuilding the same components for the third time.

Part 2: Design System Foundations

What Belongs in a Design System

Core elements:

1. Design tokens

Colours (primary, secondary, semantic)
Typography (sizes, weights, line heights)
Spacing (4px, 8px, 16px, 24px, 32px, 48px, 64px)
Border radius (0px, 4px, 8px, 16px, full)
Shadows (elevation system)
Breakpoints (mobile, tablet, desktop)

2. Component library

Buttons (primary, secondary, tertiary, ghost, danger)
Form inputs (text, email, password, number, tel, search)
Select dropdowns (single, multi-select, searchable)
Checkboxes and radio buttons
Toggle switches
Date and time pickers
Cards and panels
Modals and dialogs
Navigation (headers, footers, sidebars, tabs)
Tables (sortable, filterable, paginated)
Lists (ordered, unordered, definition)
Badges and tags
Avatars and profile images
Icons (interface, brand, social)
Loaders and spinners
Progress indicators
Tooltips and popovers
Alerts and notifications
Empty states
Error states

3. Patterns and layouts

Page templates
Grid systems
Responsive behaviour
Common flows
Animation principles

4. Documentation

Usage guidelines
Do's and don'ts
Accessibility requirements
Code snippets
Example implementations

Design System Structure

Atomic design approach:

Atoms (smallest components):

Buttons
Input fields
Labels
Icons
Typography styles

Molecules (simple combinations):

Form field (label + input + error message)
Search bar (input + button + icon)
Card header (image + title + metadata)

Organisms (complex components):

Forms (multiple fields + validation)
Navigation bars (logo + links + actions + mobile menu)
Cards (header + body + footer + actions)
Tables (headers + rows + sorting + pagination)

Templates (page structures):

Dashboard layout
Form pages
List pages
Detail pages

Why this structure works:

Clear component hierarchy
Easy to maintain
Scalable
Reusable at every level

Part 3: Figma Implementation Workflows

Setting Up Your Figma Design System

File structure:

📁 Design System
├── 📄 0 - Design Tokens
│ ├── Colours
│ ├── Typography
│ ├── Spacing
│ └── Elevation
├── 📄 1 - Atoms
│ ├── Buttons
│ ├── Inputs
│ ├── Icons
│ └── Typography
├── 📄 2 - Molecules
│ ├── Form Fields
│ ├── Cards
│ └── Navigation Items
├── 📄 3 - Organisms
│ ├── Headers
│ ├── Forms
│ ├── Tables
│ └── Modals
└── 📄 4 - Templates
├── Dashboard
├── List Page
└── Detail Page

Design tokens setup:

Colours:

Primary/100-900 (9 shades)
Secondary/100-900
Success/100-900
Warning/100-900
Danger/100-900
Neutral/100-900
Use Figma colour styles

Typography:

Headings (H1-H6)
Body (Regular, Medium, Bold)
Captions
Labels
Use Figma text styles

Spacing:

Create spacing components
4px base unit
Multiples: 4, 8, 12, 16, 20, 24, 32, 40, 48, 64, 80, 96
Use for margins, padding, gaps

Elevation (shadows):

Level 0 (flat)
Level 1 (subtle, cards)
Level 2 (dropdown)
Level 3 (modal)
Level 4 (highest elevation)
Use Figma effect styles

Component Best Practices

Variants in Figma:

Button example:

Properties:
- Type: Primary, Secondary, Tertiary, Ghost, Danger
- Size: Small, Medium, Large
- State: Default, Hover, Active, Disabled
- Icon: None, Left, Right, Only

Result: 5 types × 3 sizes × 4 states × 4 icon positions = 240 variants

But smart organisation:

Only create variants you actually use
Group related states
Use component properties
Auto-layout for flexibility

Input field example:

Properties: - Size: Small, Medium, Large - State: Default, Focused, Error, Disabled, Success - Has Label: True/False - Has Helper Text: True/False - Has Icon: None, Left, Right

Auto-layout settings:

Vertical stack for label + input + helper
Horizontal stack for icon + input
Spacing: 8px between elements
Padding: 12px (medium), 8px (small), 16px (large)
Fill container width
Hug contents vertically

Component Documentation in Figma

For each component, document:

Usage:

When to use this component
When NOT to use it
Common use cases
Alternative components

Anatomy:

Visual breakdown
Part names
Spacing specifications
Size constraints

States:

All interactive states
Transition behaviour
Animation duration

Accessibility:

ARIA labels
Keyboard navigation
Screen reader text
Colour contrast

Code:

HTML structure
CSS classes
React component name
Props/API

Example documentation:

Button Component
================

Usage
-----
Use buttons for primary actions like "Submit", "Save", "Continue".
Don't use buttons for navigation (use links instead).

Anatomy
-------
- Icon (optional): 16px, 8px margin-right
- Label: Medium weight, 14px/16px depending on size
- Padding: 12px horizontal, 8px vertical (medium)
- Border-radius: 8px
- Min-width: 80px

States
------
Default → Hover (0.15s ease)
Hover → Active (0.1s ease)
Active → Default (0.2s ease)

Accessibility
-------------
- Focusable via Tab key
- Activated by Enter or Space
- Focus ring: 2px primary-500, 4px offset
- Min touch target: 44×44px

Code
----
Component: <Button />
Props: variant, size, icon, onClick, disabled, loading

Responsive Behaviour

Breakpoint system:

Mobile: 320px - 767px Tablet: 768px - 1023px Desktop: 1024px+

Responsive patterns:

Stack on mobile:

Horizontal layouts → vertical on mobile
Side-by-side → stacked
Multi-column → single column

Hide on mobile:

Tertiary navigation
Extra metadata
Decorative elements
Secondary actions

Adapt sizing:

Larger touch targets (44×44px minimum)
Bigger typography
More padding
Simplified layouts

Component examples:

Navigation:

Desktop: Horizontal menu bar
Tablet: Horizontal with collapsed secondary
Mobile: Hamburger menu

Cards:

Desktop: 3-column grid
Tablet: 2-column grid
Mobile: Single column

Forms:

Desktop: 2-column layout
Tablet: 2-column for short fields, 1-column for long
Mobile: Always 1-column

Part 4: Developer Handoff Process

Preparing Components for Development

Component specifications:

For every component, provide:

Visual specifications
- All states
- Spacing (margins, padding)
- Sizing (width, height, min/max)
- Typography (font, size, weight, line-height)
- Colours (with hex codes)
- Border radius
- Shadows
- Borders
Behaviour specifications
- Hover effects
- Click effects
- Focus states
- Loading states
- Error states
- Empty states
- Animation timing
- Transition easing
Responsive specifications
- Mobile behaviour
- Tablet behaviour
- Desktop behaviour
- Breakpoint rules
Accessibility specifications
- ARIA labels
- Keyboard navigation
- Focus management
- Screen reader text
- Semantic HTML
Implementation notes
- Dependencies
- API/props
- Event handlers
- Common mistakes to avoid

Design Token Export

CSS custom properties:

Tailwind config:

Using tools:

Figma Tokens plugin
Style Dictionary
Design Tokens Format Module
Export to JSON, then transform

Component Implementation Examples

Button in React:

Matching Figma specs:

Variants map to props
States handled via CSS
Icons handled via composition
Loading state adds spinner

Developer Documentation

Component README template:

Part 5: Scaling Your Design System

Team Collaboration

Design system ownership:

Small team (1-3 designers):

Shared responsibility
Weekly sync to review additions
Anyone can contribute
Design lead approves

Medium team (4-10 designers):

1 designer owns design system (20-40% time)
Contribution process defined
Monthly review meetings
Documentation maintained

Large team (10+ designers):

Dedicated design ops role
System design team
Formal contribution process
Regular audits and updates
Versioning strategy

Contribution process:

Proposal
- Designer identifies need
- Creates RFC (request for comment)
- Shares with team
Review
- System owner reviews
- Team discusses
- Checks for existing solutions
- Validates need
Design
- Designer creates component
- Documents usage
- Specs for development
- Accessibility review
Build
- Developer implements
- Code review
- Testing
- Documentation
Release
- Added to library
- Announced to team
- Examples provided
- Migration guide (if replacing existing)

Version Management

When to version:

Breaking changes
Major additions
Significant updates
Migration required

Versioning strategy:

v1.0.0 - Initial release v1.1.0 - New components (non-breaking) v1.1.1 - Bug fixes v2.0.0 - Breaking changes

Migration guides:

What changed
Why it changed
How to update
Before/after examples
Automated tools if possible

Example:

Multi-Platform Systems

Web + mobile design systems:

Shared:

Colour tokens
Typography scale
Spacing system
Iconography
Design principles

Platform-specific:

Navigation patterns
Input methods
Gestures
System components
Platform conventions

Structure:

📁 Design System
├── 📁 Core (shared)
│ ├── Colours
│ ├── Typography
│ └── Icons
├── 📁 Web
│ ├── Components
│ └── Patterns
└── 📁 Mobile
├── iOS Components
├── Android Components
└── Patterns

Example differences:

Navigation:

Web: Header with dropdown menus
iOS: Tab bar + navigation bar
Android: Bottom navigation + app bar

Inputs:

Web: Keyboard focus states
Mobile: Touch targets (44×44px min)
iOS: Native pickers
Android: Material date/time pickers

Buttons:

Web: Hover states
Mobile: Press states, no hover
iOS: SF Symbols icons
Android: Material icons

Part 6: Real-World Design System Examples

Example 1: SaaS Dashboard System

Product: Analytics platform
Platforms: Web only
Team: 2 designers, 4 developers

Design system scope:

Colours:

Primary (brand blue)
Data visualisation palette (8 colours)
Semantic (success, warning, danger)
Neutral (greys for UI)

Components (40 total):

Navigation (header, sidebar, breadcrumbs)
Data display (tables, charts, stat cards)
Forms (all standard inputs)
Feedback (alerts, toasts, modals)

Key decisions:

Data visualisation:

Colour-blind safe palette
Consistent chart styles
Accessible contrast
Export functionality

Tables:

Sortable headers
Filterable columns
Pagination
Row selection
Bulk actions
Empty states

Performance:

Virtual scrolling for large tables
Lazy loading charts
Skeleton screens
Progressive enhancement

Results:

New dashboard pages: 2 days (was 5 days)
Bug reports reduced 60%
Consistent experience across product
Onboarding new designer: 1 week (was 3 weeks)

Example 2: Mobile-First B2C App

Product: Habit tracking app
Platforms: iOS and Android
Team: 1 designer, 2 developers

Design system scope:

Colours:

Vibrant, motivational palette
Progress indicators
Achievement colours
Dark mode support

Components (25 total):

Bottom navigation
Habit cards
Progress rings
Achievement badges
Forms and inputs
Onboarding flows

Key decisions:

Gestures:

Swipe actions on cards
Pull to refresh
Long press menus
iOS and Android conventions

Animations:

Celebration animations
Progress transitions
Micro-interactions
Performance budget (60fps)

Dark mode:

Every component has dark variant
Automatic switching
Maintained accessibility
Colour adjustments

Results:

iOS and Android feature parity
Consistent brand experience
Fast feature development
90+ App Store reviews mention "polished UI"

Example 3: Enterprise Internal Tool

Product: Project management system
Platforms: Web
Team: 3 designers, 8 developers, across 4 squads

Design system scope:

Accessibility:

WCAG 2.1 AA compliant
Keyboard navigation
Screen reader support
High contrast mode

Components (60 total):

Complex forms
Approval workflows
Permission controls
File uploads
Comments and annotations

Key decisions:

Governance:

Design ops role created
Monthly reviews
Contribution process
Documentation site

Advanced components:

Rich text editor
Gantt charts
Calendar views
Drag-and-drop builders

Performance:

Component code splitting
Tree shaking
Bundle size monitoring
Lighthouse scores

Results:

4 squads building features independently
Consistent experience across all tools
Reduced duplicate components from 30 to 0
Support tickets down 45%

Part 7: Tools and Resources

Design Tools

Figma (primary):

Component variants
Auto-layout
Design tokens
Team libraries
Version history
Developer handoff

Figma plugins:

Figma Tokens (design tokens)
Content Reel (realistic content)
Stark (accessibility checking)
Auto Flow (user flows)
Instance Finder (component usage)

Development Tools

Component libraries:

React: shadcn/ui, Radix, Headless UI
Vue: Naive UI, Element Plus
Angular: Angular Material
React Native: React Native Paper

Why use existing libraries:

Accessibility built-in
Well-tested
Documented
Community support
Regular updates

Customisation approach:

Use library as base
Override with design tokens
Add brand styling
Extend as needed

Build tools:

Storybook (component documentation)
Chromatic (visual testing)
Style Dictionary (token transformation)
Turborepo (monorepo)

Documentation Tools

Documentation sites:

Storybook (interactive)
Docusaurus (Markdown-based)
GitBook (collaborative)
Custom Next.js site

What to document:

Getting started
Installation
All components
Design tokens
Patterns and layouts
Accessibility
Contributing
Changelog

Good documentation includes:

Live examples
Code snippets (copy-paste ready)
Props/API reference
Do's and don'ts
Accessibility notes
Related components

Part 8: Common Pitfalls and Solutions

Pitfall 1: Over-Engineering

Problem:

Too many variants
Over-abstracted
Complex APIs
Slow to use

Solution:

Start simple
Add variants when actually needed (3rd use case)
Clear component purposes
Easy to use > flexible

Example:

Over-engineered button:

Properties: - Variant: 20 options - Size: 6 sizes - Colour: 12 colours - Shape: 5 shapes - Animation: 8 types = 28,800 variants

Right-sized button:

Properties: - Variant: Primary, Secondary, Ghost, Danger - Size: Small, Medium, Large - Icon: None, Left, Right = 48 variants (actually use maybe 20)

Pitfall 2: No Governance

Problem:

Anyone creates components
Duplicates everywhere
Inconsistent patterns
System ignored

Solution:

Clear ownership
Contribution process
Regular audits
Find and remove duplicates
Educate team

Pitfall 3: Perfect Before Useful

Problem:

Spending months building system
Not shipping features
Never "good enough"
Team builds around it

Solution:

Start with 10-15 core components
Ship and iterate
Add components as needed
80/20 rule

Phase 1 (week 1):

Design tokens
5 atoms (button, input, text, icon, label)
3 molecules (form field, card, nav item)

Phase 2 (week 2):

5 organisms (header, form, table, modal, card)
2 templates (list page, detail page)

Phase 3 (ongoing):

Add as needed
Iterate based on usage
Remove unused components

Pitfall 4: Design-Only System

Problem:

Beautiful Figma file
Never implemented in code
Designers and developers misaligned
System ignored

Solution:

Build in code from day one
Design and development together
Component parity (Figma = code)
Shared documentation
Regular syncs

Part 9: The Precode Approach to Design Systems

5-Day Design System Sprint

What we deliver in 5 days:

Day 1: Foundations

Audit existing product
Define design tokens
Create colour system
Typography scale
Spacing system

Day 2: Atoms

Buttons (all variants)
Form inputs (all types)
Typography components
Icons
Basic elements

Day 3: Molecules

Form fields
Cards
Navigation items
Lists
Badges and tags

Day 4: Organisms

Navigation
Forms
Tables
Modals
Complex components

Day 5: Templates and Documentation

Page templates
Usage guidelines
Developer specifications
Figma organisation
Handoff package

Deliverables:

Complete Figma design system
30-50 components
Full documentation
Design tokens exported
Developer specs

Cost: £10,000+VAT

When to use:

Redesigning product
Scaling design team
Preparing for growth
Improving consistency

Design System Maintenance

Monthly retainer options:

Essential (£1,600/month):

8 hours/month
Bug fixes
Minor updates
Questions answered

Growth (£3,000/month):

15 hours/month
New components
Major updates
Team training

Scale (£5,600/month):

28 hours/month
Dedicated support
Regular reviews
Multi-platform
Custom components

Book discovery call

Part 10: Getting Started Checklist

Week 1: Foundation

Audit existing product (list all unique components)
Define design tokens (colours, typography, spacing)
Set up Figma file structure
Create colour styles
Create text styles
Document spacing system

Week 2: Core Components

Build button variants
Build input variants
Build form field molecule
Create icon library
Document each component
Share with team

Week 3: Complex Components

Build navigation components
Build modal/dialog
Build table component
Build card variants
Create page templates

Week 4: Implementation

Export design tokens
Set up component library in code
Implement 5 core components
Create Storybook
Write developer documentation

Ongoing

Regular team reviews
Add components as needed
Audit for consistency
Update documentation
Version releases

Conclusion: Design Systems That Scale

Good design systems:

Start small
Grow with product
Stay maintained
Serve the team
Enable speed
Ensure quality

The key principles:

Build what you need, when you need it
Document as you go
Design and code together
Make it easy to use
Maintain and evolve

Investment payoff:

Without design system:

Feature: 5 days design, 5 days dev = 10 days
10 features = 100 days

With design system:

System: 5 days one-time
Feature: 2 days design, 3 days dev = 5 days
10 features = 50 days + 5 days system = 55 days

Savings: 45 days (45% faster)

Plus:

Better consistency
Fewer bugs
Easier onboarding
Scalable team

Ready to build your design system?

Book discovery call and we'll discuss your needs.

‍

Insights