Building a Design System for Speed and Consistency
As the sole designer at an early-stage startup, I couldn't afford to rebuild components from scratch every sprint. I created Stillsuit: a practical design system built for speed.
The system reduced engineer onboarding time by 50%, enabled a complete rebrand in 2 weeks instead of 6, and established the foundation for design quality as Dune scales.
Why build a design system when you're the only designer?
I'm cautious about design systems. They're often created too early, easily overcomplicated, and become maintenance burdens that slow teams down instead of speeding them up.
At Dune, I didn't think we needed one at first. But I was thinking ahead.
We were about to scale
Every component I built without a system was technical debt for the future team.
The rebrand was coming
Moving from dark to light mode across an entire product is painful without centralized styles.
Engineering velocity was at stake
Without a shared language for components, every ticket required extra explanation.
Design quality needed to compound
I wanted every new feature to be better than the last. A system meant learnings accumulated.
Making the case with math
I made the case to leadership that investing 3-4 weeks in a design system would pay back 10x over the next year.
We were planning to ship 12+ major features. If each saved 3-4 days of design/eng overhead, the system paid for itself by feature #3.
Four principles that guided every decision
Speed over completeness
The system needed to accelerate work this week, not in six months. Build components as needed, not speculatively.
Engineer-first documentation
The primary consumer was engineering. Documentation had to answer their questions without requiring a meeting with me.
Flexible but opinionated
Sensible defaults for 90% of use cases, with clear escape hatches for the other 10%.
One source of truth
Tokens in Figma had to match code exactly. Drift between design and implementation defeats the purpose.
Token architecture
I started with design tokens, the foundational layer that everything else builds on. Getting this right meant the rebrand could happen by changing values in one place.
Raw values
gray-100, space-4
Contextual meaning
color-bg-primary
Specific usage
button-padding-x
When we flipped from dark to light mode, I changed the semantic token mappings. Every component updated automatically.
Color earns its place
The old product used color decoratively. Dark backgrounds, gradient accents, colorful cards. It looked "sophisticated" but made the interface noisy and risk states hard to spot.
In the new system, saturated colors are reserved for risk and status. This means when something is red, it actually means something.
Risk & Status
The only place we use saturated color liberally. High signal, no noise.
Everything Else
Neutrals that let meaningful color pop. The restraint makes the signal clear.
The risk indicator
The most important component in the system. It appears everywhere: dashboard summaries, user rows, inline mentions. It needed to work at multiple sizes while remaining instantly scannable.
Large
Dashboard hero
Medium
User row
Small
Inline mention
Documentation that engineers actually use
Documentation that lives in a separate wiki gets stale. Documentation that's too sparse doesn't help. I needed something that engineers would actually use.
My solution: documentation lives directly in Figma, attached to components. When an engineer inspects a component, the usage guidelines are right there.
Engineers stopped asking "what's the padding here?" The answer was always "check the component."
The numbers
Faster engineer onboarding
Rebrand execution (vs. 6 estimated)
Faster average feature shipping
Visual bugs and "doesn't match" tickets
What I learned
Infrastructure is a leadership decision
Building a design system when you're the only designer feels indulgent. But I was thinking about what the team would need in 12 months, not just what I needed that week.
The system is a product
It has users (engineers, future designers). It needs UX. It needs maintenance. Treating it as a product, with strategy, roadmap, and success metrics, is what made it successful.
Document for the person who isn't here yet
Every piece of documentation was written for the engineer or designer who would join in 6 months and need to understand "why is it this way?"
Make the case with math
Leadership approved the investment because I showed the ROI. Speaking in business outcomes, not just design quality, is how you get buy-in.
Next Project
University Park →