When I joined CloudSpot, common patterns like dialogs, buttons, inputs, typography, spacing, and icons varied across the product. Different features often solved the same interface problems in different ways.

That inconsistency created more than visual drift. As I worked with engineering, I saw developers repeatedly rebuilding similar components from project to project because there was no shared design-and-code foundation to reuse.

I proposed making the design system a focused priority, starting with the patterns that were used most often, took the most effort to recreate, or caused the most ambiguity during handoff. The goal was simple: stop solving the same UI problems over and over.

Rather than rebuild the entire system at once, I audited how common patterns were being used across CloudSpot, looking for repeated solutions, meaningful variations, accessibility gaps, and places where inconsistency created unnecessary work.

I worked primarily with a Senior Fullstack Engineer in a recurring design-system review, usually tackling one area at a time. I would audit the existing product, define the component structure and states in Figma, then review it with engineering before it was implemented in Storybook and code. Real implementation needs often changed the design, from adding a second text-field label pattern to aligning icon and typography naming more closely with code.

That created an iterative workflow:

The team’s process increasingly treated Figma and Storybook as two sides of the same shared component contract, rather than design documentation followed by a separate engineering interpretation.

A design system would only create leverage if it reflected the product CloudSpot already had, mapped clearly to how engineering built it, and defined enough behavior to reduce repeated interpretation. The key decisions were about where to standardize, where to allow flexibility, and how to keep design and code aligned as the system evolved.

I did not want to create a clean component library that only worked in theory. I started by auditing the patterns already in use, then used those real product needs to define what each shared component actually had to support.

Dialogs were the clearest example. Existing implementations varied in structure, sizing, action placement, and responsive behavior, so I reviewed dozens of real examples before consolidating them into a smaller set of reusable patterns. Engineering then implemented the corresponding components in Storybook and code.

That same approach guided the rest of the system: prioritize common cases, support legitimate variation intentionally, and avoid adding complexity for edge cases that did not yet justify becoming part of the shared component.

Why it mattered: The system needed to reflect the product CloudSpot actually had, not an idealized version of it.

A design system only worked if the component logic was consistent on both sides of the handoff. I partnered closely with engineering to make Figma and Storybook reflect the same states, variants, naming, and behaviors instead of treating design and code as separate sources of truth.

That collaboration changed the components themselves. For example, engineering recommended supporting a second text-field pattern where the label persists above the field instead of forcing every input into one treatment. We also adjusted icon and typography naming to better match the existing codebase.

The goal was not perfect one-to-one parity everywhere. It was to reduce interpretation: designers could compose screens from known patterns, and developers could map those patterns directly to reusable production components.

Why it mattered: A shared system only saves time if both design and engineering understand the component the same way.

As the system matured, I realized that polished variants and states were not enough. Developers also needed to know which behaviors were fixed, which were supported variations, and where flexibility was intentional.

I started treating that behavioral logic as part of the component itself. Buttons, text fields, dialogs, and other controls were documented with complete states, supported configurations, and clearer boundaries around what should remain consistent versus what could adapt to the product context.

For high-variant components like buttons and text fields, I used Claude to accelerate production. I defined the base component, states, variable logic, and supported options, then used Claude’s Figma capabilities to generate the full component structure and combinations. That let me spend less time assembling repetitive variants and more time reviewing edge cases, QAing the system, and aligning behavior with engineering.

Why it mattered: A reusable component is only useful when the team knows how it is meant to behave, not just what it looks like.

Rather than trying to standardize every component at once, I concentrated on the foundations and controls that showed up most frequently across CloudSpot and created the most repeated work for design and engineering.

120+ icons implemented in Storybook, with standardized sizing, color, and stroke-weight options.

The goal was not completeness for its own sake. It was to establish a reliable set of shared patterns that could cover the majority of everyday product work and expand as real needs surfaced.