Building a Design System From Zero in 8 Weeks
A step-by-step breakdown of how I built a production-ready design system solo — without a team, without a big budget, and without burning out.
Every large design system article I've read assumes you have a team. A dedicated systems engineer. A content strategist. Time. Budget. Six months minimum.
I built one in 8 weeks, alone, while shipping a product in parallel. Here is exactly how — and the hard lessons that would have saved me two weeks.
Why I Built It
We had a ~40-screen product with copy-paste components, inconsistent spacing, four different shades of "primary blue," and a developer who had to ask me about visual decisions 10 times per sprint. The design debt was invisible until I mapped it: 23 unique button styles, 14 different card layouts, 7 font size definitions with no semantic meaning.
Before I started: 23 button variants, 14 card layouts, 7 unrelated font sizes. The visual entropy was costing us 2–3 sprints per quarter in rework and developer clarification cycles.
I didn't need a perfect system. I needed a good enough system that the team could actually use so we could stop bleeding time on visual inconsistency.
The 8-Week Plan
Catalog every UI element in production. Extract the real token set (color, spacing, typography, radius). Don't design new tokens yet — discover what already exists and rationalise it.
Build only the 10 components that appear on >50% of screens. For most products this is: Button, Input, Card, Badge, Modal, Toast, Avatar, Checkbox, Toggle, Dropdown.
Compose the 10 core components into the 5–7 patterns your product actually uses repeatedly. For us these were: Form, Empty State, Data Table row, Card Grid, Modal with Form.
Document while context is fresh. Usage guidelines, do/don't, variants, props. I used Notion for this — not Storybook (not yet). Storybook would have added 3 weeks of tooling setup.
Convert the token set into CSS custom properties. Run a 2-hour session with the dev team. Answer every question they have live and add it to docs. This session eliminated 80% of future design-dev clarification requests.
Update the 5 most-visited screens to use system components. Establish a simple PR-style contribution process for adding new components. Ship it.
The Token System: Start Here, Not with Components
Most designers start design systems with components. The correct order is tokens first. Tokens are the DNA. Components inherit from tokens. If your tokens are well-structured, components are largely mechanical to build.
My token hierarchy:
- Primitive tokens — raw values:
color.blue.500: #6366F1,space.4: 16px - Semantic tokens — meaningful aliases:
color.action.primary: {color.blue.500},space.component.padding.small: {space.4} - Component tokens — scoped to a component:
button.background.primary: {color.action.primary}
This structure means when the brand color changes, you update one primitive and every component updates automatically. It sounds obvious until you've spent a day manually updating 40 screens because someone changed the primary blue.
The Biggest Mistake I Made
I built 8 components in the first week, including a complex Data Table with sorting, pagination, and row selection. Took 4 days. We used it on exactly one screen. Meanwhile the humble Badge component — which appears on 32 screens — got built in 30 minutes in week 3.
Build in order of usage frequency, not visual complexity. Frequency multiplies value. A simple Badge used 32 times creates 32× the value of a complex Data Table used once.
Rule I now follow: if a component appears on fewer than 20% of screens, it goes on the backlog. The 20% that appear everywhere are what you build first.
The System After 6 Months
Six months post-launch, here's what changed:
The system isn't perfect. It never will be. But "good enough to use" is infinitely more valuable than "perfect but incomplete." The best design system is the one your team actually uses.
Need help building or scaling a design system? Let's talk — design systems are one of my specialisms.