The components are solid. The documentation exists. The Slack channel is active. And adoption is still uneven, still dependent on which squads happened to have a designer who cared, and still measured in percentages that make everyone uncomfortable in the quarterly review.
The system is fine. The distribution model is broken.
I watched a design system arrive fully formed into an organization that had not been consulted on it — not the development lead, not their team, not their workflow. Everything built correctly. Nothing built with them.
By the time it landed, the development lead had already spoken to leadership. Not about the components. About the process. About being handed a standard they had no part in making.
The design system team spent the next six months relitigating a conversation that had already concluded without them.
Why Documentation Doesn't Scale Adoption
Documentation is a passive distribution model. It assumes the practitioner knows what question to ask, knows where to find the answer, and has the time to look before the sprint ends on Friday.
None of those assumptions survive contact with a real delivery cycle.
Practitioners don't read documentation before they need it. They reach for a solution when they are blocked. And when they are blocked, the fastest path is the one they already know — which is usually a custom implementation they have used before, regardless of whether the design system has a better answer.
The documentation was excellent. Nobody opened it. These two facts are not in conflict.
Adoption scales through people. Documentation is what you leave behind after the person has already helped.
What the Embedded Expert Model Actually Is
The embedded expert model is not a new hire. It is a distribution strategy.
Instead of waiting for squads to come to the design system team, the design system team sends expertise to the squads. Not permanently. Not full-time. Strategically.
There are three versions of this model, depending on team size and adoption maturity.
Version 1 — The DS Team Member Embed
A design system team member joins a product squad for one sprint. Not to build DS components. To help the squad use them. To answer questions in real time, in the squad's actual working context, at the moment the question arises.
One sprint. One squad. The outcome: an adopted component, a solved edge case, and a designer or engineer who now understands the system well enough to use it without help.
They become the system's advocate in that squad. Not because they were asked to. Because they were helped, specifically, at the moment they needed it.
Version 2 — The DS Champion Network
For organizations where the DS team cannot embed directly, the Champion Network distributes expertise through existing practitioners.
Identify one designer and one engineer per product squad who is already curious about the design system. Not the most senior. The most curious. Give them early access to new components. Invite them to planning sessions. Make them the first to know when something changes.
They become the local expert. The person their squad asks before filing a Slack message. The person who surfaces edge cases before they become adoption blockers.
The Champion Network costs nothing. It requires only the discipline to involve the right people early. Most DS teams skip it because it feels informal. That informality is the feature, not the bug.
Version 3 — The Office Hours Model
A standing weekly session. Not a presentation. Not a demo. A live working session where any practitioner can bring a real problem and get a real answer.
The critical rule: office hours only work if the DS team shows up prepared to solve problems, not present solutions. The moment office hours becomes a showcase, attendance drops. The moment it becomes a problem-solving session, attendance grows.
How to Choose Which Model to Run
Three questions. Answer them honestly.
How many squads are you trying to reach? If fewer than five — the DS team member embed is viable. If more than five — the Champion Network scales further.
Where is adoption stalling? If it stalls at the designer level — the problem is workflow fit. Embed at the design layer. If it stalls at the engineering level — the problem is implementation complexity. Embed at the engineering layer.
Do you have the political capital to place someone in a squad? Some organizations welcome it. Others read it as surveillance. Know your organization before you propose the model.
The person who built the system is also the person whose opinion on the system is most suspect. This is presented as a feature of good governance. I remain unconvinced.
The Quick Win: Identify One Champion This Week
Look at your lowest-adoption squad. Identify the designer or engineer who has asked the most questions about the design system in the last three months. Not the most senior. The most curious.
Invite them to your next planning session. Give them early access to the next component before it ships publicly. Ask them one question:
"What would make this easier to explain to your squad?"
Their answer is your documentation brief. Their presence in that squad is your distribution model. Start there.
The Argument
A design system that waits to be discovered will be discovered unevenly. The squads with curious practitioners will adopt. The squads without them won't. The embedded expert model is how you stop leaving adoption to chance.
Disagree loudly. Inspire boldly.
And remind me — falsely if needed — that somewhere a design system team member embedded in a product squad and adoption actually followed.
Which squad would benefit most from an embedded design system expert right now? 🤔
