2025-26
Design system development
Sole designer for the Slush Platform design system, built from scratch across those ten tools. I owned the full surface: color system, typography, spacing, component architecture, documentation, and developer handoff.
In 2025 I built the foundational system while leading one designer in mirroring the platform foundations to the app side. In 2026 I am responsible for scaling both, as well as leading a designer alongside me.
why was the design system needed
The conventional approach would have been to audit everything first, define tokens, build components, then roll the system out. That sequence assumes the product surface is stable. Slush's wasn't. The tools were being actively redesigned. Waiting for a clean audit would have meant building a system for products that no longer existed by the time it shipped.
Atomic design made this possible. Starting from the smallest primitives and composing upward meant the system could be useful from day one and grow alongside the products rather than requiring a finished library before any product work began.
Step 1: primitives first
Colors, spacing, and typography foundations built before any components. These were small enough to define quickly and immediately usable across every tool being redesigned.
Step 2: products drive components
Instead of speculating which components the system would need, I let the product redesigns surface them. If a pattern appeared across multiple tools, it entered the shared library. If it didn’t, it stayed local.
Step 3:
Step 3: scaling the team
Throughout the first year, I led and guided a designer to extend the design system to our app.
In 2026, I lead and guide a designer to grow both files alongside me.
Setting up colors
Setting up typography
Each new component that makes it to the design system comes from real product redesigns. The general rule of thumb is: if the component is/going to be used across multiple tools it’s brought to a design system. This helps to keep the design system factual, and allows to scale the system in a rapid product cycle.
Read more
What the system deliberately leaves out
What the system intentionally leaves out matters as much as what it includes. Tool-specific components stay local, even when the temptation is to centralize everything. The Meeting Tool’s company card is a tool-specific artifact that is not re-used anywhere, thus it lives only locally.
The gap between design and code is closed. Developers reference the same tokens in production that drive the Figma library, so what a designer specifies is what ships.
Before the design system: 30-40% of the "fix" tickets during testing would be minimal UI changes VS 5% now. The communication layer has shifted from descritptive into a sharper token and component driven approach.
The system is still growing, which means the hardest judgment calls are ongoing: when to abstract, when to leave something local, and when a pattern has proven itself enough to graduate. My first instinct was to systematize more aggressively; I pulled back once I saw that premature components sat unused. The system works because it’s smaller than it could be.
50+
Components with variants built to support product needs.
10
Public-facing platform tools now sharing one design system.
