Stop Adding AI to the Design Process. Re-engineer It.

Most teams are asking where AI fits into the workflow they have. The better question is what workflow is possible now.

Last time I argued that seven AI-native designers don’t make an AI-native team. Each person gets faster, the coordination around them doesn’t move, and the team ends up more fragmented than it started.

The reason I’m continuing to write about how a design team can become AI-native is I feel like too many teams including mine have given designers the tools and let them tinker and share but this becomes about individual skill building. But how do we bring the whole team is what I’m continuing to ask myself and what I’d like to bring to my next team.

The obvious response is to standardize. Put AI into every stage of the process you already run. An LLM for research synthesis. Figma Make for concepts. Claude Code or Cursor for prototypes. Figma wired to the codebase for handoff.

Every one of those is a real improvement. Together they still leave you with the same process you had before, running slightly faster.

The design process most of us run was built for a world where making things was expensive. Research, synthesis, requirements, Figma, prototype, review, handoff, build, QA. Each function produces an artifact and passes it to the next one. Product writes requirements, design interprets them, engineering interprets the design, QA interprets the implementation. Every handoff is a translation, and every translation loses something.

We are now automating the boxes and leaving the arrows between them exactly as they were.

AI amplifies whatever your organization already is

DORA’s research on AI-assisted software development lands on something design leaders should sit with. AI works as an amplifier. It magnifies strong organizational capability, and it magnifies dysfunction just as efficiently. Individual gains get swallowed downstream in testing, security review, deployment, and rework.

Design has exactly this problem and mostly refuses to look at it. A coded prototype produced in two hours is not a gain if engineering spends two days finding out it uses the wrong components, ignores half the states, and can’t survive contact with the real architecture. The first artifact arrived faster. The product didn’t.

I’d go further. If your handoffs were unclear before AI, they are now unclear at higher volume. If design and engineering disagreed about what a prototype means, you now have that disagreement four times a week instead of once a sprint. Fragmentation isn’t a side effect of moving fast. It’s the old dysfunction, amplified.

Map the workflow you actually have

Design Workflow Re-engineering doesn’t start with tools. It starts with mapping how one real piece of work travels from a customer problem to production. Not the process on the slide. The one people actually follow, including the parts nobody documents.

Where does work sit waiting. Where does information get recreated because someone couldn’t find it. Where does engineering reverse-engineer design intent from a file. Which decisions take five people because nobody owns them. What knowledge is trapped in a Slack thread, a meeting nobody recorded, or one designer’s personal prompt library.

Then go through it activity by activity and ask what should be eliminated, what’s structured enough to automate, what AI can make better without owning, and what should move to a different role entirely. The point isn’t to attach a tool to every step. It’s to find the steps that should disappear, merge, move earlier, or produce something completely different than they do today.

Most teams skip this because it’s unglamorous and it surfaces things people would rather not say out loud. That’s exactly why it works.

Learn by building, together, on something real

Atlassian ran an AI Builders Week in 2026 where 1,400 designers and product managers stopped theorizing and built. Thirty-one sessions, more than 100 presenters and mentors, and 96% of participants rated it positively. Later rounds moved past foundational skills into actual workflow changes with measurable impact.

The number that matters there isn’t 1,400. It’s that people worked on real problems, with protected time, alongside people who could help them, with permission to fail. Four days doesn’t transform an organization. It does surface which new ways of working are worth keeping.

That’s the model I’d use, scaled down. Not a mandate. One bounded, cross-functional pilot on a real project with genuine customer value, manageable risk, a reasonably mature slice of the design system, and product and engineering partners who actually want to work differently.

And write the hypothesis down before you start. Something like: working from a shared, system-aligned coded prototype, we can reach customer learning earlier and cut implementation rework without increasing review burden or defects.

That’s an experiment. “Everyone should be using Cursor this quarter” is a press release.

Stop pretending every coded artifact is the same thing

Here’s the fight I keep seeing between design and engineering, and it’s almost always a vocabulary problem. A designer hands over something built in Cursor. Engineering doesn’t know whether it’s a sketch, a proposal, or something they’re expected to ship. So they either dismiss it or waste two days evaluating it as production code. Both outcomes are expensive.

A designer on my team built a prototype in two days and sent it to engineering as a way of saying, “Here’s what I mean.” They treated it as an implementation proposal and spent a week reviewing architecture, components, and state handling. She meant a sketch; they received a spec. The problem wasn’t the code. It was that we had no shared language for what the code was supposed to be.

Designers are producing code now. Almost nobody has agreed on what any of it is for. I’d name five levels and make the team use them out loud:

1. Thinking artifact. Disposable. Built to explore an idea, thrown away after.

2. Experiential prototype. Realistic enough for a customer or the team to learn something from the interaction.

3. System-aligned prototype. Built with the real components, tokens, patterns, and accessibility expectations.

4. Engineering-ready artifact. Runs in the real environment, handles the important states, and gives engineering a credible starting point.

5. Production contribution. Meets the same architecture, testing, security, accessibility, performance, and review bar as any other code.

Nobody needs every designer operating at level five. What a team needs is to stop guessing which level they’re looking at. Say the number when you hand something over and most of the friction disappears.

Levels three and four are where this gets hard, and they depend entirely on how mature your design system is. Connecting an inconsistent design system to an agent doesn’t fix the system. It reproduces the inconsistency faster, at scale, in production. That problem is big enough that it gets its own piece next time.

Measure the workflow, not the person

Most teams measuring AI’s impact are measuring the wrong unit. They track whether individual designers feel faster, which is the one number almost guaranteed to mislead them. In a 2025 randomized study, METR found experienced open-source developers using early-2025 AI tools took 19% longer on tasks while believing they’d been made faster. Newer tools have improved and results vary by task and person, but the finding worth keeping is the gap between perceived and actual speed.

Set that next to the Harvard research I cited last time, where consultants using GPT-4 finished 25% faster inside the model’s capabilities and got worse outside them. Both are true. Individual acceleration is real, inconsistent, task-dependent, and largely invisible to the person experiencing it. Which is the whole argument for measuring the workflow instead of the designer.

So measure the things that survive contact with reality. Did we get to customer evidence sooner. Did review time drop. Did engineering rework go down. Did quality improve. What did the tools cost. What did the team learn that it can use again next quarter.

Speed inside one box has never been the metric.

The output of the pilot is the system you’re left with

You don’t need a consultancy and a hundred-slide transformation plan. Start with one project. Pair the advanced adopters with the people still finding their footing. Get engineering in before the prototype hardens. Run workflow reviews instead of tool demos. Write down the prompts that failed, the context that was missing, the corrections you kept making, and the decisions that still needed a human.

Then keep what worked.

Vercel has started treating accepted product decisions the way it treats code. Their agents can reach product judgment, interface quality guidance, interaction patterns, examples, lint rules, and evaluations that live alongside the product. People still decide which lessons become standards.

That’s the real deliverable. Not the feature. The system you’re left holding afterward: a shared process, better design system coverage, clearer decision rights, reusable context for agents, known failure patterns, explicit quality gates, and an actual agreement about what design owes engineering.

Re-engineering the process doesn’t write designers out of it. It clears away inherited work so they can concentrate on the parts that still require them. Understanding customers. Framing the right problem. Making consequential calls. Deciding what good looks like.

Stop asking where AI fits into your design process.

Ask what design process is possible now that it exists.

---

See the deck version of this article: https://speakerdeck.com/lanceshields/stop-adding-ai-to-the-design-process-re-engineer-it