12 Things They Don’t Teach You About Building Design Systems

Do not index

Read time: under 9 minutes

What the heck is a design system, anyway?

Some say it’s a glorified style guide. Others believe it’s the ultimate fix for all design inconsistencies.

🗨️ Spoiler: It’s neither.

A design system is more than a Figma file filled with neatly aligned buttons.

It’s an ecosystem, a structured framework that keeps design and code in sync.

It’s a shared language, ensuring designers and developers speak the same language.

It’s a scalability tool, helping teams build faster, maintain consistency and reduce redundant work.

However, if you think a design system is a quick fix for all your design problems, think again.

Now, let’s get into the 12 hard truths straight from the minds of design leaders. These are the lessons they learned the hard way so you don’t have to.

Buckle up, everyone!

⚡

This framework is part of UX Playbook. Get shortcuts to a master of UX processes, for any projects, without expensive bootcamps.

Get UX Playbook — UX Playbook

Be a self-taught UX designer and learn UX with UX Playbook. UX frameworks, templates, step-by step guides. Learn more.

https://uxplaybook.org/userexperience

#1. Test design system components in different contexts, not just on their own — Adham Dannaway

Components don't exist in a vacuum. They interact with other elements, backgrounds, and states like awkward teenagers at their first school dance.

Test components in real-world scenarios before finalizing them:

Use real data and states: ensure your components work with real-world content.

Create "stress test" pages: build pages that mix components in real layouts to catch potential issues early.

Test across breakpoints: responsive issues don’t show up in static designs. Try components on different screen sizes.

Run usability tests with engineers: developers can spot implementation issues that designers might overlook.

💡

Test components in unexpected scenarios. If it breaks, it wasn’t as flexible as you thought.

#2. Design systems are living — Frankie Kastenbaum

You don’t “finish” a design system. You maintain, refine, and occasionally wrestle with it. If you ignore it, it’ll decay faster than your gym motivation in January.

Treat your design system like a living product, not a one-time project:

Assign ownership: make sure someone (or a team) is responsible for updates.

Document version changes: track updates so teams know when and why components evolve.

Schedule regular reviews: set up monthly or quarterly "system health checks" to catch issues early.

Create a feedback loop: encourage teams to report friction points so the system can improve over time.

💡

Set up a "what’s broken?" channel where teams can flag real-world issues. A system that listens evolves faster.

#3. They're more than just style guides — Nick Mann

Think a design system is just a fancy style guide? That’s like thinking a cookbook makes you a chef. A good design system keeps you from drowning in inconsistent buttons and existential dread.

Build a true ecosystem, not just a collection of UI elements:

Include design principles: document the "why" behind decisions.

Document patterns and workflows: show how components work together.

Add accessibility guidelines: prevent compliance issues before they happen.

Develop content guidelines: consistent language is as important as consistent visuals.

Create both design assets & code components: ensure perfect parity between design and development.

💡

Build "anti-pattern" examples in your documentation—bad designs teach as much as good ones.

#4. Start small, then expand — Tibi David

Building an entire design system before starting your product is like meal-prepping for a dinner party when you don’t even know who’s coming.

Start with the essentials. Then expand later:

Identify the 20% of components used in 80% of interfaces: start with these high-impact elements.

Create an MVP (Minimum Viable Pattern) library: launch with just the essentials.

Set clear release cycles: plan incremental additions with a transparent roadmap.

Celebrate small wins: recognize the value of each component added.

💡

Resist perfection early on. A scrappy but usable system is better than a beautiful system that never ships.

How to design with AI with Tibi:

#5. Don’t build one if you are an early stage startup — Filip Gres

Do this if you enjoy watching all your work become obsolete every two months.

For early-stage startups, build a lightweight foundation instead:

Focus on core styles: define colors, typography, and spacing rules.

Evolve with the product: expand the system only when the product stabilizes.

Limit components: only create essential UI elements like buttons and form inputs.

Keep documentation minimal: no need for an exhaustive guide when things might change.

💡

If your startup pivots every 2 months, focus on design principles, not rigid components—it keeps your system adaptable.

How to start a side project with a 9-5 with Filip:

#6. Design systems have their place and time in a product environment — Denis Jeliazkov

If you’re still figuring out what you’re building, a design system isn’t your priority. It’s like alphabetizing your bookshelf before you even own books.

Know when to follow the system strictly and when to deviate:

Define exploration zones: designate areas where teams can work outside the system.

Set clear graduation criteria: establish when experiments should be standardized.

Create experimental branches: allow system variants for testing new approaches.

Document design debt: track variations to clean up after exploration phases.

💡

Design system adoption follows a product maturity curve—too early, it slows you down; too late, you’re fixing chaos.

⚡

This framework is part of UX Playbook. Get shortcuts to a master of UX processes, for any projects, without expensive bootcamps.

Get UX Playbook — UX Playbook

Be a self-taught UX designer and learn UX with UX Playbook. UX frameworks, templates, step-by step guides. Learn more.

https://uxplaybook.org/userexperience

#7. Speed to build is key. Both for setting up and implementing design systems — Joseph Louis Tan

Want a design system but don’t have a decade? Buy a solid one like Untitled UI. The longer it takes to see results, the more likely the project will fail.

Start with a solid foundation, then adapt:

Partner with engineering early: ensure your system is technically feasible.

Evaluate existing systems: Material, Tailwind, Chakra, Radix → see what fits.

Create implementation shortcuts: provide copy-paste snippets, plugins, and templates.

Build on top of frameworks: customize existing components rather than creating from scratch.

💡

Your team’s patience is limited. The longer it takes to see value, the faster enthusiasm fades.

