Design Systems Should Tell Us What Not to Build

When we talk about Design Systems, we usually talk about patterns.

Buttons. Cards. Forms. Navigation. Layouts.

We document how components should be built, when they should be used, and what variants they support.

But there is another concept that deserves just as much attention:

Anti-patterns.

I hadn't paid much attention to the term until recently, but the more I think about it, the more important it seems—especially when we start thinking about Design Systems as a source of knowledge for AI.

What is an anti-pattern?

An anti-pattern is a solution that may seem reasonable at first, but has repeatedly proven to create problems.

A pattern says:

"This is a good way to solve this problem."

An anti-pattern says:

"We've learned that solving this problem this way usually causes problems."

The concept isn't specific to design. It has existed in software engineering for decades.

For example, a particular architecture might technically work, but create excessive complexity and make the system difficult to maintain.

The same idea applies to UX and UI.

A component can be perfectly designed and still be used incorrectly.

Patterns tell us what to do

Imagine a Design System documenting buttons.

It might say:

Use the primary button for the main action of a section and secondary buttons for supporting actions.

That's a pattern.

It gives designers and developers a recommended solution.

But there's another question worth answering:

What should we avoid?

For example:

Don't use multiple primary buttons next to each other.

Why?

Because when every action has the same visual emphasis, the hierarchy becomes unclear.

Instead, we might have:

[ Save ]   [ Cancel ]   Delete
   ↑
Primary action

rather than:

[ Save ]   [ Delete ]   [ Cancel ]
   ↑           ↑            ↑
   Same visual emphasis

The difference isn't about whether the buttons technically work.

It's about the experience they create.

Anti-patterns aren't absolute prohibitions

This distinction is important.

An anti-pattern doesn't necessarily mean:

"Never do this."

It means:

"This approach tends to create problems and should generally be avoided unless there is a good reason to use it."

Context still matters.

There may be situations where two primary actions are appropriate.

The purpose of an anti-pattern is not to remove design judgment.

It's to preserve the lessons we've already learned.

What does this look like in a Design System?

Consider a card component.

A traditional documentation page might say:

Recommended

Use cards to group information that belongs together and benefits from visual separation.

But we could also document:

Anti-patterns

• Don't wrap every piece of content in a card.
• Avoid using cards when spacing and typography already provide sufficient hierarchy.
• Don't nest cards inside cards unless there is a clear structural reason.

This is valuable because the problem isn't necessarily the component itself.

The problem is overuse.

A perfectly designed component can still create a poor interface when applied everywhere.

Design Systems preserve more than UI assets

This is where the concept becomes more interesting to me.

A Design System is often treated as a collection of reusable assets:

• Colors
• Typography
• Spacing
• Components
• Icons
• Tokens

But teams also accumulate something less tangible:

design knowledge.

Why did we choose this pattern?

Why don't we use that one?

What problems have we encountered?

What mistakes should a new designer avoid?

What looked good in isolation but didn't work in the product?

That knowledge is incredibly valuable.

And much of it can disappear when people leave a team.

Anti-patterns provide a way to capture some of that knowledge.

The AI connection

This becomes even more relevant as AI starts participating in design and development.

Imagine asking an AI agent:

Build a Product Detail Page using our Design System.

If the agent only has access to your tokens and components, it knows what is available.

It knows that you have:

Button
Card
Modal
Input
Tabs

But it doesn't necessarily know how you expect those components to be used.

It might create a page where everything is inside a card.

It might add three primary CTAs.

It might use every available component simply because those components exist.

The agent has the building blocks, but not necessarily the judgment.

Anti-patterns can help communicate that judgment.

For example:

## Anti-patterns

- Avoid using multiple primary CTAs within the same section.
- Don't wrap every section in a card.
- Don't use modals for information that can be presented inline.
- Avoid introducing a new component when an existing pattern solves the problem.

Now the Design System is communicating more than implementation.

It's communicating experience.

A Design System can encode failure

This may be the most interesting way to think about anti-patterns.

Patterns represent successful solutions.

Anti-patterns represent lessons from unsuccessful ones.

Both are valuable.

Design System
│
├── Patterns
│   └── "This is how we solve this problem."
│
└── Anti-patterns
    └── "We've learned that solving it this way
        usually creates problems."

In that sense, a mature Design System isn't just a collection of things a team has created.

It's also a record of things the team has learned.

From UI kit to design knowledge

This changes how I think about Design Systems.

A UI kit gives you components.

A Design System gives you components, rules, principles, and context.

And an AI-native Design System may need to go even further.

It needs to communicate not only:

What can I use?

but also:

How should I use it?

and perhaps most importantly:

What should I avoid, and why?

That's what makes anti-patterns so interesting.

They aren't simply a list of forbidden UI decisions.

They're a way of turning experience into reusable knowledge.

A mature Design System doesn't only encode what to build. It also encodes what we've learned not to build.