Zero-Blocker Delivery: Closing the Design–Engineering Gap (for Real)

Marcus Knight at UXDX EMEA. Video: https://youtu.be/jEPWPsHMWAQ

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Meet Gavin

[00:00:08] Good morning, Berlin. I have to say to the Berliners who are finally enjoying the sunny weather that we have now. Yes, great, good, we have life. So firstly, hi everyone. This is Gavin, and I'm sure everyone has a Gavin in their company. This is my version of Gavin. Gavin was one of the most experienced engineers on my team when I joined N26. He was sharp, incredibly pragmatic, and very good at exploiting the exact parts of the design that would just break. Early on, our relationship was tense. He always found a reason to not move the work forward, and for me, I found that so frustrating.

[00:00:49] I would show up with these beautiful Figma designs, polished, specced, ready to be shipped, ready to be built, and Gavin would always immediately start pulling it apart, poking holes in it. Again, it made me super frustrated. At first I took it so personally, like, why does he not want to build this? But over time I realized something very important. Gavin wasn't trying to block the work. He was essentially trying to protect the team from uncertainty.

[00:01:22] So, closing the gap between engineering and design, for real. Hi everyone, I'm Marcus, and for the last three and a half years I have worked at N26, where I've led design. The realization about Gavin, it changed everything for me. It made me look at our process and our tools and our people. On the surface we had polished files, documentation and formal reviews. All of this worked, it looked like quality control, but underneath the waves the collaboration model was broken.

[00:01:57] Every time engineering opened the file, and it sounds like I'm picking on engineering, I'm really not, just building up for you guys, but every time engineering picked up the file and opened it, everything became a very, very painful conversation. I'm looking over this side because I know most of the designers here, so you probably understand, like, oh no, not this again. So today I wanted to talk about how we move from the handoff as a stressful one-off event to handoff as a shared system. So what I call zero-blocker delivery for the engineering and design gap.

The handoff trap

[00:02:28] The real issue was not Gavin. The issue was the handoff model. I was treating the Figma file like a finished, polished package. Engineering was treating it like a set of decisions that needed to be made. And both sides weren't wrong. Both sides were not right. The design looked completely visually great, but it was not complete from the implementation point of view.

[00:02:54] When we surveyed leaders across design and engineering led orgs, 64% said that there was no standardized practice. There was no way of them knowing what the standard is that we're aiming for. For me that was really shocking, because we had been doing this for three years and for me everything worked. But apparently, do your research: it actually was not working. That confirmed that we were failing there. We did not have a shared definition of what ready was.

[00:03:28] Once I listened more closely to Gavin's feedback, digested it a bit more, I noticed a pattern. Most of the so-called blockers were not necessarily engineering issues. They were communication gaps. Now, I don't mean verbal communication. I mean the communication in the file itself. It was not speaking directly to engineers. Gavin was asking incredibly reasonable questions about things like library components, API failures, don't get me started with that, that's like total science to me, and loading states. These aren't annoying engineering roadblocks. They are product quality questions. The problem was that these questions would always show up far too late in the process.

[00:04:14] That's me, by the way, stressing over the changes I have to make because of Gavin. I know he's here somewhere, but anyway, we'll get to that later. So this was the mindset shift for me. I stopped thinking of my design file as something explaining the experience to stakeholders, or selling it to marketing, et cetera. It needed to explain to engineering. It also needs to explain how do you build this experience. That doesn't mean turning designers into engineers. It means respecting implementation as part of the process. If the file creates uncertainty for engineering, then the design is not done.

Blocker one: file hygiene

[00:04:57] So let's just go over some of the blockers that were highlighted in the survey that I did. The first blocker was basic file hygiene. Yes, wonderful, super boring, I know, but it's super important. This sounds boring, but you absolutely must do this, because your engineers, you want to be able to almost scale what it is that you know in a design file, so that an engineer can just look it over and go, ah, I get it. In an ideal world. It's not the reality. If a file has unnamed frames, duplicated flows, old explorations sitting next to finalized designs, that is going to create confusion.

[00:05:35] Engineers would waste, excuse my French, they would waste a shitload of time digging through your files to just really understand what is the source of truth. What should they be building? This was a massive problem, especially when you're in a company that is super keen on AI. We're building faster, we're shipping faster, and this now becomes a problem. So the goal was simple: when Gavin opened the file, he should know exactly what mattered.

