Design systems should be made retrospectively

The Common Mistake

Ever seen this? A company decides they need a design system, spends months creating the perfect component library... and nobody uses it. Classic.

Real design work is messy before it's organised - and that's actually a good thing

Why "System First" Usually Flops

Building a design system before you have products is like writing a cookbook before you've cooked anything. You end up with:

1. Theoretical components that don't match real-world needs
2. Zero buy-in from teams who are busy building actual stuff
3. Missing context for how components need to work together

The Better Way: Build, Then Systemise

Here's what actually works:

1. Make real stuff first - Let teams build actual products
2. Spot the patterns - Notice what components keep getting recreated
3. Extract and refine - Only then build your system based on what's proven

Real Story: The E-commerce Fail (and Recovery)

I worked with an e-commerce company that tried both approaches:

First attempt: Six months building a comprehensive design system upfront. Result? Components didn't fit real needs, developers created workarounds, and the system gathered digital dust.

Second attempt: They focused on building features first, then extracted common patterns into a system. This time, teams actually used it because it solved problems they actually had!

A wall of screenshots is a great way to spot patterns and inconsistencies

Quick Tips for Doing It Right

1. Audit what exists - Screenshot everything and look for patterns
2. Start small - Begin with high-frequency components (buttons, inputs, cards)
3. Make it solve real problems - If it doesn't make life easier, nobody will use it

The Results

When you build systems retrospectively:

• Teams actually use them (shocking, I know!)
• Components work in real situations, not just in Figma
• Documentation includes actual examples, not theoretical ones
• The system evolves based on real needs, not assumptions

"The best design systems don't dictate how products should be built - they extract wisdom from how products were actually built."

Remember: Even the prettiest design system is useless if nobody uses it. Build products first, systems second, and you'll create something that actually helps your team.