Building a design system that helped product team ship faster

Propulsion is fully built to accessibility standards, with support for both light and dark themes.

It has a documentation site, so every component comes with clear guidelines covering definition, anatomy, usage, behavior, and accessibility.

It includes everything from simple components to organisms and templates.

Before any guidelines existed, forms across the platform were built on instinct. Button positions varied from page to page, field lengths were arbitrary, and there was no shared logic for when a form should live in a modal versus a drawer versus its own page. Each team solved it their own way, and nothing matched.

During research, I discovered more form types than we'd realistically ever use, which made the next decision just as important as the research itself: what to leave out.

I mapped usage patterns across the platform and landed on four types that covered everything Propulsion actually needed: Standard, Modal, Drawer, and Wizard. From there I defined clear guidelines for each one, covering layout, field length, grouping, spacing, and button placement.

The goal was consistency, so that two different teams building two different forms would arrive at the same structural decisions without having to ask each other.

The feedback was good, designers and developers found it straightforward, and what is more important, the consistency started showing up across the platform.

When I joined the team, the design system had no data visualization layer — yet data was everywhere on the platform, and every team had their own charts. That needed to change immediately.

To figure out where to start, I did a research, audited data across products, and spoke with teams about how they needed to present it, what comparisons they were making, what trends they needed to cover.

From the research I mapped out which chart types were genuinely needed and designed a library of ten from scratch. Each one was built to feel native to the design system, consistent in visual language and behavior, and thoughtful about edge cases like empty states, long labels, and dense data.

To understand where teams were losing time, I ran interviews across product teams to map how they approached page design. A clear pattern emerged: teams were borrowing layouts from other teams and adapting them to fit. It created inconsistency and slowed everyone down.

The solution was a library of page templates built directly into the system. I built each one from existing Propulsion components, fully responsive and consistent by default, so teams could adapt them without breaking anything.

The templates were adopted across five or more teams and became the standard starting point for new page design across the platform.

Color was another deep dive. I researched how leading systems handle color and accessibility, then restructured the palette into clear categories — hues, specialty colors, categorical colors, and gradients — all documented for both light and dark mode. Everything was built to accessibility standards from the ground up.

One of the bigger additions was a new categorical color palette, now widely used across charts and data visualizations throughout the platform.

I was an active member of the UX Writing team, and much of my writing went into Propulsion's guidelines. Every component page followed the same structure: Definition, Anatomy, Usage, Behavior, and Accessibility. Before writing, I studied how popular design systems document the same components, picked out the best practices, and turned them into clear, consistent copy for ours.

The same care applies to the words inside the components. An error message is a good example: a vague one leaves people stuck, while a good one says what went wrong and how to fix it, in plain words, without blaming anyone. The component stays exactly the same; only the words change, and that alone decides whether someone can fix the problem on their own.

I mentored a junior designer on the team. We held regular reviews, and I helped her learn how the system was structured and how to design components that fit it. By the end she was building and documenting components on her own.

Developers were part of the work from the start. Before I designed anything new, we held a kick-off to agree whether a new component was really needed or an existing one could cover the case. Daily syncs kept design and development moving together, so questions were answered early instead of at build time.

Working on Propulsion taught me what it really means to design for other designers. Design system work demands a different kind of attention — every component, guideline, and token is a decision that gets inherited by someone else, in a context you can't always predict. The more precise the foundation, the less friction everywhere else. That's what I found most rewarding about this work: seeing how far something small can travel when you do it right.