← Back to Blog
Design Systems • • 7 min read

Design Systems That Don't Suck

Building design systems that teams actually want to use, not fight against. Lessons from Google's design system work.

Why Most Design Systems Fail

I've seen beautiful design systems that nobody uses and ugly ones that everyone loves. The difference isn't aesthetics – it's understanding that design systems are products, and your developers are your users.

If your design system feels like homework, you've already lost.

Start with Problems, Not Components

Don't begin by cataloging every button variant in your app. Start by identifying the actual pain points your team faces:

The 80/20 Rule for Design Systems

Focus on the components that appear everywhere: buttons, inputs, cards, modals. Get these right and you'll solve 80% of your consistency problems.

My Priority Order:

  1. Typography scale (everything else builds on this)
  2. Color tokens (semantic, not just hex values)
  3. Spacing system (consistent rhythm across the UI)
  4. Basic components (button, input, card)
  5. Layout patterns (how things are arranged)

Figma + Code = Best Friends

Your Figma components should map directly to your code components. Same names, same variants, same behavior. This isn't optional – it's the bridge between design and development. 

// Button component in React
export const Button = { 
  variant = 'primary', 
  size = 'medium', 
  children,
  ...props 
} => {
  return (
    <button 
      className={`btn btn--${variant} btn--${size}`}
      {...props}
    >
      {children}
    </button>
  );
};

Figma Variant Names Should Match:

Documentation That Developers Actually Read

Nobody reads 50-page design system documentation. Make it scannable, practical, and example-heavy.

What to Include:

"If your design system documentation is longer than your getting started guide, you've overcomplicated something."

Tokens: The Secret Sauce

Design tokens are the DNA of your design system. They make changes easy and ensure consistency across platforms. 

// Instead of this:
color: #3B82F6;

// Use this:
color: var(--color-primary-500);

// Or in JavaScript:
backgroundColor: tokens.color.primary[500];

Token Categories I Actually Use:

Making Changes Without Breaking Things

A good design system evolves without breaking existing implementations. Version your components and provide migration paths.

Change Strategy:

  1. Add new variant alongside old one
  2. Update documentation to prefer new variant
  3. Deprecate old variant with clear timeline
  4. Remove old variant after migration period

Testing Your Design System

Yes, design systems need testing. Not just visual regression tests (though those help), but usability testing with your actual users: the development team.

Questions to Ask Developers:

The Governance Reality

Someone needs to own the design system, but it shouldn't be a dictatorship. Create a lightweight process for proposing changes and adding new components.

Simple Governance Model:

Metrics That Actually Matter

Don't measure design system success by the number of components. Measure it by developer happiness and product consistency.

Good Metrics:

Tools I Actually Recommend

The Kawaii Philosophy

A good design system should spark joy in your development team. If using your components feels delightful rather than restrictive, you're doing it right.

Remember: you're not building a museum of perfect components. You're building a toolkit that helps real people ship real products faster and more consistently.

The best design system is the one that gets out of your team's way while quietly ensuring everything looks and feels cohesive. It's the ultimate behind-the-scenes hero.