Zero-Blocker Delivery: Closing the Design–Engineering Gap

“Gavin wasn’t trying to block the work. He was essentially trying to protect the team from uncertainty.” - Marcus Knight, Head of UX at N26

Most handoff problems do not start when engineering opens the file. They start much earlier, when design decisions are left implicit, edge cases are skipped and “ready for dev” means something different to everyone involved.

In his talk at UXDX EMEA 2026, Marcus Knight, Head of UX at N26, showed how his team moved from tense design handoffs to a clearer, calmer system. It is built around shared standards, earlier feedback and AI-assisted readiness checks.

The engineer who was not really blocking the work

Marcus began with Gavin. Every company has a Gavin. At N26, Gavin was one of the most experienced engineers on the team: sharp, pragmatic and extremely good at finding the exact part of a design that would fall apart in implementation.

At first, their relationship was tense. Marcus would arrive with polished Figma files, carefully specced and ready to be built. Gavin would open the file and immediately start pulling it apart. What happens if the API fails? Is this a library component? What happens when there is no data? What does the loading state look like?

To a designer, that can feel personal. The work looks finished, and the handoff is meant to be the point where engineering builds, not the moment where everything is questioned again.

Over time, though, Marcus realised that Gavin was not the problem. The issue was a broken handoff model.

The handoff trap

The traditional model treats the design file as a finished package. Design completes the work, engineering receives it, and implementation begins. On the surface, this looks like quality control: polished files, documentation and formal reviews.

Underneath, it is fragile. Marcus saw the Figma file as a finished, polished package. Engineering saw it as a set of decisions still to be made. Neither side was wrong, and neither was fully right. The design looked great, but from an implementation point of view it was not complete.

Then came the survey. When Marcus asked leaders across design and engineering organisations, 64% said there was no standardised practice, and nobody could say what standard they were aiming for. After three years of work he thought was going well, he found that shocking.

“We did not have a shared definition of what ready was.”

That is the trap. Without a shared definition of readiness, handoff becomes a negotiation. Every file turns into a conversation, every conversation arrives late and every late question feels like a blocker.

Most blockers are communication gaps

Once Marcus listened more closely to Gavin, a pattern appeared. The so-called blockers were usually not engineering problems. They were communication gaps in the design file itself. The file might have been clear to stakeholders and good enough to sell the concept internally, but it did not always explain behaviour, constraints or failure states.

Gavin’s questions about components, API failures and loading states were product quality questions. They only felt like blockers because they arrived too late.

That drove a mindset shift. Marcus stopped treating the file as a presentation artefact and started treating it as an implementation artefact too. This doesn’t mean designers have to become engineers. It means implementation is part of the process.

“If the file creates uncertainty for engineering, then the design is not done.”

Blocker one: a file that shows what matters

The first blocker was simple, boring and essential: file hygiene. Unnamed frames, duplicated flows and old explorations sitting beside final designs force engineers to dig for the source of truth. That wastes time, and it also creates doubt.

It matters more in companies moving faster with AI, because speed amplifies ambiguity. If a file is messy, the confusion travels faster through the process.

The goal was that when Gavin opened the file, he would know exactly what mattered. N26 made better use of Figma Dev Mode, whose focus view means engineers don’t see the exploratory pages and abandoned directions. The tool helped, but the important part was the standard behind it. Designers needed to know what to mark, and engineers needed to know where to look.

Blocker two: the misery path

The second blocker was missing states. Designers tend to design the happy path, where the data loads, the user does the right thing and the result appears. “But engineering lives in the misery path,” Marcus says, preferring “misery” to “unhappy” because it adds more drama.

What if data is missing? What if there are no results? What if the API fails? What if a button needs to be disabled? These are not annoying edge cases. They determine whether an experience survives contact with reality.

The loop was familiar: design hands over the file, engineering returns with questions, design makes changes. N26 broke it by documenting these decisions directly in the design file, through comments and annotations, instead of in separate slides and spreadsheets. When an engineer has to search across a Figma file, a product requirements deck and a metrics sheet, the handoff has already become fragile.

Blocker three: respecting the system

The third blocker was design system alignment. A design can look right in Figma and still be risky to build. If components are detached, styles are changed manually, or one-off patterns appear without explanation, engineering absorbs the cost.

Those decisions raise obvious questions. Why can’t the existing component solve this? Is the pattern reusable or a one-off? What states does it need? How does it behave? These questions are not bureaucracy. They protect consistency, maintainability and speed.

N26 became stricter about component usage, design tokens and the rationale for anything new. New interaction patterns also had to be demonstrated, not just shown as a static image. For Marcus, that meant a prototype of N26’s virtual card switcher, so the engineer could see exactly what was intended. A static design shows what the product looks like. A prototype helps explain what it means to use it.

Blocker four: feedback before polish

The biggest shift came from changing when engineering feedback happened. Instead of waiting until the file was polished, Marcus brought Gavin in at the point of inception, sometimes with nothing more than “Gavin, I got an idea. Have a look at this.”

He also began bringing what he calls “vibe comps”, very early explorations built with AI. One was a card selector he prompted in Figma Make in about five minutes and took straight to Gavin. Marcus says he’s coining the term.

The point was never approval. The goal, in his words, was “pressure testing”. Gavin could say the interaction looked expensive, the API didn’t support it or it would add complexity, which matters in a regulated industry like banking. Early feedback feels like pressure testing. Late feedback feels like rejection. Because the feedback came earlier, it was useful and less threatening, and Marcus no longer felt his file was under attack.

Dev Mode supports the process, but it is not the process

Dev Mode helped engineers inspect designs, measure spacing, review components and see what was ready. But Marcus was clear that it did not magically fix handoff. One gap was that nothing showed an engineer that a prototype was attached. The team had to recreate a small indicator component and paste it alongside their files, and made it a rule to always include it, so engineers knew what to look for and designers knew what to enable.

“Dev mode is not the process; it supports the process.”

Before a design could move forward, it needed a clear ready-for-dev indicator, clean frame names, documented key states, annotated behaviours, prototype links where available and visible technical constraints.

That created a more objective standard. Gavin was no longer dismantling Marcus’s work. He was checking the file against an agreed definition of readiness. That made critique less personal, and the file easier to trust.

The problem with relying on one Gavin

For a while, it worked. The team had clearer feedback loops, a shared language and fewer surprises, and engineering feedback made the design stronger instead of feeling like a threat.

Then reality returned. Gavin was stretched across several work streams, stressed and short on time. When Marcus kept bringing him rough work early, Gavin pushed back. He didn’t have the capacity, and he asked Marcus to come back when the design was polished.

Marcus’s first reaction was alarm, because it sounded like going back to the handoff trap. Then he accepted that Gavin was right. “I couldn’t rely on stealing hours from him,” he says, and he admits he was being selfish.

When deadlines got tight, the discipline fell apart and the team slipped back into old habits. The improved process depended too much on one relationship. So the question changed. How do you give engineers what they need without them being in every conversation, and protect their time while still getting the feedback that improves the work?

Enter Sheldon

Marcus’s answer was Sheldon, a Claude Code skill named after the Big Bang Theory character and built as a first line of defence before engineering review. As he puts it, “Sheldon does not care if the design is beautiful.” It checks whether a file is understandable enough for an engineer to build from.

To build it, Marcus went back through his Google Chat history with Gavin and pulled out every recurring question: which use cases, which states, which patterns tended to cause uncertainty.

Sheldon turns those concerns into a readiness check. It returns a scorecard, a summary and a verdict at the top. In the example Marcus showed, the verdict was “not ready”, partly because the Dev Mode indicator was off. It can flag an unconnected flow, a missing error state, unclear comments or a missing prototype for a component that isn’t in the design system.

It is a pre-flight check, not a replacement for engineering feedback. The biggest value is not that Sheldon removes every blocker, which Marcus calls unrealistic. It moves blockers earlier.

“Earlier is cheaper. Earlier is a lot, lot calmer. Earlier creates better design.”

File readiness stops being subjective and becomes something designers can check, improve and own before handoff. Marcus says it also made conversations with future engineers, not just Gavin, much easier.

What still isn’t solved

The Q&A pushed on some honest questions. The host raised a fair one: isn’t this mostly just collaboration, which teams already knew they should do? Marcus agreed that it’s nothing new. AI is a multiplier, he said, and he uses it where work drains him, such as analysing a file for missing use cases. He also suggested remote working has blurred the collaboration that once happened naturally, which is why it bears repeating.

AI has limits at a bank, too. N26’s design team has onboarded onto Claude Code, but Marcus doesn’t expect AI-generated work to go straight to production in a banking app, where the team doesn’t want to disturb anyone’s money or balances. For now, AI helps in the development process, not directly in the product. Where it could do more for customers, such as analysing spending behaviour, regulatory and GDPR requirements mean N26 is still working out its approach.

Asked how he built Sheldon, Marcus described a cheeky method: using AI to talk to AI. He had Gemini write a skill prompt for Claude, then brought in ChatGPT to check the wording, and iterated until it worked. It reads his Figma files directly. He hasn’t yet made it sound like Sheldon.

Handoff is part of design

Marcus’s broader point isn’t really about Figma or Claude. It’s about a cultural shift towards a design engineering mindset: a designer who understands the medium and the platform they design for, and who treats implementation as part of the craft. He doesn’t think designers should ship directly to production code, but he does think AI should take on the tedious parts of handoff, such as file hygiene, missing states and broken flows.

The practical advice is simple. Know your engineer, or know your Gavin. If you prefer the AI route, know your Sheldon. Bring engineering in earlier. Design for the misery paths. Make your ready-for-dev standard visible by agreeing what “ready” means with your engineers.

And don’t copy his process wholesale. “There is no one-size-fits-all,” he says, so take the ideas to your engineer and work out your own way.

That is what zero-blocker delivery really points towards. It is not a world with no feedback, no edge cases and no engineering questions. It’s a world where the predictable blockers are handled early, the file communicates clearly, and design and engineering work from the same definition of readiness.

“Great design is what survives the journey into production.”

The gap closes when handoff stops being a moment and becomes a shared system.

Want to watch the full talk?

You can find the full talk here:
https://uxdx.com/session/zero-blocker-delivery-closing-the-design%E2%80%93engineering-gap-for-real/

Or explore all the insights in the UXDX EMEA 2026 Post Show Report:
https://uxdx.com/post-show-report