The situation
Two months earlier we had deployed a design-system MCP. It made BMW's design system queryable from inside an IDE, and it could sit alongside Figma MCP so that design intent and system rules arrived in the same working environment.
The service worked. The access path did not.
Most designers in the community had never opened an IDE. The ones who tried often stopped at the first setup problem: Node was missing, Angular CLI was not installed, Git was not configured, VS Code was not available from the command line, or an error message assumed knowledge they did not have.
Underneath those practical issues was the line I heard repeatedly:
They were afraid of breaking something.
That fear was rational. If nobody has shown you what a terminal command can and cannot damage, every command feels risky. So the barrier to AI-assisted design work was not curiosity or capability. It was a setup process that assumed designers already knew which steps were safe.
I automated the setup instead of documenting it
The default response would have been a guide: install this, check that, run this command, troubleshoot this error.
I built a repository that did the setup instead.
The Designers Playground template included a scripts folder with three plain entry points: first-run setup, setup verification, and new project creation. Each script existed in both shell and PowerShell versions, so the path worked across common designer machines rather than only on one operating system.
The first-run setup checked what was already installed and added missing prerequisites such as Node.js, Angular CLI, and uv. The verification script checked the rest of the working environment: Node, npm, Git configuration, VS Code CLI access, GitHub Copilot, Copilot Chat, Angular CLI, uv, and the MCP server connections designers needed to confirm inside VS Code.
That changed the nature of the first attempt. Instead of asking a designer to interpret eleven separate setup steps, the repository could tell them what was present, what was missing, and what to do next.
Someone who runs a setup script learns less about each individual dependency than someone who installs everything manually. I accepted that tradeoff because the first goal was not to teach terminal literacy. It was to get designers safely into a working environment where learning could start.
The Playground template gave designers three clear scripts: first-run setup, setup verification, and new Angular project creation.
The MCPs are connected before the designer arrives
The environment was designed around a simple rule: if a tool was essential to the workflow, it should not be left as a manual setup task at the end.
The Playground helped designers get to an IDE environment where GitHub Copilot, Figma MCP, and the design-system MCP could be used together. That mattered because the design-system MCP only created value if designers could actually reach it. Asking every designer to configure their own tools would have reintroduced the adoption barrier after they had already done the hardest part.
The new-project script made this more concrete. It checked the local environment, asked for a project name and location, guided the designer through creating or connecting a repository, cloned it, installed dependencies, renamed the project, added the Density design system, opened the result in VS Code, and ended with the command and local URL needed to run the project.
The output was deliberately explicit. Designers could see each step complete: dependencies installed, project renamed, design system added, project opened. That visible progress mattered as much as the automation itself, because it made the process feel recoverable.
The repository used opinionated defaults. It was coupled to a specific toolchain: VS Code, GitHub Copilot, Angular, the design-system boilerplate, and MCP connections. That made onboarding simpler, but it also meant the setup had to change when the toolchain changed.
The scripts showed designers each check and setup step as it completed, then ended with a clear next action.
I went to the developer-experience team rather than inventing conventions
This was a developer-tooling problem wearing a design-enablement costume.
I knew the designer problem: where people hesitated, what felt unsafe, and which moments made someone give up. But I did not want to invent environment conventions from a designer's intuition. The developer-experience team already understood dependency handling, setup failure modes, and the small differences that make scripts behave differently on different machines.
So I built the Playground myself, but I consulted developer experience where the work crossed into their craft: prerequisites, installation flow, verification checks, and the shape of a setup that can fail clearly instead of mysteriously.
The hard part: knowing when not to borrow engineers
On the design-system MCP, I had gone looking for engineering support because the work was a service. It needed real engineering, review, and a deployment path.
The Playground was different. It was a setup routine, and its hardest question was not only technical. It was about confidence: which steps frighten a designer, which errors feel unrecoverable, and what someone needs to see before they believe they cannot break anything important.
That made it a DesignOps problem as much as a tooling problem. I was close enough to the design community to understand the fear barrier, and the build was small enough for me to own directly. I used developer-experience input where I needed it, but kept the shape of the tool grounded in how designers would actually encounter it.
Knowing which work needs engineers and which work needs a practical bridge is part of the job.
WHAT SHIPPED
- A Designers Playground template repository for IDE-based design-system work
- First-run setup scripts for shell and PowerShell
- Verification scripts for Node, npm, Git, VS Code CLI, Copilot, Copilot Chat, Angular CLI, uv, and MCP readiness
- A new-project script that scaffolds an Angular project from the design-system boilerplate
- Guided project creation, dependency installation, design-system setup, and VS Code launch
- Validation through group workshops with designers in Portugal, South Africa, and India
- Release path into the global BMW Group UX community as part of AI4UX
A working default turned IDE setup from a private failure point into a guided path designers could complete, verify, and repeat.
What it changed, and what I'd measure next
I ran the Playground as batch proofs of concept in small group workshops across three regions. At that stage, the question was not whether every future setup would succeed at scale. The question was whether the fear reduced when designers had a guided setup, visible checks, and a clear next step.
The signal was positive. Participants described the IDE environment as approachable rather than difficult, which was the specific change the Playground was built to create.
I want to be precise about that evidence. This was qualitative feedback from facilitated workshops, not long-term adoption data. It was strong enough to justify wider release, but it should not be presented as proof of sustained usage.
On a broader rollout, I would measure setup completion rate, where setup fails, time from clone to first working session, how many designers return to the environment unprompted, and how many use the MCP workflow in real project work. The fear barrier has a measurable signature: people abandon setup and do not come back. That is the behavior worth tracking directly.
What I learned
The blocker was earlier and more mundane than the capability. We had a design-system MCP that could answer questions from inside an IDE, and a community of designers who could not comfortably open one. Training alone would not close that gap. A working default could.
A fear barrier and a skills barrier need different fixes. If people lack knowledge, a tutorial can help. If people are afraid of breaking something, a tutorial is not enough. The system has to show what is safe, check its own state, and give people a way to recover.
Automation is not only about saving time. In this case, the scripts mattered because they moved uncertainty out of the designer's head and into the tool. The setup could check, report, and guide. That made the first attempt feel less like a test of technical confidence and more like a supported start.