[00:06:03] Bit of a problem because we have two screens, but on the left is originally how we had the files, so I'll just go from here and here. And on the right side is dev mode, which has a focus mode for engineering. They will never see any of these random pages here. They will never see this. They will never see that. Dev mode is great at just creating a focus. So we switched more to dev mode so that we can create much more focus for engineers.

Blocker two: missing states

[00:06:29] The second blocker was missing states. Another one. I know it sounds obvious, but designers, we often create for the happy path. The perfect data loads, the user does the right thing, everything works, ta-da. But engineering lives in the misery paths. I know some say unhappy paths, but I prefer misery, it just adds more drama to it.

[00:06:50] So the questions that will come up: what if the data is missing, how do we account for that? What if the user has no results, what's the state, what do we do? What if the API fails? There's API again. What if the button needs to be disabled? All of these questions would constantly come up, and it was more of a tandem of, okay, I throw the file over, you come back with questions, I make changes, et cetera, et cetera.

[00:07:13] So we started to document these decisions directly in the design file. So that's through the comments that you have here, adding annotations, et cetera. Most importantly, it's also not in a separate document. Again, we're notorious for doing this. We have a Google slide to talk about the product requirements. We have a Google sheet that talks about the different metrics we're trying to achieve. And you're constantly bouncing around, and we're constantly grabbing the latest version, copy and paste into a Figma file. It gets crazy. So we made sure that we kept everything in the same file.

Blocker three: system standards

[00:08:01] The third blocker was system standards. Where are my design systems engineers, designers? Yeah, they're in here somewhere. They're going to love this one. For us that meant three things. Component usage. Yay. Again, designers, I know we detach components like crazy because it just feels so restrictive, but bear with me. Using strict design tokens, and a clear rationale for everything new. Oh my gosh, tiring but necessary.

[00:08:30] A design can look right in Figma but still be risky if a component is detached, if we manually style anything, if we're using one-off UX patterns. Again, this drives engineers crazy. Why can't we use what's in the design system? Or why are you using this? All of these questions are constantly coming up. So a design can look right in Figma but still be risky to build, especially when it's detached.

[00:08:57] That meant answering a few basic questions. Why can't the existing component solve this? Is this reusable or is it a one-off component? What states does this component need to have? How does it behave? And if it introduced a new interaction pattern, it had to be demonstrated, not just shown in a static image.

[00:09:22] So here, this actually should be playing. Is there any technical difficulties there? Anyway, this is your prototype window, and it's basically showing the different switches between the cards that we have here. By the way, these are our virtual cards. Love these designs. You're going to see cookie everywhere, I just absolutely love it. And this window is essentially showing the engineer what it is I'm trying to do.

Blocker four: feedback, and vibe comps

[00:09:50] The next blocker was feedback. Again, this one should be playing. Anyway, we'll get to that. Engineering needed a clear channel to give feedback before the design became too polished. So Gavin was my early sounding board. I brought him rough Figma files. I brought him what I call vibe comps, so I'll get to that in a bit. And for me it was important that as soon as I had an idea, at the point of inception, I had a conversation with him immediately. Even if I didn't have a design or anything ready, I would literally go, Gavin, I've got an idea, have a look at this, what do you think? Oh, not you again, Marcus. Well, we're doing feedback, right? We're trying to communicate more. So this is the relationship we started to develop a bit more.

[00:10:39] We use comments. I use vibe comps. So, vibe comps. This is a very early exploration of how I wanted the card selector to be. This was something I prompted up in Figma Make. Took like five minutes to do. But this is something I brought to Gavin right away. I said, look, this is what I'm trying to achieve. I want different transitions. I want a much cleaner, more simplistic way of just switching between our different virtual cards. He took one look at it and said, that's interesting, how far in the design process is it? That's it, it just started. That's why I'm here speaking to you. So that worked out pretty good.

[00:11:14] So the goal was not approval. The goal was pressure testing. And with this vibe comp, I don't know, I've never heard the term vibe comp, so if no one else has heard it, I'm coining it today. Please put that in some YouTube reel somewhere. That gave Gavin things to say like, this interaction could be expensive, it's too complicated to build, there's that word again, the API does not support that.

[00:11:47] This pattern might also create unnecessary complexity. Again, working in a bank, there's a lot of regulatory issues that we have to work around, so it's really important that we don't introduce more of this stuff. Anyway, because the feedback came earlier, it was useful and it was less threatening to me as a designer. I didn't feel threatened. I didn't feel like he was attacking the file. I didn't feel like he was just trying to prevent any work from moving forward. So this was really great.

Dev mode supports the process, it isn't the process

[00:12:21] So this is where Figma dev mode became really useful. In fact, we weren't fully leveraging Figma dev mode in the first place. Sorry, Ilgaz. So Ilgaz is our design ops lead. He fought tooth and nail to get the budget to afford dev mode, and we weren't using it, but we're using it now, Ilgaz. So apologies, but we're using it, so keep up the great work. Dev mode helped engineering inspect designs, measure spacing, review components, and understand what was marked ready for dev.

[00:12:56] But to be honest, dev mode did not magically fix the handoff issue. One limitation we ran into was the indication that we had a prototype attached to any of our boards. So in this example here, we actually had to create this little component here. It's actually native in Figma, but we had to recreate this and just paste it along with our files when we ship these off to dev engineers to build. That matters because some interactions simply can't be understood by looking at the file. So it's important we can demonstrate any new components, any new UX patterns, while we're not in the file ourselves.

[00:13:41] So we created a simple rule: always, in some shape or form, have an indicator that there is a prototype attached to it and that it's ready for dev mode. And just here, I mean, we all know this, you select for dev mode, it's right there. So we really started to utilize that, but most importantly we made it a rule, so an engineer knew what to look for and a designer knew what to enable.

[00:14:11] The biggest lesson was this. Dev mode is not the process. It supports the process. Before a design can move forward, it needed the following. A clear ready for dev section or an indicator. Clean frame names, you can actually prompt this in Figma, so that's one less thing to worry about. Key states documented. Important behaviors annotated and clearly marked. Prototype links whenever available, especially if there's something unknown. Technical constraints clearly visible. Now this can be in the comment section. It could be, dare I say, an external document. Please don't do that.

[00:14:53] This made the design easier for Gavin to trust. It also made critique less personal. Gavin was no longer dismantling my work. He was checking the file against an agreed standard.

[00:15:10] At this point the work changed. Great, we're finally making traction. Not because the tooling was better, but because the relationship with Gavin was better. We had clearer feedback loops. We had a shared language. We had fewer surprises. I'm slightly lying with that. I'm always surprising Gavin, because that's just the type of person I am, might just want to keep him on his toes. And most importantly, engineering feedback started to make the design stronger, instead of making it feel like a threat.

The messy reality: you can't run a process on one engineer

[00:15:48] But then we hit a messy reality of product development. Up to this point, everything works, it's great. The reality is this. My relationship with Gavin had improved. We were in a great place, almost like a married couple. But then that didn't mean it magically fixed the design handover process.

[00:16:13] Gavin was stretched across multiple work streams. He was stressed, he was tired. He didn't always have the time to get involved in my discussions. So when I tried to bring him in really early into these conversations, rough work, chats, et cetera, he actually started to push back. Not because I was annoying him. He just actually didn't have the time. He told me, I don't have the capacity, I have too much going on right now, come back to me when the design is super polished and well thought out, et cetera. I was like, whoa, whoa, hold on a minute, are we going back to square one? We're going back to the handoff trap. We had spent and put a lot of effort into getting to a space where it just worked. We communicated well, the documentation was there, it worked. And now you're telling me to go back and do exactly what we had, the problem we had just come from. Super bizarre for me.

[00:17:05] So he was actually right in some strange way. We couldn't design a process that solely relied on myself and Gavin. I couldn't rely on stealing hours from him. He's a lead engineer. He needs to give direction to the team. He needs to be in other stuff. So it wasn't fair. In many ways I was being super selfish about that.

[00:17:30] When deadlines get tight, the discipline fell apart and we slipped right back into the handoff trap. So the question changed. It wasn't just, how do I communicate to engineers? How do I ensure they have everything they need to build without me being in the room? How do we protect engineering's time? How do we ensure that we get the feedback we need from engineering? How do we close the gap?

Sheldon: a first line of defense

[00:18:00] That is where Sheldon comes in. Any Big Bang Theory fans in here? No. Okay, I'm surprised by that. Since I couldn't clone Gavin, well, at least not now, I'm working on it, I built a Claude Code skill to act as a first line of defense. Sheldon does the heavy lifting of checking file readiness before an engineer even has to look at it. The goal is not to judge the visual quality of the work. Sheldon does not care if the design is beautiful. He doesn't care if you're using this, et cetera. What Sheldon is checking for is the existence of something. In this case it's being much more practical: can an engineer understand the design file enough to build from it?

[00:18:51] As a designer, I can run Sheldon before any handoff even happens. And what it is looking for is everything I discussed with Gavin. I basically took all of the questions, I ran a prompt, all of the conversations we've had in a Google chat. I ran a history check. What are the different use cases that Gavin brought up? What issues does he typically bring up? What are the different use cases? What are the different states? You name it. I went super deep into it to really understand what are all the things that Gavin would be looking for, and how can I anticipate those questions. So I built that into a skill, and Sheldon will look for all of that. He will even give you a scorecard. He gives you a summary. You even get a verdict right away at the very top. In this case, it's not ready. And here in the top right you have the dev mode indicator that wasn't on, and Sheldon, yep, he found it. There's problems there. So this was great.

[00:19:56] Sheldon gives us designers a simple readiness score. This is just to go a little bit deeper into that. Sheldon is not there as a replacement for engineering feedback. It's more like a pre-flight check. If the file is marked as risky, Sheldon explains what is missing, what needs attention. That might be an unconnected flow. It might be a missing error state, or any unclear comments or any documentation. It might be a missing prototype, because it knows that this component doesn't exist in the design system, so it will flag that.

[00:20:31] I really love Sheldon because, when you see him in the Big Bang Theory, he literally is like living AI, robotic like. So for me this just made it a bit more fun by giving him the name Sheldon, because I just love the way he reacts to things. Bazinga. So this made the handoff conversation much easier, because I was no longer relying on memory or personal discipline. I could just run Sheldon. Sheldon will do the checks, and it made the conversation with future engineers, not just Gavin, a lot easier.

[00:21:11] The biggest change was not that Sheldon removed every blocker. That would be super unrealistic, they're always there. The change was that it helped me move the blockers to an earlier stage. Earlier is cheaper. Earlier is a lot calmer. Earlier creates better design. That is where the gaps start to get closed.

[00:21:36] It is not about pretending there will never be any feedback from engineering. Again, not picking on you guys, but they will always find those really super narrow edge cases, which is great. This is the point, right? We're trying to make a great product. It is about giving designers a better way to prepare for those questions, a better way to eliminate any unexpected issues that might pop up. Sheldon helped turn file readiness from something that's subjective into something designers could check, improve, and own themselves.

A design engineering mindset

[00:22:16] So where does this lead us? For me this is not just about fixing the handover process or passing a file readiness check. The bigger opportunity is a cultural shift towards a design engineering mindset shift. And to be clear, I do not think design engineers, in our case, should be shipping directly to production code. I do however think we should be utilizing AI to do that for us. To me it means being a designer who deeply understands the medium and the platform you're designing for. Someone who treats implementation as part of the craft, not something that just happens in a silo.

[00:22:56] This is why tools like Sheldon matter. They can help automate the tedious parts of the handoff, like file hygiene, missing states, broken flows, unclear annotations, and basic file readiness checks. That gives us more space to focus on the details that actually shape the product. The goal is not to hand over static screens. You really want to show what the intention is.

[00:23:29] If there's one thing I want designers to take from this, it is that handoff is part of the design process. It shouldn't be seen as an afterthought, or, oh no, I have to do it. The file is not just a place where we make things look good. It is where we explain intent, behavior, constraints and decisions. So know your engineer, know your Gavin. Or if you want to go the AI route, know your Sheldon. Bring them in earlier into the conversation. And sure, I know this is totally obvious. I've seen a million talks that talk about bringing engineers in earlier, et cetera. Yes, I know, there's no rocket science behind this. This is exactly how it goes.

[00:24:14] Design for the misery paths. So, no more unhappy paths, it's complete misery. Obviously from the UK, I love that word. And make the design ready for dev standard visible. What I mean by that is have that agreement with your engineer on what is ready for them. This whole process taught me something very important, that you can't essentially boilerplate a process if you want to work faster. You have to tailor it to your own situation. So if there's any inspiration from what I'm talking about, you take this to your engineer and you figure out a way of how you can work together better. There is no one-size-fits-all. Great design is not just what works in the prototype. Great design is what survives the journey into production. Right on time. Thank you.

Q&A

[00:25:15] Host: Excellent, thank you very much. I'll just grab that. So we'll flip to the questions. That was a great juxtaposition between the two talks so far, of throw away the UI versus how you get deep into the Figma. But I think both can be true at the same time. The one is probably a couple of years in the future and this is solving the problems today. So the first question is, seems like classic design. Oops, can we pin the question? So we'll go with "seems like classic design from the past". Any thoughts on AI in banking? Are you doing any AI work at N26?

