Making Petavue's Design System Easier to Use

The System Already Existed

Petavue already had a design system when I joined. It had grown alongside the product and become harder to use: components spread across different Figma files, duplicate or similar components, inconsistent naming, different versions of similar patterns, missing states. Before designing a new screen, we were often solving the same UI decisions again.

I Consolidated the Foundation

I pulled commonly used components into a single working library and cleaned up patterns that had accumulated over time — one place to find the component, one place to maintain it, and fewer reasons to recreate it.

Components Became More Complete

A component wasn't complete if we still had to figure out what happened when something went wrong, so I designed common states into the component itself so they could be reused instead of recreated inside every screen.

Pick one real, state-rich component — a table row, an input, a button — and only show the states that actually exist; swap out any tile above that doesn't apply.

The System Had to Work With the Product

Once the foundation was cleaned up, it became the starting point for new product work. New screens could be assembled from existing patterns instead of rebuilding UI from scratch.

Consistency Still Needed Room for the Product

Reuse didn't mean forcing every use case into the same component. When a pattern needed to evolve, I treated the new behavior as part of the system instead of creating another isolated version.

The System Changed How I Designed

Once the common UI decisions were already made, I could spend more time on the product problem. New work started with composition instead of reconstruction.

Demos Needed to Move Fast, Without Inventing New UI Each Time

Stakeholders would often bring a short brief and a direction for a demo, sometimes with only a few days' notice. Those screens didn't always match what existed in the product yet, but I built them on top of the current UI to stay consistent, and the component library meant most of the time went into the actual UX, not into rebuilding buttons, tables, and inputs from scratch.

Handoff Was Practical, Not Just a Figma Link

Once a flow was ready, I posted it where the whole engineering team could see it, not only the people directly building it: a status (Ready for UI review, Ready for Dev), the Figma file and prototype links, a short screen recording of the flow, and the specific stakeholders tagged so they'd respond quickly. Anyone picking up the work later had the same context without asking around.

Then I Started Building With It

I started using Claude Code to build interactive React prototypes from the same design foundation. Because the visual rules and components were already defined, I wasn't starting from a blank codebase.

From Component to Working Interface

Instead of stopping at a polished Figma screen, I could build the interaction and evaluate it in a real interface. This changed what I could prototype and how quickly I could get an idea in front of the team.

This is the section most worth a real screen recording or GIF, since it's specifically about interaction, not a static state. If not yet available, the 4-step static progression above — isolated component → fuller layout → full built screen → browser frame of the working React prototype — works as the placeholder shape.

Figma and Code Started Speaking the Same Language

I used Figma MCP and Claude Code to translate existing designs into React and refine the implementation directly in the browser. The design system gave the code a visual vocabulary to follow. The browser gave me a faster way to test how those decisions behaved in a real interface.

What Changed

Less time rebuilding UI. More time solving the product.

Replace any of these with real numbers where they exist, otherwise leave them out rather than guessing: