By Karim Dhammani
An AI-first design team should be able to explore an idea in the same components and constraints that will shape the finished product.
Puffy’s Head of Design brief makes the stakes clear: improve add-to-cart conversion, reduce concept-to-development handoff time by 40%, and preserve brand consistency and PageSpeed. My view is that this starts with changing what designers create and what they hand over.
1. Put the workflow closer to code
I believe the centre of an AI-first design workflow belongs closer to code: repositories, structured specifications, documentation, implemented components and tests.
A code editor, or IDE, brings those materials into one working environment. Designers can explore an idea, inspect what an agent changed and keep the reasoning alongside the work.
That requires design knowledge to be readable by people and machines. Specifications need clear structure, named states and explicit constraints. Agents should be able to propose updates through reviewable changes. The team needs a maintained record of its decisions that survives beyond a conversation or a design session.
2. Make code the home of high-fidelity design
The reason to move closer to code is practical: designers should be expected and supported to create rapid, working prototypes.
My view is that high-fidelity mock-ups should move out of Figma and into code, generated with our implemented components, design language and brand identity. Figma remains useful for exploration and collaboration. The high-fidelity deliverable should let someone experience the interaction in a browser.
That makes responsive behaviour, content length, loading states and keyboard interaction available for inspection and testing. Designers can put an idea in front of users earlier and work through feasibility with developers while it is still easy to change. The prototype gives engineering something concrete to assess for production readiness.
I have worked on the foundations for this at BMW Group. I originated the Density design-system MCP, defined its retrieval use cases and secured a partner engineering team to build it. We moved from first pitch to deployment in four months; my role was product direction and coordination.
I also proposed and led AI4UX, connecting reusable skills, agents, a practice repository and learning tracks for BMW’s global design community. Expecting designers to work differently means giving them the environment, support and practice to do it.
3. Let the design system connect design and code
A shared design system makes that expectation practical. It gives designers implemented components to prototype with and gives developers access to the design decisions behind them. Designers move closer to code; developers move closer to design.
Through Model Context Protocol (MCP), an assistant can retrieve component guidance, token definitions and approved patterns while working. Pairing that knowledge with design context helps it assemble something grounded in the product’s standards.
The system also needs maintained instructions: component usage, interaction behaviour, brand voice, examples and review criteria. Prompt engineering becomes shared team knowledge. Reusable skills carry that guidance into common tasks.
A generated variant creates a decision for the team: keep it within the experiment, improve an existing component or propose a new shared pattern. Owners, versioning and a design-debt backlog keep those decisions visible. Accessibility, brand and performance checks belong in the workflow around generation.
Design context and system guidance become available where designers and developers use AI. People still review the resulting work.
4. Change the handoff, not just the tools
The handoff should become a working prototype with a maintained specification and documented feasibility decisions.
Design and engineering should assess feasibility during prototyping: component fit, data dependencies, responsive behaviour, accessibility and performance. That makes the discussion specific enough to change the design before the team commits to a build.
For a Puffy product-page experiment, I would start with one hypothesis: clearer comparisons between mattress models could help shoppers choose. A short kickoff with Growth and engineering would establish the customer question, approved product facts, constraints and measurement plan.
The designer would explore the module in code using shared components. Developers would help assess what can carry forward, what needs integration and what remains experimental. The handoff would contain three connected artifacts:
Working prototype
The interaction, responsive behaviour and important states, with simulated data identified.
Living design specification
User intent, component references, content rules, behaviour, acceptance criteria and analytics events.
Feasibility and review record
Agreed technical constraints, open questions, AI review findings, human decisions and ownership.
The specification should be clear enough for a person to understand and structured enough for an agent to use. Keep it versioned with the prototype and update both when decisions change. Existing Figma references and Dev Mode details can remain linked wherever they add context.
This is also a DesignOps responsibility: establish the shared brief, mentor designers through the workflow and reserve capacity to maintain the system and documentation.
5. Build a community that learns and shares
I want every designer to become the person colleagues turn to for a particular part of the domain. In ecommerce, that could be product comparison, checkout behaviour or how delivery and returns shape customer trust.
I would build a personal learning roadmap with each team member: choose a focused topic, connect it to live customer problems, identify opportunities to learn and practise, and protect time to develop expertise. Over time, they should become a trusted subject matter expert whose knowledge improves the team’s decisions.
That expertise should travel. I would establish recurring sessions where designers share findings, demonstrate an approach and discuss what did not work—with the team and the wider organisation. Shared notes and examples would make those lessons available to colleagues who could not attend.
Nobody can keep up with every change alone. A culture of camaraderie, curiosity and generous knowledge sharing gives the team more ways to learn. The leader’s job is to make room for that exchange and help people apply what they learn together.
6. Measure what reaches customers
Puffy’s 40% target concerns handoff time. I would baseline that measure alongside concept-to-production lead time, rework, review queues and defects. Sending a prototype earlier only helps if the team can move it forward.
For the product-page experiment, Growth and design would agree on the test and assess add-to-cart behaviour alongside downstream purchases and quality signals. Brand consistency, accessibility and PageSpeed remain part of the release decision.
I would reinvest some of the time recovered in research and usability testing, so faster prototyping leads to better understanding of customers.
The design system becomes the control layer when it helps teams carry decisions from exploration into implementation. My aim as a design leader is to give designers the means to prototype in code, make their intent usable by engineers and agents, and build a community that keeps learning from customers and each other.