Every design system has at least one squad that doesn't use it.
Not because they haven't heard of it. Not because they disagree with the principle of consistency. Because something about the system — something specific, something real — creates more friction than it removes for the work they actually do.
The standard response to this squad is a consistency argument, a leadership escalation, or a passive-aggressive Slack message about why the system exists. None of these interventions work. They have never worked. They are what you do when you have run out of ideas and still need to show progress.
What Resistance Actually Is
Resistance is not a personality trait. It is a signal.
When a squad consistently builds workarounds instead of using the design system, they are telling you something about the system. Not about themselves. About the system.
The workaround is the honest feedback. Every workaround says: the system doesn't solve this problem as well as the alternative. Repeated workarounds say: the gap is significant enough that the friction of building custom is worth it.
Treating resistance as a compliance problem produces compliance theater. Teams say they are using the system. They use it for the parts that are easy and build custom for everything else. The metrics improve. The adoption doesn't.
Resistance is not an attitude problem. It is a product feedback mechanism that most DS teams never formally collect.
I have encountered this in multiple organizations, across multiple teams, and the reason underneath the resistance is almost always the same. The people being told to adopt the new framework already have something working. Something they built. Something they understand. Something that, by every measurable signal — releases, user acceptance, defect rate — is performing fine. Nobody asked them what challenges they faced transitioning to the new framework. Nobody asked them whether the transition made sense from where they were standing. The system arrived and the instruction arrived with it.
The question underneath every reluctant adopter is the same: why redo work that isn’t broken? It is not an unreasonable question. It deserves a better answer than a consistency slide.
The Three Sources of Resistance
Not all resistance is the same. Diagnosing which type you are dealing with determines which intervention has any chance of working.
Source 1 — Workflow Friction
The system doesn't fit how the squad works. Not because the squad is wrong, but because the system was designed around a different workflow.
A mobile-first squad using a system built around desktop patterns. A rapid prototyping squad using a system optimized for production-quality output. An accessibility-focused squad using a system that treats accessibility as an afterthought.
The fix is not a presentation about the system’s value. The fix is a conversation about the workflow gap and a commitment to address it.
The most consistent version of workflow friction I have seen is the Figma handoff. Management pushes the approach: link the Figma file, use Dev Mode, the engineering team can inspect and build from there. It is presented as a solved problem. It is not a solved problem. Engineers try it for a minute or two. Then they close the Figma tab and call a designer. Where is this component? How big is the border radius? What is the spacing between these two elements? The call happens because the tool was designed for designers to hand off work, not for engineers to receive it. Those are different user problems. Figma Dev Mode solves the first one. The engineer’s workflow doesn’t include learning Figma to solve the second.
Source 2 — Trust Deficit
The squad has used the system before and it let them down. A component broke. A token changed without notice. A migration shipped with a guide that didn't match the actual implementation.
Trust deficits are the hardest source of resistance to address because they are historical. You cannot argue someone out of a bad experience. You can only give them a better one.
The fix is not documentation. The fix is a direct conversation that acknowledges what happened, explains what changed, and offers a specific commitment — not a general one — about what the squad can expect going forward.
Source 3 — Autonomy Defense
The squad values their ability to make their own technical decisions and perceives the design system as a constraint on that autonomy.
This is the most philosophically complex source of resistance because it is not entirely wrong. Design systems do constrain autonomy. That constraint is the point. But the constraint should be proportional to the benefit it delivers. If the squad cannot see the benefit, the constraint is all they see.
The fix is not a mandate. A mandate produces compliance theater and a squad that games the adoption metrics while building custom components with different names. The fix is a value demonstration specific enough to change the calculation.
The One Intervention That Works
Sit down with the squad lead. Not the whole squad. The lead.
Ask one question and do not defend, explain, or present until they have finished answering it:
"What would need to be true about the design system for it to be useful to your squad?"
Listen for the specific friction. Not the general complaint. The specific friction.
If they say "it doesn't fit our workflow" — ask which workflow. If they say "we've had problems with it before" — ask which component, which sprint. If they say "we prefer to build our own" — ask what the system would need to offer for that to change.
The specific friction is the product gap. Address the product gap. Not with a roadmap promise. With a timeline and a commitment.
A squad that sees their specific friction addressed in the next sprint cycle is a squad that gives the system a second chance. Not all of them will convert. Enough will.
The conversion that I have seen hold longest did not start with a presentation or a migration guide. I needed advice. A lead developer — already managing multiple projects, already overloaded — had more experience than I did with setting up Storybook locally on Mac. So I asked him. Not to adopt the system. For his expertise. He gave it. And somewhere in that conversation, his frame of reference shifted. He was no longer being asked to comply with something. He was being consulted about it. He brought his team on board. He became what we started calling the internal sales team — the person who carried the argument into rooms we were not invited into, in language his engineers would actually respond to.
The trigger was not a better system. It was being asked instead of being told. Most DS teams never try the first option because it feels slower. It is not slower. It is the only path that does not require a mandate to sustain it.
For the async version of this conversation — when scheduling a 30-minute call requires two weeks of calendar negotiation — Loom works. A three-minute video: here is the specific gap I want to understand, here is what the system currently does, here is where I think your workflow doesn't fit. Free tier covers twenty-five videos. An overloaded squad lead who will not attend a meeting will often respond to a Loom within the hour. The format signals that you have already done the thinking and are asking for a reaction, not a full conversation.
The Quick Win: One Conversation This Week
Identify your most resistant squad. Schedule a 30-minute conversation with the squad lead. Bring no slides. Bring no adoption data. Bring the one question from Section 3 and the discipline to listen before responding.
After the conversation, write down the specific friction in one sentence. That sentence is your product brief for addressing the gap.
Record it somewhere it won't disappear. Dovetail is the industry standard for synthesizing these conversations into patterns across squads — from twenty-nine dollars per seat per month. For teams that need a free option: a Notion database tagged by squad, friction type, and user group does the same job. The format is secondary. The discipline is primary: every friction finding from every squad conversation should be in one place, reviewable before every roadmap update, and visible to anyone on the DS team who might encounter the same squad again.
Bring it back to them within two weeks with a specific response. Not a general commitment. A specific one.
The Argument
Adoption scales through trust, not enforcement. The design system that earns the reluctant adopter's trust does it by solving a specific problem they told you about. The one that demands their compliance gets their compliance. It does not get their advocacy. And advocacy is the only thing that scales a service beyond the teams the DS team can personally reach.
Season 3 has been about scaling reach without scaling headcount. Season 4 is about what happens after the people problem is solved and the process problem begins. How design actually becomes code, daily, reliably, without a human in the middle every time.
Disagree loudly. Inspire boldly.
And remind me — falsely if needed — that somewhere a reluctant adopter became a design system advocate after one honest conversation.
Which squad in your organization is the most resistant — and do you know specifically why? 🤔
