The question came up again. I hear it often when talking to design system teams about their biggest struggles:

“How are we supposed to deliver a component that perfectly serves many different use cases?”

The honest answer? You’re not.

I’m not exactly sure where that expectation came from, but I have a reasonable guess. Many organizations start their design systems by building reusable pieces for one product—often a flagship website or another critical initiative. The components made for that project had specific use cases, so they were designed to fit those needs exactly.

Problems arise when teams try to share those components across other products. What worked so well in one context suddenly feels too rigid or ill-fitting in another.

In these cases, the design system wasn’t built with scale in mind. It works well at first but runs into fit problems as it expands.

On the other hand, a design system built for scale from the beginning runs into fit “problems” almost immediately.

What’s a design system team to do?

The solution is to reset expectations immediately—first with yourself, and then with your potential design system users.

If you think your job as a design system team is to provide perfect, drop-in solutions, think again.

Your job is to give designers and engineers components that save them time and elevate their work compared to creating from scratch.

If building a component from scratch would take them two days, and you provide a version that gets them halfway there, leaving the last half for customization, that’s a success.

Design system components are more often headstarts than holistic solutions. If you give someone a 25%, 50%, or 75% headstart, you’ve done good work.

Once you embrace that, start setting the same expectation with your potential users. Here’s a small script I use, either in writing or in conversation, before delivering components:

Release yourself from the unrealistic expectation of “perfect” design system work.

A small headstart can make a huge difference.