Remember slicing PSDs?

If you've been in this industry long enough, you remember. You'd design an entire page in Photoshop - every element, every state, every hover effect - as a flat image. Then you'd slice it into pieces. Export those pieces as image assets in three sizes: small, medium, large. Maybe more if you were ambitious about form factors. Package them with a style guide document - a PDF, sometimes a hundred pages - that specified every font size, every hex code, every pixel of padding.

Then you'd hand it all over to a developer. And pray.

That was the handoff. One direction. One moment. Everything you'd spent weeks on, compressed into a zip file and thrown over the wall.

If it sounds like that was decades ago, it's because the pace of change since then has been relentless. But it was really only about ten to twelve years ago. We went from that - from "here are your image assets and a style guide, good luck" - to a world where a designer builds in Figma, switches on Dev Mode, and a developer pulls production-ready code snippets in real time. Where AI editors like Cursor and Claude Code read the design file via MCP, generate a first-pass React component using the team's existing conventions, and a working prototype exists minutes after the design is finalised.

The wall is gone. The zip file is gone. The hundred-page PDF is gone.

But here's what I want to talk about: in the rush to celebrate how far the tools have come, we've stopped paying attention to what must never change. The principles underneath the tools - the things that made a handoff good in 2014 and still make it good in 2026, regardless of whether you're exporting assets or shipping code.

And despite what you'd expect, the problem hasn't gone away. Figma's 2025 Designer and Developer Trends report found that 92% of designers and 91% of developers say the handoff process still needs improvement [1]. The tools got dramatically better. The friction didn't. That should tell you something about where the real problem lives.

A Brief History of Getting Designs to Developers

Era 1: The PSD and the Prayer (2008–2014)

Photoshop was the tool. Designers created static compositions at specific screen sizes. Converting a design to code was called "slicing a PSD" - and it was the developer's responsibility, which was frustrating because developers didn't want to work with design tools [2]. The gap was filled with redline documents - annotated screenshots showing measurements, colours, and spacing - that were outdated the moment anything changed.

Era 2: Inspect Tools and the Spec Layer (2014–2019)

Sketch replaced Photoshop. Zeplin, InVision Inspect, and Avocode let developers inspect design files directly for the first time - pulling measurements and CSS without reading a PDF. Revolutionary at the time. But the model was still fundamentally sequential: design happens, then development happens. Zeplin made the one-time handoff cleaner. It didn't change the underlying dynamic.

Era 3: Real-Time Collaboration and Dev Mode (2019–2024)

Figma changed the game through its collaboration model. Designers and developers worked in the same file. When Dev Mode launched in 2023, the handoff became a toggle, not a ceremony. But a new problem emerged: the same real-time access that eliminated the wall also eliminated the clarity of "this is final." The question of "what's done?" became harder to answer than ever.

Era 4: AI-Mediated Continuous Delivery (2025–Present)

Two shifts broke the old model entirely. Code Connect mapped design components directly to production code - the gap between design and code stopped being a translation problem and started being a routing problem. Then AI editors integrated with design files via MCP, letting agents read Figma files, generate first-pass components using the team's existing conventions, and write back to the canvas using the actual design system [3]. The handoff isn't a moment anymore. It's a continuous stream.

Code on a laptop screen representing the evolution from static design files to production code as a design deliverable

"The Handoff Is Dead" - And Why That's Only Half Right

Before I defend the principles that endure, let me acknowledge the strongest version of the opposing argument.

There's a serious conversation happening right now about whether the handoff - and the principles attached to it - has become obsolete. Jonathan Ezell argued in March 2026 that MCP and Claude Code have eliminated the thirty-year translation problem between designers and developers overnight [4]. MindStudio went further, claiming that tools like Claude Design and Google Stitch make the mockup itself obsolete - the prototype becomes the product [5]. And Thamizh Elango made perhaps the most provocative case: that developers with AI tools are now shipping production-grade interfaces faster than designers can open Figma [6].

These arguments are not wrong about the execution layer. AI genuinely can translate a well-structured Figma file into production code faster and more accurately than a manual handoff. The translation problem - pixels to code - is being solved.

But they're conflating the translation with the thinking.

Luke Wroblewski documented this precisely in 2026: an AI-assisted project achieved 85% fidelity after the first code pass, but 5 out of 30–40 pull requests still needed a human to catch them [7]. That 15% isn't a rounding error. It's the difference between a product that works and one that looks like it works. As one observer noted: "The quality gate function still exists. It just needs to move upstream. Not 'review before ship' - that window is gone. The new window is before anyone opens a tool" [7].

