arrow_back All Work

Transforming a Design System

From a component library into a productivity platform.

Senior Product Designer · 4 Months · Solo — design and system ownership, no engineering support

1.9m+
Users
107
Components
60+
Products using the system

Problem

A complete Figma library existed, but progress had stalled. Components were flexible enough to build almost anything — which meant designers remade the same styling decisions every day, and handoff kept breaking on the details.

Solution

Rebuilt the library as a prescriptive platform: production-ready, fully assembled components with strong defaults, and design guidance embedded in the Figma workspace itself rather than a separate wiki.

Impact

Component assembly time fell from 20 minutes to under 5. Component detachment dropped to zero on rebuilt patterns, and completion rates on the flows powered by the new stepper improved 15% across three product lines.

Overview

The library had every basic piece — buttons, inputs, dropdowns — and none of the things designers actually built with day to day. No standard data table. No standard page header. So everyone rebuilt them, slightly differently, every time.

The decisions it left open were small ones: grey or white background on this modal, which spacing value for that card. Small, but you make them forty times a week, and the inconsistencies land downstream as engineering rework.

This is what I changed, and what happened after.

My Role

Solo. I ran the audit, made the case to engineering leadership, and designed the architecture for the two hardest patterns — data tables and advanced navigation. There was no dedicated engineering headcount on the design side, so the system's ongoing upkeep was mine as well.

What I was after: move the system from "here are the pieces" to "here's the answer", so designers spent their judgment on the problems that actually needed it.

The Problem

The library was called complete, and by one measure it was. Building blocks at the bottom, full-page templates at the top. What it didn't have was the middle — the data table, the form, the page header people actually reached for. Those got assembled from scratch, every time, by everyone.

Across a team that adds up to two things nobody wants: screens that don't quite match, and a handoff that keeps stalling on detail.

Research & Discovery

I interviewed 12 product designers across India and the US, then set them a task: build a standard five-column data table with sorting, filtering and bulk actions, using only what was already in the library. Same brief, same library, twelve people — I wanted to watch the variance rather than ask about it.

What I found

  • Average completion time was 20 minutes, with wide variance in spacing and interaction patterns between designers solving the same problem.
  • Figma API scripts showed how frequently components were detached from the system to force a specific layout.
  • An audit of handoff tickets quantified the back-and-forth between design and engineering on spacing and state definitions.

Key Insights

01

Decision Fatigue

Flexibility that should have been resolved by defaults was landing on designers instead, every single time.

02

The "Missing Middle"

Strong basic building blocks, strong templates, nothing assembled in between.

03

Handoff Degradation

Detached components meant custom CSS, which meant slower builds and more QA cycles.

04

Documentation Deficit

Guidelines existed, but lived in Confluence, outside the tool where the decisions were actually being made.

Prioritization Framework

I couldn't stop product work while I rebuilt everything, so I had to pick an order. Three questions per pattern: how many people hit it, how often, and what it costs to fix.

Opportunity User Impact Frequency Effort Priority
Data Tables High Daily High P0
Progress Steppers Medium Weekly Low P1
Modals High Daily Medium P1

Deep Dive 01

Reimagining Data Tables

The Problem: Data tables were the most-used pattern in the product and the most manual to build. Designers assembled rows, cells, and headers by hand, which produced 45+ custom variations across the product and meant engineers wrote near-custom CSS for almost every table.

The Approach: I built a single responsive component that automatically resizes and rearranges itself, with built-in toggles for pagination, bulk actions, and density. Complex to build once; trivial to reuse afterwards.

Diagram contrasting the old manual, misaligned table structure with the new architected table component, showing its layout anatomy, a working table example, and its configurable properties

Result: Detachments dropped to 0%, table customisation time fell 75%, and the sample-task time dropped from 20 minutes to under 5 — with substantially fewer clarification rounds in handoff.

Table Variant Research: Before (Text Only) vs After (ASCII + Icons)

Deep Dive 02

Simplifying Progress Steppers

The Problem: Multi-step flows ran on four separate bespoke stepper implementations, each maintained independently and each behaving slightly differently for users working through long forms.

The Approach: I consolidated all four into one component handling linear and non-linear flows, error states, and responsive collapsing, with the logic for moving between states built into the component itself instead of rebuilt every time it was needed.

Diagram contrasting several inconsistent stepper implementations with the single unified stepper component and its configurable properties

Result: Custom stepper code dropped 40%, and completion rates on the onboarding and checkout flows it powers — across three product lines — improved 15%.

Driving Adoption

Building the components was half the work. Getting designers to reach for them was the other half.

The turning point was tightening engineering handoff. Once using a system component meant it shipped exactly as designed, with no QA back-and-forth, designers started reaching for it by default. The system stopped feeling like a rule and started feeling like a shortcut.

The team pushed back at first. The company is conservative about process change, and "we're rebuilding the library" sounds like disruption to everyone who has a deadline. So I stopped talking about the system and started talking about their week — what this would take off their plate, specifically. That's what shifted it.

Outcomes & What I Learned

Time-to-prototype dropped and the screens started matching. But the change I'd point to is what design reviews turned into: less "what's the border radius here", more "does this flow actually solve the problem". The system stopped absorbing the conversation.

Designers are users too.

Internal tooling deserves the same research rigour as anything shipped externally. The workflow you're designing for is your own team's.

Next Case Study
Enterprise UX Developer Tools Information Architecture

Designing Horizon Bank Developer Central

Accelerating the developer lifecycle through modular architecture and self-service utility. From 14-touchpoint onboarding to a unified self-serve experience.

Senior Product Designer · 4 Months
arrow_forward