Start Here Before You Start a Design System
A no-fluff guide from someone who learned it the long, hard, token-overloaded way.
Start here before you start a design system
A no-fluff guide from someone who learned it the long, hard, token-overloaded way.

The first time you build a design system, it feels like you’re doing everything, right? Because you are doing everything.
Tokens? Yes. Components? All of them. Icons? Let’s make custom ones from scratch. Documentation? Sure… someday… probably… maybe.
Then one day you zoom out and realise:
I have 447 buttons, 21 shades of grey, and no idea how padding works anymore.
So here it is. If I could rewind time (but keep my Figma skills), this is how I’d build a design system from scratch. Cleanly. Sanely. Happily.
1. Make a list of all the components you know you’ll need

The final list of components we created
Before touching Figma, I’d write a real list. Not “everything that might be nice to have someday.”
I mean: What do we actually use across the product?
- Buttons? ✅
- Tags? ✅
- A fully animated accordion with five microinteractions you’ll regret maintaining? ❌ Please no.
2. Create a colour palette

Our colour palette on the left and a grayscale version of the same on the right, which shows the distinct areas of flat colour, that limited ink usage.
Pick your brand colours. Pick your neutrals. Don’t forget to check the contrast.
Don’t let anyone sneak in a new shade of blue called “slightly nicer blue.” That’s a trap.
3. Choose a naming convention
Pick one that your developers are already comfortable with — trust me, it’ll save you hours of renaming (and mild existential dread) later. Whether it’s:
- snake_case
- camelCase
- PascalCase
Choose one and stick to it. When naming is consistent across code, tokens, and design files, it’s easier for developers to read, understand, and reuse things. No one wants to guess whether it’s button_primary, PrimaryButton, or BtnPrimary.
Additional tip: Layer naming is underrated, but it’s basically Figma currency
Good naming gives you so much leverage when you’re making bulk changes, searching for elements, or just trying to stay sane in a sea of rectangles and frames.
4. Borrow an icon library. Seriously.

Phospor icons library available on Figma community
Don’t reinvent the pencil icon.
Unless you have a dedicated and amazing team of visual designers, like I did.
Pick a good set (Phosphor, Remix, Feather, anything solid), convert it into Figma components, and call it a day. Why components? So you can swap them later like a magician.
Here’s a quick tip:
To quickly swap components in Figma, hold Option (⌥) + Cmd (⌘) on Mac or Alt + Ctrl on Windows while dragging a component instance from the Assets panel onto an existing component instance. This action replaces the original instance with the dragged instance.

Quick component swap in Figma
5. Create primitive tokens

Our primitive tokens
Start small, start right. Create tokens for:
✅ Global colours
✅ Global sizes (8, 16, 24… not 17.5 please)
✅ Typography:
- Font family
- Font weights
- Font sizes (web + mobile)
- Line heights
- Letter spacing (just for labels — don’t go wild)
✅ Shadows
(Ps: We added opacity later)
6. Create semantic tokens

Our semantic tokens
Now, map intent.
✅ Colour: Background/surface, text, stroke, icon
✅ Padding
✅ Corner radius
✅ Stroke thickness (1px, 2px, nothing fancy)
✅ Icon size
This is the moment when your system begins to speak human.
7. Turn colours and fonts into styles


Our colour styles on the left and text styles on the right
Font styles keep things sane. They make your typography tokens discoverable to the team in Figma’s “Text Style” panel.
Make styles for:
✅ Headings (H1, H2, H3…)
✅ Body
✅ Caption
✅ Label
Just enough to cover your UI — not enough to write a novel.
Style v/s Tokens:
- Styles are visible to other designers
- Variables (tokens) are smart, but not always obvious — they live inside the Variables panel.
- Variables shift your mindset from “What looks good here?” to “What value already exists in the system that works here?”
- Styles + tokens = happy team, clean UI
8. Start building: Components -> Widgets -> Flows

An abundance of buttons, 447 remember?
Now you can build your simple components like buttons. Not before. Not while naming tokens. Not while picking icons. Now.
Use your tokens. Tweak if needed. Let the system respond to the component, not the other way around.
Then, take on the big ones: modals, date pickers, tables — the stuff that makes you feel both accomplished and slightly dead inside.
And finally, build your flows. You’ve earned this. You’re now wiring up pages using polished, documented, beautifully tokenized components like a real adult. Bravo.
9. Document while it’s fresh

Documentation of buttons
Don’t wait for “once everything is done.” That’s how you end up writing documentation in a panic at 2 a.m.
Instead, build tiny documentation templates:
- Description
- Anatomy
- States
- Dos/Don’ts
- Tokens used
And fill them out as soon as you finish each simple component.
10. Add some fun - hide an easter egg

A unicorn for components that don’t exist (yet)
Just because you’re building a design system doesn’t mean you can’t throw in a little joy. Add a surprise element — maybe a tiny unicorn hidden in your sticker sheet or a witty comment in a token description. It makes the grind more bearable and gives your team a reason to smile mid-sprint.

Deenaz's (my colleague’s) response when she found this easter egg!
The End (and the beginning)
This list isn’t perfect, but it’s real. If you’re starting your design system journey, feel free to steal it, remix it, or print it out and highlight all the parts you already forgot to do.
Design systems are a lot. But they also become a lot less once you stop chasing perfection and start chasing consistency.
Let me know if you’d do anything differently — or if you also have 447 buttons haunting your dreams.
PS: Nothing happens without your people
For surviving token tantrums, variant spirals, and the occasional identity crisis, where we were convinced we were doing it all wrong. We built this beauty for Apollo 247's design system — and somehow had fun doing it too.
Prateekshankar Dixit Akar Sinha Arushi Agarwal Ishita Chawla Ashika Singh Srishtidudeja
If you’d like some of the templates, drop a comment below. Other articles I wrote - We had a design system. It had … issues
Till then, keep going and take care of yourself.
I’ll do the same.
Design System Inspiration
- Blady by Razorpay — My personal favourite
- Polaris by Shopify — Excellent documentation and structure.
- Lightning Design System (Salesforce) — Great example of scalability and implementation.
- Material 3 Guidelines — Industry standard for components and their usage. Use it as a design system dictionary.
Figma-Specific Resources
- Intro to Variables by Figma
- Explore Component Properties by Figma
- Figma Dev Mode — If you’re collaborating closely with developers.
Articles & Thought Leadership
- Nathan Curtis on Design Systems — One of the most respected voices in this space.
- Brad Frost’s Atomic Design — Foundational concept for components.
- Design Tokens 2.0 — The Ultimate Guide by Valentino Baptista
Tools You Might Need
- Icon libraries: Phosphor, Remix, Feather,
- Design System Checklist
메타데이터
- post_id
- cd9a4285e46d
- slug
- start-here-before-you-start-a-design-system-cd9a4285e46d
- url
- https://www.designsystemscollective.com/start-here-before-you-start-a-design-system-cd9a4285e46d
- canonical_url
- https://www.designsystemscollective.com/start-here-before-you-start-a-design-system-cd9a4285e46d
- author_url
- https://medium.com/@aarzookhare
- status
- ok
- fetched_at
- 2026-08-07 21:16:54