Forma

TL;DR

When I joined ReflexAI as their founding product designer, the company had built an innovative AI training product that was ready to scale. Like many early-stage startups moving fast to validate their market, they needed more systematic design to accelerate past the initial MVP stage. Over my first year, I founded a Figma component library, demonstrated value through improved consistency and usability, and was instrumental in bringing together designers and engineers into a dedicated design systems practice. The result wasn't just a collection of components—it was a culture of systematic, beautiful, accessible UI that became a competitive advantage as we rapidly evolved the product and grew the team.

When I joined ReflexAI in April 2024, the product was exactly where a promising early-stage startup should be: built rapidly to validate the market opportunity, with strong core functionality and early customer traction. The UI worked, but it used a generic off-the-shelf component library that wasn't designed for our specific use cases.

This isn't a unique situation—it's the inevitable challenge of moving from MVP to mature product. Early startups prioritize speed and validation over polish, and that's the right choice. But once you've found product-market fit, you need to level up. The question becomes: how do you accelerate from there without accumulating design debt?

The challenge was compounded by the nature of our product. Prepare is used to train crisis counselors, healthcare coordinators, and customer service agents handling high-stakes, emotionally sensitive conversations. The UI needed to feel sophisticated, trustworthy, and thoughtfully designed—not generic or haphazard.

We also had ambitious plans: adding voice simulations, building self-serve creation tools, enabling AI-generated content. To execute on that roadmap while maintaining quality and consistency, we needed systematic design. But we couldn't stop shipping features to build infrastructure. Everything needed to work in parallel.

I've worked in both large public companies with mature design systems and small startups building from scratch. I knew that the right approach to design systems could be a competitive advantage. It could enable us to move faster, maintain higher quality, and scale the team more effectively than competitors who were accumulating design debt.

The opportunity wasn't just to build a component library. It was to establish a practice and culture around systematic design that would pay dividends across everything we built. Done right, a design system would:

• Accelerate feature development by providing reliable, reusable patterns
• Improve consistency across increasingly complex product features
• Enable team scaling by making it easier to onboard new designers
• Strengthen cross-functional collaboration by creating shared language and tools between design and engineering
• Elevate product quality in a way that would be immediately visible to customers

But it required more than just designing components. It required demonstrating value, earning buy-in, and building collaborative processes that could sustain the system over time.

I took a “show, don't tell” approach to building support for a design system. Rather than starting with presentations about why we needed one, I started by doing the work and letting the results speak for themselves.

Starting with High-Leverage Components

I began by identifying the most frequently used, most visible components in our UI—buttons, form inputs, badges, icons, tooltips—and designing improved versions in Figma. The new components are an aesthetic update, but they also addressed real issues with usability. They were easier to design with, they improved accessibility, and through them I established visual patterns that felt more sophisticated and appropriate for our use cases.

As I designed new features, I built components that would serve those features while also fitting into a larger system. Each component was documented with clear usage guidelines, visual specifications, and interaction behaviors. Other designers on the team began adopting these components eagerly because they made their work easier and the results better.

Establishing Design Tokens

A critical early decision was to build the system on a foundation of design tokens—systematic variables for color, spacing, and typography that could be shared between Figma and our UI codebase. This wasn't just about consistency; it was about creating true design-development parity where changes to core values could propagate across both environments.

I developed comprehensive color palettes using my Paletteer Figma plugin, which generates accessible, flexible color systems from seed colors. These palettes, along with spacing scales and typography systems, became the atomic foundation that all components were built upon.

The benefits were immediate: designers and engineers spoke the same language about color and spacing, updates to tokens automatically reflected across all components, and maintaining consistency became dramatically easier as the product grew in complexity.

Building Engineering Momentum

In parallel, I conducted outreach to the engineering team. Many engineers already knew the pain of working with a disorganized UI and were eager for a mature set of UI components with established guidelines. As engineers began implementing the new components, the improvements showed up in the shipped product—better consistency, clearer interaction patterns, more polished aesthetics.

As the system matured and the team grew, we collaboratively named it Forma (Spanish for “shape”). The name reflected both how it would give shape and structure to our UI, and served as a nod to the significant contingent of Spanish-speaking Latin American members of our engineering team.

The value became obvious at first glance. We weren't just talking about the benefits of a design system; we were demonstrating them. This organic momentum made it much easier to advocate for dedicated resources and roadmap time.

About a year in, with demonstrated value from the Figma library and growing adoption by designers and engineers, I was able to help take the next critical step: transforming a component library into a true design system practice.

Building the Cross-Functional Team

I was instrumental in pushing for the next critical step: transforming our informal collaboration into a structured design systems practice. I helped assemble a dedicated cross-functional team bringing together designers, a senior frontend engineer who would lead our documentation efforts, and a product manager focused on platform and scaling projects. Together, we established regular collaboration rhythms for planning, building, and launching design system updates.

This cross-functional structure was critical. It ensured the design system wasn't owned by design or engineering—it was owned by the team, with shared investment in its success.

The Documentation Site

From early in the process, I advocated for a well-documented UI design system maintained by engineers. My colleague, a senior frontend engineer who was leading the design system effort on the engineering side, stepped up to build a comprehensive documentation site in our development environment.

The documentation site is a living, interactive reference that shows all completed and in-progress components, properties and styling options with real-time demos, usage guidelines and accessibility considerations, and code snippets and implementation examples. The documentation site transformed how we worked—design-to- engineering handoff took less time, new team members got up to speed quickly, and engineers could implement designs with confidence.

Smart Migration Strategies

We also built intelligent migration strategies into the codebase itself. Old, outdated components were marked as deprecated, creating gentle pressure to migrate to Forma components organically as we touched different parts of the UI during feature work. This approach allowed us to improve the system continuously without requiring disruptive, all-at-once migrations that would halt feature development.

Within my first year our design system saw some major milestones:

• Designed, developed, documented, and deployed over two dozen components
• Created a comprehensive system of design tokens (color, spacing, typography) shared between Figma and code
• Team grew from 1 to 3 designers with smooth onboarding enabled by systematic documentation
• Design system rated as a major win for the entire team among all work completed that year

Perhaps the most important outcome wasn't the components themselves—it was the culture we built around systematic design. New designers joining the team could be productive quickly because consistent patterns and documentation existed. Engineers knew where to find components, how to use them, and when to ask for design input. Cross-functional collaboration deepened as we built shared language and processes.

Forma became more than a tool; it became a practice and a mindset that continues to evolve as the company grows.