The starter file was positioned as a practical working default: start faster, collaborate better, stay structured, and be AI-ready.
FIG. 1 - STARTER FILE LAUNCH
The situation
A Figma file is no longer just a place where screens are designed. In a large product organisation, it becomes onboarding material, design-system context, a developer handoff surface, and increasingly, source material for AI-assisted implementation.
BMW Group already had design standards and the Density design system. What designers still needed was a practical default for everyday project files: where to start, how to organise work, what to document, how to prepare for handoff, and how to keep files understandable after the first round of changes.
Without that default, every team could structure work differently. New joiners had to learn file habits from the people around them. Developers had to decode each handoff. AI-assisted tools could only interpret whatever structure, naming, and component usage happened to be present in the file.
The design decision
The useful move was not to create another standards document. The useful move was to put the standard inside the thing designers actually duplicate.
I created a Figma starter file that worked as both a template and a guide. It gave designers a ready-made project structure, but it also explained why each part existed: where to put research, where to explore, where to keep components, how to separate active work from archived work, and how to prepare designs for review and implementation.
The goal was not to police every file. It was to remove setup decisions that nobody should have to make from scratch every time.
What the starter file included
The starter file gave each project a clear information architecture: a cover page for project context, guidelines and resources, AI-ready file practices, project background and research, local components, a playground for exploration, user flows, visual design, prototypes, and an archive.
That structure made the file easier to enter as a new designer, easier to scan as a collaborator, and easier to hand over to development.
The starter file explained its own structure, so designers could understand where work belonged without leaving the file.
FIG. 2 - FILE STRUCTURE GUIDE
The page hierarchy separated guidance, source material, active work, prototypes, and archive so the file stayed navigable as a project evolved.
FIG. 3 - PAGE HIERARCHY
Handoff was built into the workflow
The starter file also included practical handoff guidance for both sides of the workflow.
For designers, the checklist made ready for development more explicit: clear file structure, understandable layers, applied tokens, defined layout behaviour, covered states, export-ready assets, annotations, linked resources, and clean AI-to-code inputs.
For developers, the Dev Mode guidance explained how to inspect the file, follow structured views, check components and variables, track changes, use linked resources, and clarify open questions in context.
This mattered because handoff quality is rarely one big moment. It is the result of many small decisions made before the developer ever opens the file.
Handoff guidance was embedded into the file so designers could check structure, states, assets, annotations, and AI-readiness before marking work ready for development.
FIG. 4 - DESIGNER HANDOFF CHECKLIST
The developer-facing guidance helped partners inspect the design, follow linked resources, track changes, and raise questions without losing context.
FIG. 5 - DEVELOPER DEV MODE GUIDE
Why it mattered for AI
The same structure that helps a person understand a file also helps AI-assisted tools interpret it.
Clear page hierarchy, meaningful frame names, component instances, linked resources, explicit states, and annotations all improve the quality of the source material. They do not guarantee better generated code by themselves, but they reduce ambiguity at the point where an AI workflow starts reading the design.
For me, this was the important shift: AI readiness was not a separate activity. It was part of good design operations.
WHAT SHIPPED
- A standardised BMW Group Figma starter file
- Embedded guidance for file organisation, handoff, and AI readiness
- Dedicated guidance pages for designers and developers
- A reusable structure for research, components, exploration, flows, visual design, prototypes, and archive
- Formal launch to the BMW Group UX community in March 2026
- Adoption into AI4UX as a practical starting point for AI-ready design work
Adoption signal
Roughly 200 designers picked up the starter file after launch, from a global UX community of about 2,000. For an optional internal resource, that was a strong signal that the file was solving a real workflow need.
The next thing I would measure is not just duplication, but retained use: whether teams kept the structure, whether new joiners found it easier to start, whether developers saw cleaner handoffs, and whether AI-assisted implementation worked better from structured files than unstructured ones.
What I learned
Guidance is more likely to survive when it lives where the work begins. By placing structure, handoff expectations, and AI-ready practices inside the starter file itself, the standard became part of the workflow instead of another page people had to remember to read.