Why is it cool to hate on design systems?

Somehow it’s become cool to hate on design systems. And Ivan’s recent tweet about Notion definitely added fuel to the fire…

But I think the pendulum has swung a bit too far and we’ve started throwing the baby out with the bath water…

Here’s why 👇

“Design system” has become a loaded term

I’ll admit… I never use the phrase “design system” anymore. It implies a complexity that makes people throw up their guard.

“Design system to me is like a very big company word”
— Raphael Schaad (Founder of Cron)

How did we get here?

Well… one reason is the most visible systems are Polaris, Spectrum, Material Design, etc. But these are often poor models to follow.

Chances are, you’re at a company where the last thing you should do is mirror a system designed to support many teams, apps, third parties, etc.

Yet these are the examples I constantly see referenced. Somehow design systems have become synonymous with scale… and it starts with our tools 👇

The shift to enterprise

Many of Figma’s latest features cater to big-ticket enterprise customers.

But what about your product? Do you really need to define typography primitives as variables? I think the answer is “no” 9 times out of 10 (although I do have an approach that keeps it simple).

Sometimes it feels like I spend much of my time in Figma Academy helping people figure out which features they don’t have to learn 😅

So let's take a step back.

Because design systems don’t have to be so “enterprise-y”…

Design systems for speed

We often fixate on standardization as the main value prop of design systems.

Through that lens, it’s easy to view it as the thing to invest in once you’ve “figured out” the UI and are ready to codify it.

But don’t forget about speed.

I'll suggest design systems are most valuable when you don’t know what the product will be… that’s why they are the perfect first step for startups.

“Any startup that I’ve worked on that's always the first thing that I've built because it lets me go fast”
— Henry Modisett (Head of Design @ Perplexity)

Investing in a set of core components minimizes the number of knobs you need to turn in order to iterate. You’re laying a nimble foundation… not a rigid one.

The key is laser-focusing on the atomic level 👀

That way you’re never over-architecting the system. You’re simply giving yourself an open-ended box of legos that you can use to assemble UIs more quickly.

And it’s quite easy to nail down these core components 👇

Design systems are obvious

So much of a design system is consistent from product to product.

“We didn't know what the product was going to be… we didn't know how it was going to work… but it probably needed buttons, a type system, a color system, etc.”
— Henry Modisett

You don’t need product-market-fit to confirm that you’ll probably have 2-3 button sizes and they’ll almost certainly include 40 and 48px for web 😆

I even double-checked a system I made 5+ years ago and sure enough… the core elements are pretty dang close to the system I designed most recently for Maven:

• buttons

• inputs

• dropdowns

• icon buttons

• typography

• color

• etc.

So don’t overthink it.

There’s no reason to delay building out these core components. I even have my neutrals palette down to a repeatable science.

And chances are that even if you haven’t defined these elements in Figma, your engineers are most likely writing re-usable code already. And guess what that means… 😉

“If that is true, then you have a design system. It’s just a semantic issue at that point”
— Henry Modisett

Reframing design systems

If it’s just an issue of semantics, then what do we call it?

I’m orbiting around the term “design toolkit” right now… it’s how Raphael Schaad referred to his system for Cron. Somehow it feels fresh compared to “UI Kit” (although the extra syllable isn’t ideal).

More important than the name though… here’s what I think a design toolkit includes:

• Core atomic components (buttons, inputs, dropdowns, etc.)

• Typography (definitions for all headings, paragraphs, etc.)

• Color system (could just be a brand color, alert colors, and a ramp of grays)

• Icons (I typically just import Phosphor)

• Shadows (I define 3-5 up front for quick access)

Here’s what I think a design toolkit ignores:

• More complex elements that make use of multiple components

Once you graduate to defining more complex “organisms” as components, you’re building a connected system rather than a simple box of legos. That’s where I draw the line.

TLDR

The pendulum has swung too far with design systems.

I believe every product can benefit from a set of simple components and that investing in that toolkit up front is high ROI.

If design systems are cool enough for Henry Modisett and Perplexity… they're cool enough for you :)

Listen to the full episode on YouTube, Spotify, Apple, or wherever you get your podcasts 👇