BMW Group already had a mature DesignOps organisation: design standards, a design system, UX measurement services, Figma administration, community programmes, and consultation for teams that did not yet have designers. The services existed, and they were meant to be available across the company.
When BMW TechWorks India started scaling, the problem was not that those services were missing. It was that many teams did not know how to reach them at the moment they needed help.
Nothing was hidden and nobody was refusing access. There was simply no local way in. A global function can be available everywhere and still feel far away.
The gap is distance, not information
A central team naturally organises its work as services, because that is how the work is staffed, funded, and maintained. From the inside, the catalogue makes sense.
From a product team’s desk on a Tuesday afternoon, it can feel much less obvious.
A designer wants to know how to set up a project file correctly. A developer wants to check whether the component they are about to build already exists. A product manager has user complaints and no clear way to measure the experience. A team with no designer at all does not know what kind of help to ask for, or who to ask.
Sending any of those people a list of services is a technically complete answer that solves very little. Somebody still has to translate “this screen feels wrong” into “you need the design system team, and here is the person to talk to.”
That translation became the local job.
What we built
We opened a UX Live Center at the India site: a visible space with a service desk, a weekly walk-in slot, design critique, consultation, and a bookable room for workshops and collaboration.
The physical part mattered more than I expected. A room makes the function visible in a way an intranet page never can. People walk past it. They see other teams using it. They ask what it is.
But the room on its own would have been a showroom. What made it useful was the rhythm around it: a predictable time every week, recurring Knowledge Cafe sessions, hands-on workshops, and one accountable local lead making sure questions turned into follow-up.
The local hub did not replace global DesignOps services. It gave teams a front door for intake, consultation, enablement, delivery support, and feedback back to global owners.
FIG. 1 - PUBLIC-SAFE OPERATING MODEL RECONSTRUCTION
What people actually asked for
The most useful thing the centre produced was not a perfect launch plan. It was a clearer picture of what teams were actually asking for.
Density, our design system, was the most requested topic by a wide margin. After that came design-to-code AI workflows, then Figma administration and access questions. We also saw a steady stream of teams that had just hired their first two or three designers and needed help setting up a design function at all.
Over time, sessions reached roughly two thousand colleagues at a site of about twenty-four hundred. Knowledge Cafe sessions became a regular way for dozens of people at a time to learn what support existed, ask practical questions, and bring back the patterns that were slowing them down.
None of that demand was visible on a roadmap before people had somewhere to turn up. If a central function cannot say what the organisation asks for most often, it does not yet have a local presence. It has a distribution list.
The part that gets skipped
A local lead who answers the same question forty times has learned something the central team needs to know.
The temptation is to keep answering it. You are helpful, people are grateful, and the queue keeps moving. But if the same question keeps coming back, the issue is no longer only local support. It is a documentation gap, an onboarding gap, or a service that assumes context the team does not have.
So we sent the patterns back. Recurring confusion about a component, onboarding that did not fit a new hub, guidance that assumed too much internal knowledge, and questions that kept appearing across teams. That feedback loop is easy to miss because it does not show up cleanly in attendance numbers, but it is the part that helps the global service improve.
If you are setting one up
Pick one front door and name it. Not four channels, not a buried page, not a vague promise that anyone can ask for help. One place, one owner, one predictable time.
Answer three questions without effort. Where do I start, who will respond, and what kind of help can I expect? If any of those needs an insider to explain it, the door is only open to people who already know you.
Start with a small number of genuinely useful things. Trust arrives from one review that unblocks a decision, not from a campaign. A young site needs onboarding, access, consultation, and design-system support long before it needs the full advanced-service menu.
Do not fork the standard. Change how people meet it: local examples, sessions in a timezone people can attend, and hands-on setup help. The source of truth stays central.
Track what people ask. Capture categories, frequency, and which parts of the organisation never appear at all. That last one is often the most useful signal, because absence can mean the people who need the service most still do not know it exists.
Where this leaves central teams
A global service can be excellent and still be invisible. The measure of a local DesignOps presence is not how faithfully it repeats the central catalogue. It is whether a product team can find help, use the standard, and make a better decision without first having to understand how DesignOps is organised.
That takes a visible place, a reliable schedule, and somebody whose job is to notice what keeps getting lost between the centre and the teams.