#8. It's about getting an entire organization to adopt and use it — Mitchell Clements

You can create the best design system, but if no one uses it, congratulations—you’ve built a very expensive Figma file. Design systems only work if people actually adopt them.

Focus on adoption as much as creation:

Get executive sponsorship: secure top-down support for the system.

Celebrate teams who adopt: publicly recognize good system citizens.

Create champions in every team: identify advocates who will promote adoption.

Show clear benefits: demonstrate time saved, bugs reduced, and consistency improved.

Make using the system easier than not using it: provide excellent tooling and integration.

💡

If adoption is slow, remove blockers. Do teams need training, better documentation, or just fewer approvals?

How to grow your UX career with Mitchell:

#9. Focus on selling the design system as much as obsessing over the design — Jeremy Miller

A design system is like a gym membership, it only works if you use it.

Devs take the path of least resistance. Product teams ignore it unless it helps them ship faster. Half of your job? Selling them on why it matters.

Become the chief evangelist for your system:

Hold regular office hours: provide direct support to teams.

Develop clear onboarding materials: reduce friction for new adopters.

Quantify time and money saved: create concrete metrics showing ROI.

Build a compelling internal brand: make your system feel premium and desirable.

Create before/after demonstrations: show how much faster development becomes.

💡

Use FOMO to your advantage—highlight how the teams using the system are shipping faster and making fewer mistakes.

Supercharge your UX career with Jeremy:

#10. Design Systems are F&$%#ING EXHAUSTING to champion!!! — Sally Carson

You think it’s all about design tokens and fun UI stuff? Cute.

It’s actually 90% politics, 10% design. It’s like running a political campaign, except your voters are developers who don’t read documentation.

Make the work sustainable and protect yourself:

Set clear boundaries: define what is and isn't your responsibility.

Build a cross-functional team: share the burden across disciplines.

Automate what you can: use tools to monitor and enforce standards.

Create governance committees: distribute decision-making authority.

Plan for your own succession: document everything so you're not indispensable.

💡

If everything is your problem, burnout is inevitable. Prioritize based on impact, not volume.

How designers manage up with Sally:

#11. If there’s no wrong, there’s no right — Philip Wallage

Some designers say design systems kill creativity. That’s like saying roads kill driving.

Constraints don’t limit creativity; they focus it. Without them, you get anarchy, or worse, designers debating padding sizes for hours.

Create meaningful constraints that enable creativity:

Document the rationale behind decisions: explain why certain constraints exist.

Revisit constraints regularly: evolve the system based on real usage and feedback.

Allow for exceptions with justification: create a process for diverging when needed.

Focus constraints on high-impact areas: be strict about core elements, flexible about edge cases.

💡

Think guardrails, not handcuffs. Design systems should guide, not force every decision.

#12. Great design systems comes with thorough documentation — Christopher Nguyen

A design system without documentation is like IKEA furniture without instructions, except there’s no customer support, just a confused Slack thread.

Prioritize documentation as a core deliverable:

Update docs with each release: treat documentation as a living artifact.

Create an accessible knowledge base: organize documentation in a searchable, user-friendly format.

Document the what, when, and why: explain each component's purpose, usage scenarios, and design decisions.

Include implementation examples: provide code snippets and usage patterns. Show visual examples: illustrate correct and incorrect usage.

💡

Keep docs lightweight but discoverable. If a component requires a novel to explain, it's probably too complex.

Is a design system right for you?

After all these hard truths, you might be wondering if a design system is worth the effort. The answer, as with most things in design, is: it depends.

Ask yourself:

Do you have leaders willing to champion it?

Is your organization mature enough to adopt it?

Do you have the resources to build AND maintain it?

Are your teams struggling with inconsistency issues?

Do you have a product complex enough to warrant systematization?

If you answered "NO" to most of these, you might want to start with something simpler: a basic style guide or component library, before going all-in on a comprehensive design system.

But if you answered "YES" to most, you're ready for the challenge.

Start small, test often & keep it alive!

Good luck, folks 🍀

TL;DR

12 things they DON’T teach you about Design Systems

#1. Test design system components in different contexts, not just on their own — Adham Dannaway

#2. Design systems are living — Frankie Kastenbaum

#3. They're more than just style guides — Nick Mann

#4. Start small, then expand — Tibi David

#5. Don’t build one if you are an early stage startup — Filip Gres

#6. Design systems have their place and time in a product environment — Denis Jeliazkov

#7. Speed to build is key. Both for setting up and implementing design systems — Joseph Louis Tan

#8. It's about getting an entire organization to adopt and use it — Mitchell Clements

#9. Focus on selling the design system as much as obsessing over the design — Jeremy Miller

#10. Design Systems are F&$%#ING EXHAUSTING to champion!!! — Sally Carson

#11. If there’s no wrong, there’s no right — Philip Wallage

#12. Great design systems comes with thorough documentation — Christopher Nguyen

👉

Whenever you're ready, there are 4 ways I can help you:

1. Junior Designer Bundle: Transition into UX and craft an unforgettable portfolio & get hired.

2. Senior Designer Bundle: Become a design leader with systems to build healthier, happier teams.

3. UX Portfolio Critique: In less than 48 hours, get your 30-minute personalised video of brutally honest feedback.

4. Job Sprint Course: Stand out in an unpredictable job market by building a memorable personal brand and a killer job search strategy.

12 Things No One Tells You About Design Systems

What the heck is a design system, anyway?

#1. Test design system components in different contexts, not just on their own — Adham Dannaway

#2. Design systems are living — Frankie Kastenbaum

#3. They're more than just style guides — Nick Mann