The situation
Across the industry, designers were being asked to adapt to AI across research, handoff, prototyping, and implementation. For many, the shift did not feel like an exciting new tool. It felt like another major change they were suddenly expected to absorb.
Inside BMW DesignOps, we already had useful pieces for that shift: a design-system MCP, IDE setup guidance, reusable skills, agents, a Figma starter file, and training material. The work was valuable, but it was scattered across teams, tools, and moments.
That was the real problem. The capability existed, but it had no clear shape. Designers could not easily see where to start, how the pieces connected, or what adopting this new way of working would actually require.
I proposed this as a change management campaign, not a tool release
The default move would have been simple: publish the assets, announce them, run a session, and call it enablement.
I proposed AI4UX as a change management programme instead. The goal was not just to make AI tools available. It was to help a global design community move toward a new way of working, with the tooling as one part of the system rather than the whole story.
That distinction changed what we needed to build. A tool release needs documentation. A change programme needs a reason to care, a first step that feels safe, a visible path to competence, support when people get stuck, and reinforcement long enough for the behaviour to hold.
Change programmes are slower and harder to prove early. A launch gives you a date and a number. A campaign asks you to wait for behaviour, not just attendance.
How I shaped the campaign
To make the programme actionable, I mapped AI4UX against the ADKAR model: Awareness, Desire, Knowledge, Ability, and Reinforcement. That gave the campaign a progression instead of a single launch moment.
AI4UX was shaped as a campaign over time, moving from awareness and curiosity into learning, practice, and reinforcement.
Each phase had a different job. First, make the change visible. Then make the offering understandable. Then help designers build capability through structured learning tracks. Finally, reinforce the behaviour through recurring enablement so the programme did not disappear after launch week.
Our top priority: making the offering real
Before designers could change how they worked, they needed something real to work with. The first priority was to bring the practical pieces together: reusable skills, agents, the Designers Playground repository, IDE setup guidance, and access to GitHub Copilot.
This mattered because AI enablement can stay abstract very easily. Designers can attend a session, nod along, and still have no safe place to try the workflow on Monday morning. AI4UX had to remove that first layer of friction: access, setup, confidence, and a clear starting point.
The first release made the programme tangible: access, reusable skills, agents, setup guidance, and a safe place to practise.
Skills, Agents & Playground Repo
The offering had three practical layers: reusable skills for common UX tasks, agents to guide AI-assisted work, and a safe repository where designers could practise before using these workflows in real projects.
The AI4UX offering connected skills, agents, setup guidance, and the Designers Playground into one support structure.
Designers Playground Repo
- The Designers Playground gave designers a safe place to practise inside an IDE before using AI workflows in real project work.
The Agent
- UX Buddy acted as the agent layer: a guided assistant that could work across multiple skills and help designers decide what to use, what context to provide, and how to evaluate the output.
The Skills
- The skills turned common UX and DesignOps tasks into repeatable AI workflows, including accessibility audits, UX reviews, usability testing, feedback analysis, UX writing, design-system checks, AI interaction patterns, and Figma workflows.
Together, these pieces made AI4UX tangible: designers had access, workflows to start from, an assistant to guide them, and a safe environment to practise.
Use cases came before features
The fastest way to lose a designer is to hand them a capability and make them work out what it is for.
So AI4UX led with use cases: recognisable moments in a designer’s week where AI could help. The goal was not, “Here are some skills and agents.” The goal was, “Here is how this helps you write a clearer brief, structure messy research, check accessibility, prepare handoff, or review the quality of your own output.”
The first use cases focused on practical design work
- Turning rough notes into structured UX briefs, specs, summaries, and decision logs
- Synthesising research notes into themes and first-draft insights
- Running UX reviews, heuristic checks, accessibility checks, and design-system reviews
- Supporting product discovery with problem statements, assumptions, user needs, and opportunity areas
- Preparing handoff material, design rationale, prototype logic, and reusable workflow instructions
Moving from AI curiosity to AI-enabled UX work.
That framing mattered. It made AI4UX feel less like a new technical layer and more like support for work designers already recognised.
The three tracks are a change ladder, not a difficulty rating
Beginner, intermediate, and advanced read as a skill scale. That is not what they are. Each level is what has to be true before the next one can work — and, in change terms, how far a person has actually moved.
The learning structure became three connected tracks: AI4UX Starter, AI4UX Practitioner, and AI4UX Builders. Each track had a different job in the adoption journey.
The tracks were designed as a progression: first confidence in the environment, then AI-assisted practice, then reusable workflows that other designers could build on.
Track 1: AI4UX Starter — the environment
- Starter was for designers who were curious about AI but not yet comfortable opening an IDE or trusting an AI workflow. Its job was to reduce setup anxiety, explain the basics, and make the first step feel safe: what AI4UX is, why AI is becoming part of design work, what an IDE is, how to run a first workflow, what not to put into AI, and how to check the output before using it.
Track 2: AI4UX Practitioner — augmentation
- Practitioner was for designers ready to bring AI into real UX work, without turning it into a separate technical discipline. It focused on repeatable workflows for documentation, research synthesis, design-system guidance, product discovery, prototyping, persona-based work, and reviewing AI-generated UX output before it reached a project team.
Track 3: AI4UX Builders — reusable context
- Builders was for advanced designers who could create reusable skills, agents, and team-specific workflows for others to build on. It covered workflow design, project context, MCP basics, testing, quality review, governance, maintenance, and sharing useful workflows back to the community.
- The ordering was the point. You cannot teach agentic workflows to someone who is afraid to open an IDE. And no amount of prompt training replaces an environment that works.
Each rung also has to be small enough that the person standing at the bottom can picture themselves taking it. That is the change-management job as much as the curriculum one.
A sequence asks even experienced practitioners to look at the earlier track, which not everyone enjoys. It also means the most impressive outputs come later, after people have built enough confidence to use them well.
Responsible use sits next to the action, not in an appendix
Security and responsible-use guidance is attached to the step it applies to. The lesson on building repository context also covers what must never go into that context. AI-assisted research covers how participant data is protected. Generated UI carries an accessibility and design-system review.
People make those decisions while working, not while reading policy — and in a change programme, ambiguity about what is allowed is one of the strongest reasons people quietly opt out.
I do not own these policies. I embed guidance from the people who do, which makes the programme dependent on their update cycle and means I keep that distinction visible rather than appearing to speak for them.
WHAT SHIPPED
- A formally approved DesignOps change programme, self-initiated and proposed by me — approved June 2026, launched August 2026
- A SharePoint site as the single destination for offerings, use cases, enablement tracks, resources, and guidance
- Three connected enablement tracks: Starter, Practitioner, and Builders
- Use cases mapped to recognisable moments in design work
- Roughly thirty to forty reusable skills in an internal marketplace; I owned the set, wrote the Figma skills and several others myself, and shaped the rest with the team.
- UX Buddy, an agent offered through the programme
- Existing DesignOps work folded into one programme: the design-system MCP, Designers Playground, and the Figma starter file
- Responsible-use guidance embedded at the point of action, sourced from the policy owners
AI4UX gave the design community a clear place to start, a structured path to build confidence, and a practical foundation for using AI responsibly in design work.
What it changed, what's next and what I'd measure
AI4UX launched in August 2026. The global design community now has one place to go, a defensible answer about where to begin, and a path that does not require designers to already feel confident. That was not true before the programme.
The campaign is now moving from launch into enablement and reinforcement: delivering learning material, supporting setup, and planning recurring sessions, walk-ins, and setup clinics so designers can try the workflows with help nearby.
Next, I would measure the behaviour change behind the launch: who enters the programme, where they stop, whether environment setup completes, whether designers return for a second track, which skills are reused, and whether AI-assisted work appears in real project delivery without increasing review burden or lowering quality.
What I learned
Three things, and the last one is where I got it wrong.
AI adoption is a change problem wearing a tooling costume. The instinct — mine included, early on — is that the gap is access: make the offerings findable and people will use them. Access mattered, but it was not enough. What needed designing was the transition itself.
Resistance rarely announces itself. The Playground workshops taught me this before AI4UX launched. Nobody objected to AI. They simply did not go first. That changes what you build: the first step has to feel safe, the environment has to be clear, and silence cannot be treated as agreement.
I should have built the measurement in before launch, not after. The programme has approval, assets, and a structure. What it does not have is a baseline for confidence or usage before launch, which will make later movement harder to prove. Next time, the baseline goes in first.
None of this is specific to AI. It is what adopting any new way of working costs, and design organisations will be doing a lot of it over the next few years.