The handoff-is-dead crowd is right that the ceremony is dying. They're wrong that the principles are dying with it. The principles don't disappear - they migrate upstream. They move from "how we document after design" to "how we think during design."

NNGroup's State of UX 2026 was direct about this: "If you're just slapping together components from a design system, you're already replaceable by AI." The principles I'm about to describe are what make you irreplaceable.

What Remained - And Must Never Change

These principles were true when we were slicing PSDs. They're true now that we're shipping AI-generated components. If you abandon them because the tools feel magical, you'll discover - painfully, during a production incident or a stakeholder review - that no tool compensates for missing fundamentals.

The thinking behind the design must be communicated, not just the design itself.

Whether you're handing off through a prototype, a flowchart, an annotated Figma file, or a data comprehension model - the person receiving your work needs to understand your reasoning about interactions, content decisions, and state changes. Not just what the screen looks like, but why it looks that way. What happens when the API fails. What the empty state communicates. What the loading state should feel like.

Figma's survey found that the top handoff challenges are differences in assumptions (52% of developers) and differences in priorities (63% of designers) [1]. Both are failures of communicated intent, not failures of tooling. Auto-layout and Dev Mode give developers the what with unprecedented accuracy. But the why- the intention behind the design - still requires a human designer to articulate it. If you don't, the developer makes assumptions. And assumptions are where quality dies.

This is one of those core design skills that AI can't replace - the ability to not just produce a design, but to explain the thinking underneath it in a way that survives the translation into code. We explored what this kind of irreplaceable judgment looks like in AI Will Change Everything About Design. Except the Part That Actually Matters.

Standardisation must be versioned, verified, and intentional.

Every component pulled from a design system, every token applied, every pattern reused - these need to be versioned and verified before they enter the delivery stream. Not generated on the fly. Not "whatever the latest version is." Explicitly checked, explicitly documented, explicitly marked as ready.

And verification matters more in an AI-mediated workflow, not less. If your Figma file has sloppy auto-layout, missing variables, and no Code Connect mappings, the AI will faithfully reproduce that sloppiness in production code - at scale, in minutes. The speed of AI-mediated handoffs makes errors propagate faster, which means the discipline of verification must be even more rigorous than it was in the Zeplin era.

Brand, theme, and vision must be coherent across every artefact.

When handoffs were slow and ceremonial, there was a natural checkpoint: someone reviewed the full set of deliverables before they crossed the wall. Now that delivery is continuous, coherence becomes something you must actively protect.

The colour system, the typography hierarchy, the interaction patterns, the voice and tone - these need to be documented and distributed so that every contributor can access and verify against them. Not as a static PDF that nobody reads, but as a living system referenced at the point of creation. We explored what this living system should look like for modern design teams in What Should a Design Team Look Like in 2026? - the coherence challenge is structural, not individual.

A designer working on a structured design system with components and tokens, representing the discipline of versioned, verified standardisation

Master layouts must be rigorously evaluated.

Before a layout ships - before it enters the continuous delivery stream - it should pass a critical evaluation. Can it accommodate the realistic range of content variations? Does it degrade gracefully at different breakpoints? Has it been tested for usability, not just visual consistency?

Auto-layout makes responsive design feel effortless. And that effortlessness is dangerous - because "it adapts to different screen sizes" is not the same as "it works well at different screen sizes." The former is a technical capability. The latter is a design judgment that requires human evaluation. Dev Mode shows the design at whatever breakpoint is active in the file - if you only designed at 1440px, that's all the developer gets [8]. The tool doesn't compensate for missing design decisions.

Naming, taxonomy, and discoverability must be deliberate.

Every asset, component, page, and token that leaves the design environment must be named so that anyone - not just the designer who created it - can find, understand, and use it six months from now. Designers, developers, product managers, QA engineers, content writers.

A component called "Card_v3_Final_FINAL" is not a handoff. It's a liability. Taxonomy is design work. And in an AI-mediated environment, it's even more critical - because AI agents parse your naming conventions to make routing decisions. Poor taxonomy doesn't just confuse humans anymore. It confuses the machine that's generating production code from your file.

Evaluation frameworks must travel with the design.

The principles you used to evaluate usability. The criteria for structural and detailed design decisions. The standards for accessibility. The testing protocols. These don't live in the designer's head - they need to be explicit, documented, and handed off alongside the design itself.

