There’s a concept I’ve been thinking about for a while: the gap between a designer’s intent and the working thing that eventually ships. Traditionally, this gap is where a lot of design quality gets lost — in handoff, in interpretation, in the distance between a Figma file and production code.
AI-assisted workflows are compressing that gap in ways I’m still trying to fully understand.
The old model
In most teams I’ve worked with, the design handoff process looks something like this:
- Designer produces high-fidelity Figma screens
- Developer receives specs and interprets them
- Something gets built that’s mostly like the design
- Designer reviews, annotates changes
- Repeat until ship
This is not a bad process — but it has inherent loss built in. Every interpretation step introduces drift. And the further a designer is from the code, the less they can course-correct in real time.
What changes with AI
When I built the Passport of Play system at the Museum of Solutions, I used a different approach. Rather than designing everything in Figma and handing off, I was designing and building in parallel — using AI to scaffold functional code from my design intent, then iterating on working prototypes with the floor team.
The result wasn’t just faster. It was qualitatively different. Problems that would normally show up in a QA cycle showed up in the third day of prototyping. Design decisions got tested against real data immediately.
Here’s a rough capture of what the workflow looked like in practice:
(Replace this with an actual screen recording of your workflow)
What this requires from designers
This isn’t a free lunch. To work this way effectively, you need:
- Enough technical literacy to evaluate and correct AI-generated code — not write it from scratch, but read it
- Tolerance for messiness — early prototypes built this way are rough. You have to not be precious about it
- Strong design intent — AI can help you execute, but it can’t supply the “why” behind a decision
The risk is that designers who adopt AI tooling without strong design foundations end up building things faster that are still wrong. Speed amplifies intent — good or bad.
The broader shift
I think this is part of a broader collapse of role boundaries in design. The question isn’t “designer vs developer,” it’s “who can take ownership of the outcome, end to end?”
Designers who can move fluidly between strategy, UX, and working prototypes will be disproportionately valuable — not because they replace engineers, but because they reduce the cost and time of the feedback loop between intent and reality.
That’s the design practice I’m trying to build.
Thoughts? Disagree? Drop me a line →