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 designed
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.
The wall of inconsistency, redrawn
Fourteen button styles found in the audit, reconstructed from my inventory with the client's colour and brand removed. Every difference shown here is one an engineer had to guess at: radius, weight, casing, height, border, and four unrelated notions of what "primary" meant.
14 styles. Six radii, five type sizes, three casings, four colours competing for the same meaning.
What replaced them
Four variants with written rules for when each applies, each shipping the full state set. Consolidation was not a visual preference: it removed the question an engineer had to answer on every screen.
PrimaryOne per view. The action the screen exists for.
SecondarySupporting actions that do not commit anything.
GhostTertiary and in-table actions where weight would crowd the data.
DestructiveIrreversible only, never adjacent to primary.
Every variant, every state
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
Submission forms in this product run to fourteen steps. When a control behaves the same on step twelve as it did on step two, people stop reading it and start using it. Inconsistency costs attention exactly where the data gets hard.
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
Undocumented components got rebuilt by whoever could not find them. Usage guidelines, do and don't examples, and interaction specs ship with every component so the second squad to need one does not redraw it.
Separating primitive values from meaning
The architecture separates primitive values from semantic tokens. Primitives are raw colours and pixel sizes; semantic tokens name what a value means in context. Engineers consume the semantic layer only, so the visual language can change without touching product code, and a designer and an engineer arguing about a state are arguing about the same named thing.
Primitive
Semantic
Why the split
Squads referenced raw hexes, so a brand change meant hunting values across three codebases. Naming by meaning made the palette swappable and gave reviewers a vocabulary for arguing about intent rather than about colour.
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
Due to confidentiality, some interface details are simplified or omitted. I can discuss the process, decisions and collaboration model in more detail in an interview.
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
Versioned and supported, or ignored
It has users, and they are designers and engineers with deadlines. Once it had a roadmap, versioned releases, and somewhere to ask questions, adoption stopped depending on whether I was in the room.
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.
Office hours moved more than the Figma file
Weekly office hours, migration guides, and a standing slot in each squad ritual moved adoption further than any improvement to the library itself. The blocker was never component 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.