[00:25:58] Marcus: As with most companies, yes, we're doing lots of AI work, and at least for me, top of mind is how do we start for designers? How do we integrate AI into our entire process? Because we have an app, not everyone knows Swift code or can work with Android, so it's a little different for us to ship directly into production, because we don't want to disturb anyone's money or their balances. So it has to go through a much stricter process of getting there. But top of mind for me is really in our design files, in our design process. We have all been onboarding onto Claude Code, and we're really trying to think about how do we integrate that to make our lives simpler and easier. How do we get it to be a multiplier of things that we want to do?

[00:26:43] Host: So it's using the AI in the development process and not yet hitting the product just yet.

[00:26:47] Marcus: Exactly, yeah.

[00:26:48] Host: Okay, yeah, because I'd be a little nervous of my bank balance.

[00:26:51] Marcus: Oh, 100%. And I also don't trust myself to push to production in a banking environment. Web, other areas, for sure, all about it.

[00:27:01] Host: Excellent. Can we get a QR code link for Sheldon's MD or skill file and try it out?

[00:27:08] Marcus: Ah, yeah, I can put something together. Yeah, I can do that for sure.

[00:27:13] Host: Excellent, we'll give you a little bit of time.

[00:27:16] Marcus: Yeah, exactly, I've got to take out some of the confidential stuff.

[00:27:19] Host: Okay, so we'll chase up on that and we'll share it out.

[00:27:24] Marcus: Oh yeah, absolutely.

[00:27:26] Host: How did you create Sheldon? Is there a Figma MCP, or how are you getting from Claude Code to Figma?

[00:27:33] Marcus: So I was a little cheeky. I essentially used AI to talk to AI. I used Gemini and then I jumped back into Claude and was bouncing around a bit. So I said, Gemini, I need a skill prompt, tell Claude to go and do it. So he gave me a prompt to prompt Claude, and Claude came up with something, and then I went back to Gemini. I even brought ChatGPT into the conversation. I said, can you just check it? Because I love ChatGPT with its language, it just speaks better to me, it's a lot nicer to me.

[00:28:02] Host: That's a brilliant idea.

[00:28:03] Marcus: Yeah, so I got the AI models all working against each other, and then through a few iterations we got to a good space. I still haven't quite figured out how to make it sound like Sheldon, so the personality aspect is still something I'm working on.

[00:28:17] Host: And can it read directly from your Figma files, or do you export it somehow?

[00:28:21] Marcus: Yes, it can go right directly to my Figma files.

[00:28:24] Host: Excellent. Yep, so hopefully we'll get that shared after the event. Is it correct that you got around the handover trap by mostly just collaborating? I mean, fantastic, but didn't we know that? Said lovingly.

[00:28:40] Marcus: Exactly, yes, that's the point. AI can somehow create this strange layer that everything is going to be amazing. Again, it's a multiplier. It really helps you do things quicker. And in my case, where did I want to use AI? In areas that drain me. For example, and for me it's the analyzing the file and understanding what the missing use cases were, et cetera. That's where I utilize AI. But the point is, especially with COVID and working remotely, this layer of collaboration and communicating is somehow blurred. So I do want to reiterate the point that you should be communicating and collaborating with your engineer. So yeah, to your point, we've already done it, it's nothing new there.

[00:29:22] Host: Yeah, I think it's also the speed change has actually made it easier, because it used to be it would take a lot longer to get, as you were saying, you can prompt and it's quite quick, and then also from the dev side the speed has sped up there. So I think it actually makes it easier to collaborate.

[00:29:39] Marcus: 100%, yeah.

[00:29:41] Host: Okay. If AI prompts are the future, why does N26 still make me click buttons?

[00:29:49] Marcus: Who are you? Show yourself. That's a great question. I'd love to speak to you about that after. The truth is we are still figuring out, as a company and as a product, what AI is going to do for us. How do we want to utilize that? Can we leverage AI's capability to analyze spending behavior, for example? There's a lot of regulatory compliance that we have to get around with, GDPR et cetera. So we are trying to figure that part out.

[00:30:19] Host: And to Dez's point, he said a lot of companies are blurring the boundaries, that it used to be everybody was kind of more siloed. Do you see that happening with N26 becoming more than just a bank, with all of your spending information and things like that?

[00:30:33] Marcus: There's a PR person around us anyway. To answer your question, I can't really answer that right now.

[00:30:42] Host: Okay, fair enough.

[00:30:43] Marcus: Sorry guys, I know.

[00:30:45] Host: And we look like we're just out of time. So thank you very much, Marcus.

[00:30:50] Marcus: Thank you.