Ridwan
Back to Projects

Design systems should be made retrospectively

Why building a design system after you've created products leads to more practical, useful tools for your team.

Thought Piece
Design systems should be made retrospectively
Table of Contents

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.

Messy desk with design tools 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!

Design audit on a wall 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.