Design Systems: Building Foundations for Scale
Over the past several years, I've built design systems at three very different companies—Andesite, Rebellion Defense, and Logixboard. Each had its own challenges, timelines, and constraints, but they all shared a common goal: ship polished UI quickly while preserving accessibility, consistency, and trust as teams and products scale.
Andesite: System Architecture from the Ground Up
At Andesite, I had the opportunity to build a design system from scratch for a fast-moving cybersecurity product. The goal was straightforward: create a system that could scale with both the product and the team without sacrificing quality or speed.
Foundations: Tokens First
I started by defining semantic and system tokens—color, typography, spacing, radii, elevation—so designers and engineers could work from a shared vocabulary and make safe, predictable changes across the app. This token-first approach meant that design decisions cascaded through the entire system, making global changes trivial and preventing UI drift.
Component Library and Documentation
From tokens, I built accessible React components with robust states and variants, designed for real-world edge cases and fast QA. Storybook became the interactive source of truth—MDX usage guidelines, variant matrices, and visual regression readiness all lived there.
The component library emphasized consistency and discoverability. Variant matrices for core components made coverage clear and prevented UI drift.
Logixboard: Scaling from 0 to 1
At Logixboard, I joined as the first designer when the company was around 10 people. The design system needed to grow alongside the product, from early-stage experimentation to a platform that could scale through Series B.
Establishing Foundations
Early on, I did foundational work on the product design, including establishing the look and feel for the UI. I introduced GT Walsheim as the UI font to make the app more distinctive and developed a type ramp that provided structure across the application.
The design system work was pragmatic. We were moving fast with an eye on scaling. I established color palettes for both UI and brand, updated logos, and started setting foundations for a brand platform.
Scaling Process and Culture
As the design team grew from just me to a team of several designers, the design system became a crucial tool for maintaining cohesion. But a system can only do so much; we also needed process. Design crits became regular, and the design system became a shared vocabulary that helped designers give each other feedback and make decisions faster.
Rebellion Defense: UI Overhaul and System Refinement
At Rebellion Defense, I joined as a Principal Product Designer working on Rebellion Nova, a cybersecurity tool. The UI needed a comprehensive overhaul, and the design system work was foundational to that effort.
I overhauled the UI and helped develop assets, but more importantly, I worked to establish a link to the design system that was already a WIP (Boba) that could support the product as it evolved. The challenge here was different; we weren't starting from scratch, but rebuilding while the product was actively being used.
Common Threads and Lessons
Building design systems at three different companies taught me a few key lessons:
Start with Tokens, Not Components
Tokens are the foundation. When you get color, typography, spacing, and elevation right, components follow naturally. This made global changes super-easy and consistent.
Documentation is Part of the System
A design system isn't just code. Storybook, Figma libraries, usage guidelines—all of this documentation is part of the system. It's what makes the system discoverable and usable.
Design and Code Need to Stay in Sync
Figma and Storybook are powerful on their own, but they're transformative when they work together. Visual regression testing with Chromatic catches drift before it becomes a problem.
Systems Need Culture to Scale
A design system can provide structure and consistency, but it can't replace good process and culture. Design crits, shared vocabulary, clear ownership—these are the things that help a system scale with a team, not just a product.
Ship to Learn
The best design systems are proven in product. I've contributed code and found it essential to be able to run the codebase locally so you can iterate quickly and make sure the design system is working as expected.
Looking Forward
Design systems are never done. They evolve with products and teams, and the best ones are living systems that adapt to new needs while maintaining consistency and quality. The common thread: systems don't just make products look better; they help teams move faster, make better decisions, and ship with confidence.