The Handoff Breaks Again
The approved flow stalls between design and engineering. When a product designer watches the same handoff break for the third time, the decision is not how to fix the handoff. It is whether to fix it at all, or to let the failure stay visible long enough to force a better conversation about how the product actually gets built.
Kwame was three weeks into a four-week sprint when the pattern surfaced again, same shape as the last two. He had handed the approved onboarding flow to engineering on Thursday, complete with every state, every error message, every edge case drawn and annotated. By Monday morning, the build had drifted. Not because anyone was careless. Because the design file and the implementation had no shared source of truth, and every engineer who touched the flow made a reasonable, local decision that pushed it further from what he had approved.
The third time the same flow stalls
The first time, Kwame rebuilt the specs. The second time, he wrote a longer handoff document. Both times, the flow shipped close enough to pass review, and both times, he watched users stumble on a screen that was not the one he had designed. The third time, on Monday at 9:12 AM, he sat with the build open and the Slack thread growing under him, and he had to decide whether the fix was more documentation or something harder.
The easy call was to re-spec the flow, add the missing annotations, schedule a walkthrough, and get the build back on track by Thursday. That was the job he had been hired to do. But the same repair had failed twice, and he could see the real cost of fixing it again: another round of design catch-up, another missed opportunity to ask why the handoff kept breaking in the same place.
The bad ending was concrete. The onboarding flow was the thing investors saw in demos, and it was the thing new users met first. If it shipped wrong a third time, the product would feel unpolished at the exact moment the team was pitching for the next contract, and Kwame would be the one who had approved a flow that kept arriving broken. He sat with that possibility for longer than he wanted to admit.
Letting the failure stay visible
What changed was not a new process. It was a decision about where to put the friction. Kwame stopped treating the broken handoff as a design problem and started treating it as a systems problem, one that would keep producing the same result no matter how carefully he re-specified the inputs.
He did not re-spec the flow. He left the build as it was, visibly off from the approved design, and he took the divergence to the Monday team meeting as the agenda item. Not to assign blame. To ask a question the team had never answered together: what actually happens between an approved design and a shipped screen, and where does the interpretation happen that keeps changing the outcome?
The turn came when the lead engineer said something Kwame had not heard in three weeks of handoffs: the design file was clear, but it was not the thing the code was built against. The team was building from memory, from the ticket summary, from whatever was open in the browser. The approved file was the source of truth for design, and the ticket was the source of truth for engineering, and nobody had ever said those had to be the same thing.
The morning after
The team did not adopt a new tool that week. They made one change that cost nothing: the design file became the attachment in the ticket, and the ticket became the only place a screen was defined. When an engineer had a question, they asked it on the ticket, not in a side channel, and the answer stayed with the work.
By Friday, the onboarding flow had shipped closer to the approved design than either of the first two attempts, and the team had a working answer to a question that had been costing them a sprint every cycle. Kwame's role changed too. He stopped being the person who repaired the handoff after it broke and started being the person who made the handoff legible in the first place.
The next time he handed a flow to engineering, he attached it to the ticket before anyone asked. And when the build came back, he checked it against the file, not against his memory of it. The third failure was the last one, because the fix was never a better spec. It was deciding that the failure should stay visible long enough to name the real problem, the gap between the file and the work, and then closing that gap instead of redrawing the file.
A version of this pattern shows up in most AI and SaaS builds happening on a small team and a tight runway. The cost of a broken handoff compounds when you cannot absorb rework, which is why the product teams that ship the fastest are often the ones that put the least effort into documentation and the most into a single source of truth. For a related look at what happens when the wrong thing gets the design energy, see how three buyers wanting three different products can pull a roadmap in three directions at once.
Comments
No comments yet.