Density, BMW’s design system, was the most requested topic at our UX hub in India by a wide margin. It came up ahead of AI workflows, ahead of Figma access, and ahead of most other standards questions. People were not discovering the design system for the first time. They were trying to use it in real work and getting stuck.
That distinction matters. Most enterprise design systems do not have an awareness problem for long. Teams hear the name, see the launch material, open the library, or meet the system during onboarding.
The harder problem appears later, when a designer needs to choose the right component, a developer needs to connect a Figma decision to code, or a product team finds an edge case that the documentation does not quite cover.
My role was local enablement rather than core component design. I helped teams at a growing technology hub understand and adopt a global system, and I carried recurring friction back to the people maintaining it. That made the work less like a campaign and more like a support loop: help teams use the standard, then help the standard learn from the teams using it.
Where adoption actually breaks
"Teams aren’t using the design system" sounds like one problem. In practice, it is usually several different problems wearing the same label.
They cannot get access. The library, the code package, the permissions, or the right workspace are missing. It is not glamorous, but it stops everything.
They do not know which component applies. The team can see the library, but their product situation does not map cleanly to the examples in front of them.
Design and code do not line up. A designer may choose the right Figma component while a developer still cannot tell which package, variant, or behaviour it corresponds to.
Their edge case is not in the guidance. Most documentation explains the middle of a pattern. Product teams usually arrive with the edges.
They reported a gap and nothing happened. This is the expensive one, because it teaches teams that feedback is a dead end.
Training helps with understanding, and sometimes with design-to-code alignment. If the real blocker is access, a missing implementation path, or an unresolved system gap, another session can make people more frustrated. You have taken an hour from a team that was blocked by something training cannot solve.
Teach it where the questions already are
We did not treat adoption as a broadcast campaign. We put design-system support in the places where teams already brought product questions.
The UX Live Center gave that work a visible local route: walk-ins, critiques, consultations, and regular Knowledge Cafe sessions. Density came up constantly because it touched daily delivery work. Teams were not asking for a brand lecture. They needed help deciding what to use, how to set up files, how design artifacts related to coded components, and where to send gaps they could not resolve locally.
Across the site’s roughly 2,400 colleagues, around two thousand came through those sessions in some form. That is strong evidence of reach, and it helped make the support visible. I would still label it carefully: it shows exposure and demand, not proof that every team adopted the system correctly afterward.
Adoption work needed a visible local route: teams brought questions in, local support helped resolve what it could, and repeated issues went back to the global owners.
FIG. 1 - LOCAL ADOPTION LOOP
Include developers, properly
A design system that only designers understand breaks at the point where it matters: implementation.
The useful sessions covered standards access, Figma usage, implementation guidance, and how design artifacts connected to coded components in the same conversation. Running one awareness track for designers and another for developers would have missed the handoff problem sitting between them.
That gap matters even more now. AI coding assistants can generate plausible interfaces quickly, but they do not automatically know which design system your product is supposed to use. If the system is not reachable from the workflow, the assistant fills the gap with something that looks reasonable and quietly bypasses the standard.
Recurring questions are data
We built feedback surveys into the sessions and tracked what people wanted next. That gave us more than satisfaction notes. It showed where the system was hard to use from a new hub’s point of view.
When the same question appears again and again, that is not forty people being slow. It may be a documentation gap, an onboarding gap, a naming problem, an access issue, or a component model that makes sense to its owners but not to the teams trying to ship with it.
Answering those questions one by one is helpful in the moment. Answering them forever means the system never improves. So we took the patterns back to the design-system team in Munich and Portugal, where product, documentation, and onboarding decisions could actually change. That part of the work does not show up in an attendance number, but it is the part that turns adoption support into product signal.
Reach is not adoption
Attendance shows that people encountered the material. It does not show that a team shipped correctly against the system.
The measures worth building toward sit further down the chain: teams accessing the library without help, components appearing in real applications, fewer custom reimplementations of things that already exist, and support questions becoming more specific instead of repeating the basics.
Those signals are harder to collect. That is a reason to improve the instrumentation, not a reason to quote reach as though it proves adoption. The honest version is stronger: the program created broad exposure and a clear feedback channel, while product-level adoption evidence still needs to be measured closer to the work.
What I would tell a design-system team
A launch is not an adoption strategy. Adoption is a service the organisation keeps using while people, products, tools, and standards change.
It needs a clear front door, someone accountable for what happens after a team asks for help, and a route back to the people who can change the system. The practical test is not whether everyone has heard of the design system. It is whether a team can use it correctly at the moment a product decision is being made.