Building a design system for a global enterprise platform from zero
How I created a 60+ component design system from scratch for an enterprise climate-tech platform handling regulatory workflows across thousands of global companies. The system unified 3 product squads and became the foundation for all new feature development.
Work under NDA
Due to a non-disclosure agreement, I cannot show the final production UI. This case study focuses on my process, methodology, design decisions, and measurable outcomes. The component previews shown are simplified representations, not actual product screens.
Three squads, three different design languages
When I joined, the enterprise platform had no shared design system. Each of the 3 product squads had developed their own patterns independently. Buttons looked different across modules. Spacing was inconsistent. Form patterns varied. Engineers spent 30% of their time recreating UI that already existed somewhere else in the product.
Siloed squads
When I joined, each squad was building UI independently with zero shared patterns between them.
Wasted engineering time
Engineers were recreating UI that already existed elsewhere. I identified this through an audit in my first two weeks.
Button variants consolidated
I found 14 different button styles across the product. I consolidated them into 4 purposeful variants with clear usage rules.
Components I built
From zero shared components to a 60+ component Figma library with tokens, documentation, and usage guidelines.
Cataloging the chaos
Before building anything, I conducted a comprehensive interface audit. I screenshotted every unique UI pattern across the platform, categorized them, and created a visual inventory. This became the foundation for stakeholder alignment: showing leadership the inconsistency made the case for investment self-evident.
What I found
14 button styles. 8 different input patterns. 5 card layouts. 3 navigation paradigms. 4 color palettes. No accessibility standards. No spacing scale. No type hierarchy.
How I presented it
Created a "Wall of Inconsistency" in FigJam showing every variant side by side. Presented to product, engineering, and leadership. The visual impact made the problem undeniable. Got buy-in for a dedicated design system workstream within one week.
What this system stands for
Before designing a single component, I facilitated a workshop with all 3 squad leads, the PM, and 2 senior engineers to define the principles that would guide every design decision. These became our north star for trade-off discussions.
Clarity over cleverness
Enterprise users handle complex regulatory data. Every component must communicate its purpose instantly. No ambiguity, no decoration for its own sake.
Consistency is trust
When buttons behave the same everywhere, users build muscle memory. Muscle memory builds confidence. Confidence builds trust in the platform.
Accessible by default
WCAG 2.1 AA compliance is not a feature request, it is a baseline. Every component ships with proper contrast ratios, keyboard navigation, and screen reader support.
Composable, not prescriptive
Components should combine freely to serve use cases we haven't imagined yet. Atomic building blocks over rigid templates.
Document everything
A component that isn't documented doesn't exist. Usage guidelines, do/don't examples, and interaction specs ship with every component.
The foundation layer
I established a token architecture that separates primitive values (raw colors, pixel sizes) from semantic tokens (what they mean in context). This lets us theme the system and maintain consistency even as the visual language evolves.
Color primitives
Spacing scale
Typography scale
Atomic building blocks
I structured the library using atomic design principles: tokens feed into primitives (buttons, inputs), primitives compose into patterns (form groups, card layouts), and patterns assemble into templates (page layouts, workflow steps). Every component includes states, variants, and responsive behavior.
Buttons (4 variants, 3 sizes, 5 states)
Primary, secondary, ghost, and destructive. Each supports default, hover, active, disabled, and loading states. Consolidated from 14 inconsistent button styles.
Inputs (6 types, validation states)
Text, email, number, select, textarea, and search. Inline validation with error, warning, and success states. Consistent label, helper text, and error message positioning.
Status badges (8 semantic states)
Consistent status communication across all workflow states. Color-coded with accessible contrast ratios. Used across document review, target validation, and submission tracking.
Data table rows and list items
Flexible row components for document lists, data tables, and workflow queues. Supports selection, expansion, inline actions, and drag reordering.
How it all comes together
The design system now powers every screen in the platform. Here is where the components live in context. Due to NDA, I cannot show the actual product UI, but I can share the structural patterns.
Production screens under NDA
The final product UI is confidential. Contact me directly for a walkthrough.
Document review workflow
A multi-step guided flow that replaced a 14-step process with 6 clear steps. Uses progress indicators, inline validation, contextual help, and auto-save. Users stopped abandoning the flow midway and could resume without losing work.
AI-assisted search
Search and recommendation features surfacing relevant guidance from large unstructured document sets. Designed trust, audit, and override patterns for AI outputs.
Target submission dashboard
Enterprise dashboard for tracking climate target submissions across multiple entities. Status tracking, document management, and multi-stakeholder review.
Data entry forms
Complex forms handling hundreds of data points with conditional logic, cross-field validation, and progressive disclosure to manage cognitive load.
How I shipped it across 3 squads
Building the system was only half the challenge. Adoption required buy-in, education, and ongoing support. Here is the phased rollout approach I designed and executed.
Measurable impact
Design-to-dev handoff
Shared component names between Figma and code removed most translation overhead. Engineers reported pulling components by name instead of rebuilding them from screenshots.
One language across squads
Three squads moved from independent patterns to a single component vocabulary, so the same button or form behaves identically wherever it appears.
Components shipped
Covering the full product surface: navigation, forms, data display, feedback, overlays, and workflow-specific patterns.
Audited to WCAG 2.1 AA
Components are built and reviewed against AA standards: contrast ratios, keyboard navigation, focus indicators, and screen reader support.
What I learned
A design system is a product
It has users (designers and engineers), a roadmap, versioning, support channels, and adoption metrics. Treating it as a product, not a side project, is what made it succeed.
Start with tokens, not components
Tokens gave engineers something to use immediately, even before components were ready. This built momentum and trust before the first component shipped.
Adoption is a people problem
The best design system in the world is worthless if nobody uses it. Weekly office hours, migration guides, and embedding in squad rituals mattered more than the Figma file quality.
Enterprise complexity requires composability
Rigid templates break when use cases multiply. Atomic, composable components survived use cases we never anticipated, while template-based approaches would have required constant rework.