Design Systems Enterprise B2B Climate Tech NDA Protected

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.

Role
Sole Product Designer
Company
Enterprise Climate-Tech
Timeline
6 months (ongoing)
Impact
3 squads, 60+ components
🔒

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.

60+
Components built
3
Product squads unified
40%
Faster design-to-dev
14→4
Button styles unified

The Problem

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.

3

Siloed squads

When I joined, each squad was building UI independently with zero shared patterns between them.

30%

Wasted engineering time

Engineers were recreating UI that already existed elsewhere. I identified this through an audit in my first two weeks.

14→4

Button variants consolidated

I found 14 different button styles across the product. I consolidated them into 4 purposeful variants with clear usage rules.

60+

Components I built

From zero shared components to a 60+ component Figma library with tokens, documentation, and usage guidelines.


Interface Audit

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.


Design Principles

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.

01

Clarity over cleverness

Enterprise users handle complex regulatory data. Every component must communicate its purpose instantly. No ambiguity, no decoration for its own sake.

02

Consistency is trust

When buttons behave the same everywhere, users build muscle memory. Muscle memory builds confidence. Confidence builds trust in the platform.

03

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.

04

Composable, not prescriptive

Components should combine freely to serve use cases we haven't imagined yet. Atomic building blocks over rigid templates.

05

Document everything

A component that isn't documented doesn't exist. Usage guidelines, do/don't examples, and interaction specs ship with every component.


Design Tokens

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
Gray 900
--gray-900: #0A0A0A
Gray 600
--gray-600: #555555
Gray 400
--gray-400: #999999
Gray 200
--gray-200: #EBEBEB
Gray 100
--gray-100: #F5F5F5
Green 600
--green-600: #16A34A
Red 600
--red-600: #DC2626
Spacing scale
4px
8px
12px
16px
24px
32px
48px
Typography scale
Heading XL
24px / 700 / -0.03em
Heading L
18px / 600 / -0.02em
Heading M
14px / 600
Body
14px / 400 / 1.55 lh
Caption
12px / 400 / 1.4 lh
OVERLINE
10px / 600 / uppercase

Component Architecture

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.

Primary Secondary Ghost Small
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.

Approved Pending Rejected Draft
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.

Document name.pdf2.4 MB
Validation report.xlsx890 KB
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.


The System in Production

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.


Rollout Process

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.

Weeks 1-2
Audit and alignment
Interface audit, stakeholder presentations, principle definition workshop. Got executive buy-in and dedicated time allocation.
Weeks 3-4
Token foundation
Color, typography, spacing, and elevation tokens. Published as Figma styles and CSS variables simultaneously. Engineers could start using tokens before components shipped.
Weeks 5-8
Core components (v1)
Buttons, inputs, selects, badges, cards, tables, modals, tooltips. Each with full state coverage, responsive variants, and usage documentation. Reviewed with all 3 squads.
Weeks 9-12
Pattern library
Form groups, navigation, page layouts, workflow templates, data display patterns. Composed from core components. Tested against real product use cases.
Weeks 13-16
Migration and adoption
Worked with each squad to migrate existing screens. Held weekly office hours for questions. Created migration guides for common patterns. Tracked adoption metrics.
Ongoing
Governance and evolution
Bi-weekly design system review sessions. Contribution guidelines for engineers. Versioning and changelog. New component requests go through a lightweight RFC process.

Results

Measurable impact

Faster

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.

Shared

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.

60+

Components shipped

Covering the full product surface: navigation, forms, data display, feedback, overlays, and workflow-specific patterns.

AA

Audited to WCAG 2.1 AA

Components are built and reviewed against AA standards: contrast ratios, keyboard navigation, focus indicators, and screen reader support.


Reflections

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.

← Back to portfolio