When a developer asks "is this right?" they should be able to check against the same framework the designer used to make the decision. When QA tests the implementation, they should test against criteria defined during design, not invented during testing. Tools like Dev Mode surface visual specs but don't verify whether the build meets the evaluation criteria the designer intended. That gap is yours to close.

What Changed - And Why It Matters

Now let's look at what's genuinely new. Not just "better tools" - but structural shifts in how design reaches production.

Responsive design is now automated, not manually produced. Auto-layout means you design once and the system adapts. No more exporting three versions at different breakpoints. But the rules you set are the rules the developer inherits - sloppy constraints produce sloppy responsive behaviour at every breakpoint simultaneously.

Code is part of the design deliverable.Your Figma file is now a production input, not just a communication artefact. When the AI-generated code doesn't match your intent, the question is no longer just "did the developer build it wrong?" It's also "did the designer set up the file in a way that generates correct code?"

Concept-to-deliverable timelines have compressed to near-zero. AI generates concept explorations, layout variations, and functional prototypes in minutes. Evaluation - not ideation - has become the primary mode of working. You spend less time creating options and more time judging which option is right. The risk: if you evaluate options you didn't create, you may lack the understanding to judge them well. This is exactly the dynamic we explored in AI Will Change Everything About Design. Except the Part That Actually Matters.

Motion design has become parallel work. Animation is no longer a post-production afterthought constrained by what developers already built. With Figma prototype animations, Rive, and AI-generated motion specs, motion is designed and delivered alongside the static UI - a first-class deliverable in the handoff stream.

Content and writing standards travel with the design. Content strategy - writing style guides, architecture decision records, standard copy patterns for existing and anticipated workflows - is increasingly part of the design deliverable rather than a separate workstream. AI accelerates the structure. The editorial judgment - voice, precision, sensitivity to context - remains human work.

A team reviewing design specifications together on a large screen, representing the shift toward integrated accessibility and collaborative delivery

Accessibility has shifted from afterthought to integrated practice. Accessibility evaluation reports, WCAG compliance checks, and accessibility considerations are now part of the design deliverable - not a separate audit after development. This is one of the most positive shifts in handoff evolution. If you're building AI into your personal design workflow, accessibility evaluation is one of the highest-value applications - it catches issues before a single line of production code is written. We covered how to integrate AI effectively into your design practice in How to Build Your Personal AI Workflow as a Designer.

Design scope has expanded beyond screens.Handoffs now include omnichannel considerations, service design layers, and persuasive design approaches. The deliverable isn't just "here's the app screen." It's "here's how this screen connects to the email sequence, the push notification, the customer support workflow, and the in-store experience."

Analytics and tracking are designed into the delivery. What tags fire, what events are tracked, what data is collected - these are specified during design, not added by engineering after the fact. This closes the loop between "we designed this" and "here's whether it worked." It's also what separates the designers who are getting noticed in the current job market from those who aren't - connecting design decisions to measurable outcomes is no longer optional. We broke down what this looks like in practice in The UX Job Market Has Changed. Your Strategy for Getting Noticed Hasn't.

Starting From Your Next Project

Everything above is useless if it stays theoretical. Here's what to change - not eventually, not next quarter - starting from the next project that lands on your desk.

Before you open Figma

Define what "done" means with your developer.Not what the screen looks like when it's done. What information they need from you to consider the handoff complete. Ask them directly: "What did you wish the last designer had given you that they didn't?" Every developer has an answer to this question. Most have never been asked.

Agree on a naming convention.Before a single component is created, establish how things will be named - pages, frames, components, variants, tokens. Write it down. Share it. This takes twenty minutes and saves weeks of confusion across the project lifecycle. If AI agents will be pulling from your file, this isn't just good practice - it's a production input.

Document your evaluation criteria upfront.What usability principles are you designing against? What accessibility standards must be met? What constitutes "good enough" for this project's timeline and constraints? Write this down before you design anything. It becomes the framework against which the final build is verified - by you, by QA, by the developer, by anyone who touches the project after you.

While you're designing

Annotate intent, not just interaction.Every major design decision should carry a note - not a novel, a sentence or two - explaining why. "This flow uses progressive disclosure because user research showed that showing all options simultaneously increased task abandonment by 40%." That note survives personnel changes, sprint boundaries, and developer rotations. The screen alone does not.

Structure your file as if an AI agent will read it. Because it probably will. That means proper auto-layout with intentional constraints, not quick-fix absolute positioning. Variables and tokens instead of hard-coded values. Code Connect mappings where they exist. Components that are properly named and organised. Think of your Figma file as source code, not a canvas. The quality of what comes out of it depends entirely on what you put in.

