Internal Customers

Every design system kickoff meeting has the same slide.

It usually appears around slide four. It has a headline that says "Who is this for?" and a single answer in the center of the slide in a large font. The answer is: everyone.

I once watched a junior designer defend an engineering decision in a design meeting. Not passively. Actively. She had been working closely with the lead developer on her squad, and somewhere in that collaboration, her frame of reference had shifted. She was no longer defending the design system's decisions. She was defending the engineering team's workarounds — in a room full of the people who had built the system she was working around.

She wasn't a bad designer. She was a designer who had been influenced by the user group with the most daily proximity to her work. That is not a character flaw. It is a distribution problem. And it is what happens when a design system treats everyone as its user and ends up serving whoever happens to be standing closest.

Why "Everyone" Fails

A product built for everyone is optimized for no one. This is not a design principle. It is an engineering constraint, a resource allocation reality, and the reason most design systems plateau at partial adoption and stay there.

When you build for everyone, you make compromises in every direction simultaneously. The component is flexible enough for advanced users but confusing for new ones. The documentation is detailed enough for specialists but overwhelming for generalists. The API surface is comprehensive enough for complex use cases but too complex for simple ones.

Something inside that component is asking its users to fight it. Usually at 3pm on a Wednesday when the sprint ends on Friday.

Every repeated workaround is feedback you have not formally collected yet.

The Three User Groups You Actually Have

Every design system serves three distinct user groups. They have different needs, different success criteria, and different relationships with failure.

Group 1 — Product Designers

They are your most visible users. They open the Figma library every day. They are also your most likely to detach, override, or quietly build parallel solutions when the system doesn't fit their immediate need.

What they need: flexibility within constraints. Speed without sacrificing quality. The ability to move fast and know the system will catch what they miss.

What they fear: rigidity. A design system so locked down that every edge case becomes a negotiation with the DS team.

A designer who fears the design system will work around it. Quietly. Efficiently. Until the workaround becomes the standard.

Group 2 — Front-End Engineers

They are your power users. The ones whose adoption — or non-adoption — determines whether the design system exists in production or only in Figma.

What they need: a component API that is predictable, prop naming that is consistent, accessibility that is built in rather than bolted on, and documentation that answers their questions before they have to ask them.

What they fear: a system that creates more work than it eliminates. A component that is harder to implement correctly than to write from scratch.

An engineer who finds your system harder to use than not using it will not file a bug report. They will write a custom component and move on. You will find out when you look at the detach rate.

Group 3 — Product Managers

They are your least visible users and your most powerful advocates — when they are convinced.

PMs do not use the design system directly. They control the conditions under which it gets used. They set sprint priorities. They approve the allocation of engineering time to adoption work. They decide whether a squad uses the design system component or builds a custom one to ship faster.

What they need: one number. Implementation velocity. The time saved per sprint by using the system versus not using it. That is usually when support becomes enthusiastic.

I once worked with a PM who had started his career as a designer before transitioning into product management. He was the only person in that squad I could trust to carry the design system argument into spaces I was not invited into. Not because he had authority over the other PMs. Because he spoke both languages. He understood the design system's logic well enough to translate it into the velocity framing his engineering colleagues would act on. Without him, the argument went nowhere. With him, it moved.

That is not a PM success story. That is a distribution problem that got solved by accident. The design system should not depend on finding the one PM who used to be a designer. It should build the translation layer deliberately.

How to Segment Your Users in Practice

Three steps. Do them in order.

First: identify which squads are using the design system and which are not. This is your adoption map. It tells you where the system has traction and where it doesn't.

Second: for each non-adopting squad, identify which user group is the blocker. Is it the designer who finds the system too rigid? The engineer who finds the API too complex? The PM who hasn't seen a velocity argument?

Third: address the blocker for that user group specifically. Not with a general communication. With a targeted intervention. A conversation with the engineering lead. A flexibility improvement for the specific component that is being overridden. A velocity report for the PM who controls the squad's sprint priorities.

General adoption campaigns don't work. Targeted user group interventions do. The difference is whether you know which group is the actual blocker.

Sometimes the blocker is not a failure of communication. Sometimes the system genuinely does not serve the use case. I watched a squad building a Progressive Web App stop following the design system's iPad guidelines entirely. Not because they were being difficult. Because the guidelines were written for native iPad applications. Their product was not a native iPad application. The resistance was completely legitimate. The DS team had been providing instructions for a platform context that did not apply.

That squad's workaround was not feedback about their attitude. It was feedback about the system's coverage model. The correct response was not a mandate. It was an acknowledgment and a roadmap item.

The Quick Win: One User Interview This Week

Pick one non-adopting squad. Identify the user group that controls adoption in that squad. Schedule a 30-minute conversation with one person from that group.

Ask them one question:

"What would the design system need to do differently for you to choose it over your current approach?"

Do not defend the system. Do not explain its roadmap. Just listen. The answer will tell you more about your product gaps than any analytics tool you are currently running.

The Argument

Design systems don't fail because of bad components. They fail because the people who needed to use them decided not to. Understanding which user group made that decision — and why — is the most important product research your team will ever do.

Disagree loudly. Inspire boldly.

And remind me — falsely if needed — that somewhere a design system serves all three user groups equally well.

Which user group is blocking adoption in your lowest-performing squad right now?

Next in Season 2: The Internal Pitch →