Transforming how my design team works and delivers impact

I saw an opportunity bigger than making design faster

I kept seeing the same friction in product development. Designers would spend significant time developing detailed solutions, only for a leadership conversation to reveal that the problem or a key assumption wasn't aligned. The next round of work wasn't refinement. It was often a rethink.

Important experience details also got lost between Figma and production, while decisions waited on separate review forums. I knew faster prototype generation could help, but it wasn't going to resolve the larger issues in how the team worked.

I decided to pursue two changes in parallel: remove friction from our existing processes, and help designers develop the skills and practices for a very different future.

Changing how decisions get made

I separated product strategy reviews from experience reviews. I wanted us to discuss the problem, opportunity, and assumptions before designers invested in detailed solutions. That gave experience reviews a clearer purpose and reduced the risk of discovering fundamental disagreements after weeks of work.

I also clarified which decisions smaller initiatives could make within their own teams, without another leadership approval. These changes weren't about AI tooling. They were about giving people the alignment and autonomy to make progress.

To make that change tangible, I introduced a clearer language for the kinds of design work we were reviewing, the level of fidelity each stage called for, and the type of feedback each review should produce.

Click a visual to expand

The range of designs we can produce

A clearer vocabulary for what kind of artifact the team is looking at.

Match fidelity to the question

Making it explicit when the team is exploring, aligning, or preparing to build.

Tailor reviews to the work

Helping reviewers respond to the question on the table, not the polish of the artifact.

Those changes helped teams move forward sooner. More importantly, they gave designers a better structure for using their judgment and gave AI a more useful place to contribute, because faster execution only matters when the question, the stage of thinking, and the decision-maker are clear.

Helping the team learn an unfamiliar way of working

A Staff Designer on my team led much of the early technical experimentation. He developed a way to turn existing Figma designs into high-fidelity functional prototypes using agent instructions, before there were production-ready components to build with. I directed where we invested, connected his work to our broader design-to-code efforts, and helped turn an emerging technique into a capability the whole team could use.

I didn't want adoption to depend on everyone independently figuring out prompts and tools. Designers were starting from very different levels of comfort, and I knew it would take more than a tutorial to help people change how they worked. I made time for the more experienced designers to share what they were trying, ran hands-on workshops where others could follow the workflow in their own projects, and supported designers as they learned through practice.

I then made functional prototypes a normal part of critiques, 1:1s, and experience reviews. That gave designers a regular place to get feedback on both their product thinking and their new process, instead of treating AI as a separate initiative they had to learn on the side.

On the tooling side, I connected the experimentation to our broader design systems work and encouraged direct collaboration with that team. The effort started with usage guidance for the 12 components most frequently used in the Shopper app, giving agents a more reliable foundation.

Every designer on my team now uses AI to create artifacts that communicate experience intent. What began with a few people experimenting has become part of how the team explores ideas, shares feedback, and learns from one another.

A pilot changed what I pushed us to solve next

Once high-fidelity prototyping became more accessible, I supported a cross-functional pilot to test whether faster tools could also accelerate the whole development process. The goal was ambitious: compress a checkout feature that would normally take three to four weeks into one, while accounting for the different checkout requirements of two retailers.

The team developed a solution, but the experiment surfaced three problems the tools couldn't solve on their own:

• Two important experience scenarios were missing from the initial inputs, which created rework.
• Agents lacked enough product and engineering context to handle parts of the implementation correctly.
• Existing approval steps still slowed the work, even when individual activities moved faster.

I used those findings to redirect the conversation. Rather than concentrating only on better prototypes, I pushed for clearer problem framing, richer product and engineering context, and more intentional decision-making. The pilot didn't prove we could ship everything in a week. It showed me what else had to change before that kind of acceleration could be real.

Making the new role of the designer real

I've been coaching designers to take a more active role in directing experiences as AI handles more of the initial generation. In practice, that means learning to look past the first result, ask for meaningfully different approaches, identify the assumptions an agent has made, and use working prototypes to test interactions earlier.

There's a human adjustment here, too. Designers have spent years building expertise in particular tools and ways of producing work. I try to make the shift feel like an opportunity to use more of their judgment and creativity, not a demand to abandon the skills that made them good designers in the first place. That takes patience, examples, feedback, and room to try things that don't work the first time.

