Stakeholder interviews
Spoke with 3 engineers, 2 PMs, and the VP of Product to understand pain points — inconsistent handoff specs and duplicated work were the top themes.
Cross-Platform Enterprise
Design System
Unifying the design language across web, mobile, and desktop for a B2B SaaS product suite
Overview
A B2B SaaS company in the productivity/hardware space had its product suite grow organically across multiple platforms — mobile, desktop, and web — without a shared design language. With 50+ enterprise clients depending on a consistent experience, the inconsistencies were becoming a business problem, not just a design one. Inconsistent UI patterns, duplicated components, and ad-hoc styling were slowing down development and fragmenting the user experience. I was brought in as the sole designer to audit the existing interfaces, define a unified token system, build a scalable component library, and establish documentation practices for cross-functional collaboration.
The Challenge
No single source of truth
Each platform had its own visual language. Buttons looked different across mobile and web, spacing was inconsistent, and there was no single source of truth for design decisions. Engineering was spending extra cycles reconciling design specs, and onboarding new team members meant re-explaining patterns that should have been documented.
Before
Inconsistent components
After
Unified system
Process · Step 1
Audit & discovery
I started with a comprehensive UI audit across all platforms, cataloging every component variant, color value, and typographic style. This revealed 47 unique button styles, 12 different greys, and no shared spacing scale.
Research approach
UI audit
Screenshotted and cataloged every unique component across all 3 platforms. Built a spreadsheet mapping variants to frequency of use.
Developer survey
Ran a short async survey with the engineering team to identify which inconsistencies caused the most rework — buttons, spacing, and color were the top 3.
47
Button variants
12
Different greys
0
Shared tokens
Process · Step 1.5
Design decisions
Why this approach
Flat tokens or layered architecture?
I chose the layered approach. It was more upfront work, but it meant we could support theming and platform-specific overrides without breaking consistency. When the team later needed a dark mode prototype, the semantic layer made it possible in days instead of weeks.
Build everything at once or ship incrementally?
Incremental. Engineers were shipping features daily — a full freeze wasn't realistic. I started with buttons, inputs, and cards (80% of the UI surface), which gave immediate visual consistency without blocking any sprint.
Figma-only documentation or code-connected?
Both. Figma was the design source of truth, but I worked with the frontend lead to set up Storybook with the same token names. This eliminated the 'Figma says one thing, code says another' problem that was causing rework.
Process · Step 2
Token architecture
I defined a semantic token system: primitive values (colors, sizes) feeding into semantic tokens (text-primary, surface-elevated, spacing-md) that could flex across themes and platforms.
Color tokens
Primary & neutral scalessurface-primary
#0F0D14
text-primary
#EDE9F2
border-default
rgba(255,255,255,0.10)
interactive-hover
#7C5CFC
Typography
Live scaleDisplay 1
The quick brown fox
Heading 1
The quick brown fox
Heading 2
The quick brown fox
Body
The quick brown fox
Caption
The quick brown fox
Spacing
Scale as a rulerFoundations
Grid & breakpoints
A responsive grid with predictable columns and gutters kept layouts consistent across web and desktop, while scaling down cleanly for tablet and mobile.
Desktop12 columns
Tablet8 columns
Mobile4 columns
Foundations
Color system
Colors are presented as primitives (scales) and semantic tokens (usage). Semantic names kept design and engineering aligned as themes evolved.
Color palette
PrimitivesPrimaryLavender scale
GreyNeutral scale
Semantic colors
Status groupsColor tokens
Usage cardsFoundations
Typography
A strict scale with clear roles (display → caption) kept enterprise interfaces readable at dense data densities.
Type scale
Specs + sampleInstrument Sans.
| Style | Specs | Sample |
|---|---|---|
| H1 | 32/40 · 800 · -0.02em | The quick brown fox |
| H2 | 24/32 · 700 · -0.01em | The quick brown fox |
| H3 | 18/26 · 700 · -0.01em | The quick brown fox |
| Body | 14/22 · 500 · 0 | The quick brown fox jumps over the lazy dog. |
| Caption | 12/16 · 600 · 0.12em | The quick brown fox |
VariablesTypography
type.h1.size
32
type.h1.line
40
type.body.size
14
type.body.line
22
type.caption.track
0.12em
Foundations
Spacing system
Spacing tokens encode rhythm. Each token includes a readable name plus px value, with examples showing real UI application.
Spacing tokens
Name + pxspacing-4
4px
spacing-8
8px
spacing-12
12px
spacing-16
16px
spacing-24
24px
spacing-32
32px
spacing-48
48px
spacing-64
64px
Member list
Applied spacingA. Martinez
Owner · Admin
K. Nordin
Editor · Billing
S. Chen
Viewer · Reports
Foundations
Corner radius
A small set of radius tokens kept surfaces consistent and recognizable across the product.
Radius scale
Tokensradius-sm · 6px
radius-md · 10px
radius-lg · 14px
radius-pill
Foundations
Elevation & effects
Three elevation levels cover most UI needs—from flat surfaces to floating panels—without inventing new shadows per component.
Elevation
1 · 2 · 3elevation-1
elevation-2
elevation-3
Foundations
Icon set
A consistent 24px icon grid with unified stroke weights kept UI controls crisp across densities.
Icons
SVG setProcess · Step 3
Component library
Built a Figma component library from atomic elements up: icons → buttons → form elements → cards → complex patterns like dashboards and data tables. Every component included states, variants, and usage guidelines.
Buttons
Primary · Secondary · GhostPrimary
Secondary
Ghost
Default
Hover
Disabled
Input fields
Default · Focused · Error · Disabledhelper text
focus ring: primary-500
Token name must be unique
read-only
Cards & badges
Variants connected by tokens
Info
Success
Warning
Error
Neutral
Process · Step 4
Documentation & handoff
Created living documentation in Figma with annotation standards, redline specs, and naming conventions aligned with the engineering codebase. Ran onboarding sessions with developers to ensure adoption.
| Property | Value |
|---|---|
| Background | primary-500 |
| Text color | white |
| Font | 14px/20px, Semi-Bold |
| Padding | 12px 24px |
| Border radius | 8px |
| States | default, hover, active, disabled |
Results
Impact across teams & platforms
~40%
Faster design-to-dev handoff
Measured by comparing average ticket cycle time before and after design system adoption over 3 months
~30%
Less design time through reuse
Tracked by comparing time spent on new feature screens using the component library vs. designing from scratch
3
Platforms unified
Web, mobile, and desktop apps now share one token set and component library in Figma
1
Shared source of truth
Single Figma library with 120+ components, adopted by all 3 engineering teams
Key Learnings
What I took forward
A design system is a product, not a project. It needs continuous maintenance, stakeholder buy-in, and clear governance to stay alive.
Starting with tokens before components was crucial — it forced alignment on fundamentals before building anything visual.