Build your accessibility layer in parallel.Don't design the interface and then check accessibility. Design with accessibility criteria active - contrast ratios, keyboard navigation paths, label structures - from the first frame. By the time you're ready to hand off, accessibility isn't a checklist to run. It's already embedded in the deliverable.

Specify your tracking plan alongside your flows. When you design a checkout flow, also define: what events fire at each step, what data is captured, what constitutes a successful completion. Hand this off with the design, not separately. This is what turns your design from a set of screens into a measurable system.

After you hand off

Pair with the developer for the first implementation pass.Not to hover. Not to review. To sit together for an hour and watch how they interpret your file. You'll learn more about the quality of your handoff in that hour than in a dozen retrospectives. Where do they get stuck? Where do they make assumptions? Where does your documentation fail?

Review the build against your evaluation criteria, not against your Figma file.The question isn't "does this look like my design?" The question is "does this meet the usability, accessibility, and interaction standards we defined at the start?" Those are two different reviews, and the second one matters more.

Document what broke and why.After every handoff cycle, spend fifteen minutes writing down what information was missing, what was misunderstood, and what would have prevented the rework. This isn't a retrospective exercise - it's your personal handoff quality system. Over three or four projects, you'll see patterns. Fix the patterns and your handoff quality compounds permanently.

The Bigger Picture

The tools will keep changing. In two years, MCP will look primitive compared to whatever replaces it. Figma itself may be disrupted. AI code generation will get better, faster, more accurate.

None of that changes the fundamentals. The designer's job - in any era, with any tool - is to make sure the right thing gets built, not just that something gets built fast. That requires thinking, communicating, standardising, evaluating, and naming with a level of discipline that no tool automates.

The designers who understand this are the ones who remain valuable regardless of what the tooling landscape does. They're the ones whose handoffs produce fewer surprises, less rework, and better products. They're the ones who - in a market that's cutting design managers who can't demonstrate value - are indispensable. We explored what that market looks like in Design Leadership Is in Turmoil. And No One's Talking About It.

If you're looking to build this kind of discipline into your practice - the kind where your technical skills, your communication, and your strategic thinking work together as a system rather than as isolated capabilities - that's what our mentorship programs are built for. Not tool training. Practice development. Book a strategy calland let's talk about where your practice is strong and where the gaps are costing you.

At Xperience Wave, we've helped 140+ designers build the kind of handoff discipline that produces fewer surprises, less rework, and better products - not through tool training, but through practice development →

Sources & References

[1] Figma. (2025). "State of the Designer 2025: Designer and Developer Trends." 943 respondents across US, Europe, and APAC. https://figmatoazure.com/reports
[2] SitePoint. (2024). "The 5 Best Design Handoff Tools." https://www.sitepoint.com/best-design-handoff-tools/
[3] The Crit. (2026). "The New Design Handoff Is Not a Handoff." https://thecrit.co/resources/design-handoff-is-not-a-handoff
[4] Ezell, J. (2026). "The Design-Dev Handoff Is Dead. Here's What Killed It." Medium. https://medium.com/@jonandrewezell/the-design-dev-handoff-is-dead-heres-what-killed-it-444a43c7be31
[5] MindStudio. (2026). "The Death of the Mockup: How AI Is Collapsing the Design-to-Code Handoff." https://www.mindstudio.ai/blog/death-of-the-mockup-ai-design-to-code
[6] Natarajan, T. (2026). "Death of the Design Handoff: How AI Is Eliminating UX From the SDLC Forever." Medium. https://thamizhelango.medium.com/death-of-the-design-handoff-how-ai-is-eliminating-ux-from-the-sdlc-forever-a92590c980ba
[7] Medov, N. (2026). "AI Killed the Design Handoff. Here's the Cost Nobody Mentioned." Substack. Referencing Luke Wroblewski's project documentation. https://nurxmedov.substack.com/p/ai-killed-the-design-handoff-heres
[8] Pickuma. (2026). "Figma Dev Mode Review: Does Design-to-Developer Handoff Actually Work?" https://pickuma.com/for-dev/figma-dev-mode-design-handoff-review/

About the Author

Shaik Murad is Co-founder and Head of Product & Design at Xperience Wave, a UX design studio based in Bangalore, working across designer mentorship, UX services for businesses, and a design community of 1,000+ designers.

- Murad, Co-founder & Head of Product & Design, Xperience Wave