In parallel, I've partnered with my Staff Designer on experiments to capture the reasoning behind decisions. In one comparison, richer user context, experience intent, and design rationale improved the quality of generated prototypes. That reinforced my view that agents need more than a visual design system.

I've introduced experience brief templates that put the problem, rationale, and key decisions alongside the prototype. I'm still exploring how to capture that knowledge naturally as the work happens, without creating a second documentation burden. I've also been taking these lessons into broader design-organization conversations about systems, AI-enabled development, and evolving responsibilities.

My point of view: AI should expand the team, not replace the craft.

I think of AI as part of the team. Used well, it enables scale, clarifies design intent, unlocks more human capacity for judgment and direction, and amplifies the range of possibilities we can explore. The goal is not to turn designers into prompt operators. It's to help them spend more time on the parts of the work that most benefit from human perspective.

Start with the foundation, but don't confuse it with the transformation.

Making a design system useful to agents is a tangible first step. There's real work involved, but it's also the most knowable part of the transition. I think of that foundation as a few connected layers, each giving agents a different kind of understanding of the product.

The first three layers help agents make things that look and behave like the product. The last one starts to explain why those experiences were designed that way. An interface can be perfectly consistent with the design system and still be entirely wrong for the customer.

I'm particularly interested in capturing this knowledge as part of doing the work. A brief that lives with a functional prototype, an AI-assisted summary of a decision that a person validates, or a lightweight record of what we tested and learned can help the team align now and give agents useful context later. None of that works if it turns designers into full-time documentation writers.

The real opportunity is to change the development loop.

Most product teams still have a fairly familiar rhythm: Product defines the requirements, Design develops the screens, Engineering builds them, and everyone works through the differences. AI can shorten parts of that sequence. If the handoffs and approval gates stay where they are, though, there's a limit to how much faster the team can really move.

What interests me is having Product, Design, and Engineering start with a shared understanding of the problem, then work around an evolving, functional experience much earlier.

In that model, agents can help the team create working alternatives from real design and code context. Designers can explore behavior and validate it with users while engineers weigh in on feasibility and Product helps shape the tradeoffs. The work moves forward through more frequent, smaller decisions rather than separate rounds of artifact approval.

Engineering still owns production architecture, reliability, and implementation quality. Design should stay involved through the build, because the experience people use is the thing we're responsible for improving. I'd expect more of our time to move toward problem framing and learning, and less toward manually building every screen or reconciling handoff differences.

The point is getting to a validated, high-quality product sooner. Faster output is only useful if it helps us get there.

Designers need to become better at directing, not just creating.

This is the part of the transformation I'm most interested in. As agents become more capable of creating states, screens, and working prototypes, designers have an opportunity to spend more time steering what those experiences should be.

By directing, I mean having a point of view and knowing what to do with it. A designer might push an agent to explore genuinely different approaches, recognize that a technically correct pattern misses something important about the user, or refine a subtle interaction until it works in practice. The skill isn't writing a better prompt. It's understanding the problem well enough to steer the work, make tradeoffs, and learn from what happens when people try it.

I don't want this to mean designers stop designing with their hands. There's a kind of creative discovery that happens when you're sketching, moving pixels, or following an idea that seems a little strange at first. I'd hate to lose that because we're spending all our time evaluating what an agent happens to generate. AI should expand the space we can explore, not define the edges of it.

The operating model has to catch up.

You can have a beautifully documented design system, convincing functional prototypes, and designers who are fluent with AI, and still have a painfully slow product development process. A team that hasn't agreed on the problem will generate the wrong ideas faster. A team that still waits for multiple layers of approval will keep waiting, even if the work in between happens in hours.

That's why I think the everyday operating questions matter as much as the technology. What actually needs agreement before the team starts exploring? Which decisions can a team make on its own? When do Product, Design, and Engineering need to look at a working experience together? And how do we keep track of the decisions that matter without creating a second job documenting them?

Those answers change review forums, responsibilities, and the moments where people collaborate. They also change what we measure. I'd want to know whether we're reaching better decisions earlier, reducing rework, learning from users sooner, and improving the quality of what ships. Prototype speed is one signal, but it's far from the whole story.

These are less visible changes than a new AI workflow demo. I think they're also what will determine whether AI really helps teams build better products. And design leaders have a meaningful role to play because influencing how people make product decisions has always been part of the job.