Building Stage TEN's Design System
From ad-hoc UI to a scalable foundation
My role
UX Lead — Design System, Visual Design, Documentation, Project Management
Team
Me, Product Designer
Sanborn Hillland, SWE
Timeline
3 months
Impact
Established Stage TEN’s first design system, enabling faster shipping, consistent cross-device experiences, and a shared design language across product and marketing
Overview
Stage TEN had no design system. Features shipped with ad-hoc styles, creating inconsistencies and slowing development. The new dashboard made the gaps impossible to ignore: we needed a scalable foundation for consistency, speed, and a shared language.
I scoped a pragmatic v1: auditing the UI, refreshing foundations, and building tokens, core components, and documentation. Partnering with engineers, we aligned on naming and workflows to keep design and code in sync.
The result? Stage TEN’s first design system — a cross-team toolkit that improved collaboration, sped up shipping, and established a unified design language across product and marketing.
Designing for scale without a system.
Stage TEN’s UI was stitched together with ad-hoc patterns. Without a system, every new feature shipped with slightly different styles and naming conventions.
Designers spent time debating spacing, colors, and behaviors instead of focusing on bigger problems.
Engineers coded by guesswork, leading to inconsistencies and rework.
Live sellers and their viewers experienced a product that felt uneven and disjointed.
The cost of “no system” was clear: slower shipping, endless QA cycles, and a fractured product experience. On top of that, the realities of working in a fast-moving startup added to the challenge: tight deadlines, limited resources, and a culture that naturally prioritized shipping visible features over investing in invisible foundations like a design system
Start small, build smart
Step 1: Audit the chaos 🔎
With no system to reference, I audited the live studio (inspect tools, screenshots, and a quick UI inventory) to catalog colors, fonts, spacing, and common components and patterns. This created a shared picture of where inconsistencies lived and gave us a concrete starting point.
Step 2: Refresh the foundation 🎨
The audit made it clear that our product didn’t just need documentation, it needed a reset. Colors were duplicated under different hex codes, type sizes didn’t follow any rhythm, and spacing values multiplied with every new feature.
I refreshed the visual foundations so they could act as a stable base for both the dashboard and viewer UI:
Color palette. Consolidated one-off hex values, aligned with brand identity, and improved contrast for accessibility.
Typography scale. Introduced a consistent ramp (headline, title, body, caption) to replace ad-hoc sizing, ensuring readability across devices.
Spacing system. Defined a simple scale (4/8/16…) to replace random pixel values, making layouts more predictable and responsive.
Guiding principles. Documented core rules like clarity over flourish and consistency across contexts so future decisions had an anchor.
This step transformed the audit from a “list of problems” into a set of foundations that gave both designers and engineers confidence — and set the stage for a token-based system.
Step 3: Go token-first 🪙
To ensure consistency across surfaces, I defined a token-based foundation for the system. Rather than reinventing everything, we began with Tailwind’s proven defaults for spacing, typography, and color, then layered in semantic naming and brand context so the system could flex across both merchant and viewer products.
Establishing tokens involved setting up three tiers:
Core tokens. Raw values that served as the building blocks.
Alias tokens. Semantic mappings that gave design and code a shared language while allowing values to evolve without breaking references.
Component-specific tokens. For patterns like buttons or cards, which pulled from aliases but defined role-specific behaviors.
This token-first approach reduced ambiguity between design and development, sped up reviews, and gave us a scalable foundation that future components could inherit automatically.
Step 4:Build the core set 🧩
With tokens in place, I created the first wave of reusable components: buttons, dropdowns, cards, and modals. Each was:
Responsive: optimized for web and mobile.
Consistent: aligned with the token system and design principles.
By starting with high-frequency components, we maximized immediate impact in the dashboard while laying groundwork for expansion into the viewer experience.
Step 5: From Figma to Storybook 📚
A design system only creates impact when it’s shared and usable across teams. To bridge design with code, I partnered closely with engineers to set up a Storybook workflow. Each Figma component was translated into a production-ready React component, with properties and variants carefully aligned across both tools. By collaborating on token names and component naming conventions, designers and engineers could speak the same language and stay aligned.
Documentation as shared language
Alongside building, I created documentation to make the system easier to understand and adopt. This explained not just what a component was, but how and when to use it.
Component-level. Described each component’s purpose, how it differed from similar ones, and when to use it.
Variant-level. Explained the ideal use cases for each variant and how they affected workflows.
Token-level. Ensured that even the smallest design decisions like colors, spacing, and typography were transparent and consistently applied
In addition to documentation, I streamlined file organization by standardizing naming, simplifying search, and converting non-configurable components into local ones. This kept the library clean, easy to navigate, and reduced friction for engineers.
This combination of Storybook, clear naming, thoughtful file organization, and detailed documentation gave both designers and developers confidence, reduced back-and-forth, and created a single source of truth the whole team could rely on.
Step 6: Driving adoption 🚀
Rolling out the system was as much about education and trust as it was about the assets themselves. I focused on education and reinforcement: running short workshops to explain tokens and component patterns, sharing the system through Figma libraries, and doing light QA to catch drift early.
The goal wasn’t perfection, but momentum: making sure developers had clarity and confidence so the system naturally became part of their everyday workflow.
An unified language
The first version of Stage TEN’s design system became the backbone for everything that followed.
Established Stage TEN’s first design system with 300+ design tokens and 30+ components, documented in Figma and React components in Storybook.
Enabled a lean team (1 designer + 2 developers) to ship faster and accelerated feature delivery and enabled many future implementations.
Improved cross-device consistency (web + mobile) and created a unified look that later extended into marketing surfaces.
Raised design literacy across the team — engineers and PMs began using shared vocabulary around tokens, spacing, and reusable patterns.
Momentum over perfection. Foundations before polish.
Start small, scale later
A design system doesn’t need to be comprehensive from day one. Starting with the dashboard-critical components gave us quick wins and visible value. Momentum builts buy-in.
Teach to drive adoption
Tokens and components mean little without adoption. Workshops, docs, and QA helped stakeholders understand why and how to use the system, making it stick.
Embrace incompleteness
Our design system was always a work in progress. Accepting that it didn’t need to be perfect to be useful taught me to focus on iteration over finality. Shipping something usable today is better than chasing an ideal tomorrow.