We spend a lot of energy trying to improve design handoff. Better documentation, tighter specs, more thorough annotations. And yes, if you are going to hand off, doing it well is better than doing it badly. But what if we aimed to remove handoffs entirely?
Design handoff is a remnant of waterfall workflows. It made sense when design and engineering operated as sequential phases, with designers working in isolation until they were done, then throwing their work over a wall for engineers to implement. Most of us have moved beyond waterfall workflows, yet the handoff has somehow survived. It has been accepted as the norm, the way we work, when it should not have been.
Handoff exists because we continue to treat design and engineering as distinct problems to be solved separately. The moment you start treating them as a single product problem to be solved together, the handoff no longer makes sense.
The conditions for change have never been better. AI tools are putting designers closer to code than ever before. Prototyping in code, generating working components, and iterating in the same medium that engineering builds in. The gap is closing naturally. The question is whether teams are being intentional about it or letting it happen by accident.
Closing the gap
So what does being deliberate about it actually look like? In practice, it requires changing how teams are structured, how work flows through them, and how disciplines relate to each other day to day. For many teams and organisations, this can be a significant cultural shift.
A good place to start is rethinking the assumption that design must be largely complete before engineering gets involved. Two disciplines working in sequence is not a law of nature; it is a habit. And like most habits, it can be broken with will and the right structures in place.
What if we involved engineering right from the start and throughout the design process? Once we have a clear outline of what we’re building, whether it’s a new component, a feature, or an update to something existing, we can start working in parallel. Whilst design focuses on visual and interaction design, and user experience, engineering can begin prototyping, exploring the more technically challenging aspects, and testing feasibility. Both disciplines, working simultaneously, sharing back and forth, continuously.
Juli Sombat, Encore's Design Lead, created this diagram to visualise exactly how that parallel approach plays out across the length of a project. It shows something that is difficult to put into words: as the work progresses from discovery to delivery, engineering gradually becomes more involved whilst design effort naturally decreases. The lead shifts, but both disciplines remain present throughout.
This parallel approach can surface things early that would otherwise be discovered much later. Sometimes, engineering discovers that something they initially believed would be technically challenging is straightforward, or that the platform provides it out of the box. Sometimes they uncover that something is not feasible, and the design needs to change. The crucial difference is that this discovery happens alongside design, not after a leader has signed off on something that cannot be built.
"Design doesn't have a monopoly on good ideas."
Early engineering input isn't just about catching technical problems before they become expensive. Engineers bring a different perspective to how something could work, and some of the best ideas come from that collision of disciplines.
There is a practical bonus here: prototypes and early engineering thinking sometimes feed directly into the final implementation. Work done in the exploration phase does not have to be thrown away.
When this model is working well, each phase has a lead discipline, but both are present throughout. The transition between discovery and delivery is a gradual shift in which discipline leads, not a cliff-edge where design stops and engineering starts. By the time engineering is in the delivery driving seat, they have been involved from the start, and they have as much knowledge as design; there is nothing to hand over. ✨
The adjustment period is real
Ok, I made that sound straightforward, like flipping a switch. I've led teams through this cultural shift, and I won't pretend it's easy. But when it clicks, you can’t imagine working any other way.
In the beginning, it can feel really awkward. Early engineering input can initially feel stifling to creativity. An engineer pointing out that something is technically challenging or goes against a platform convention can feel uncomfortable for a designer who is not used to this kind of feedback so early in the process. It takes time to reframe it as saving a designer time rather than constraining their work. Why invest significant effort in a design direction that’s not feasible?
As more designers begin to use AI tools to prototype and work in code, they are already operating in the world of engineering to some degree. The shared context makes early technical feedback feel less like a challenge to the design and more like a natural part of the conversation.
In my experience, this only works when there is mutual respect and understanding between disciplines. When engineering genuinely understands and respects what design is trying to achieve, and the processes designers follow. When design understands that there are technical tradeoffs which need to be balanced, early collaboration becomes a strength rather than a source of friction.
A culture where engineers dismiss design nuance, or close down ideas prematurely because they seem time-consuming to implement, makes early collaboration counterproductive. Both disciplines need to develop an understanding of each other's worlds. A shared design vision can help considerably, something everyone is working towards together, so that engineering input serves the same goal rather than pulling against it.
When leaders get in the way
Depending on your organisation, your team's maturity, and the attitudes of the leaders around you, this way of working can take years to feel natural rather than forced. We are talking about changing ingrained behaviours, and your organisational environment will shape how quickly that happens.
I’ve worked with design leaders who place tremendous value on keeping design a centralised, protected function, separate from engineering. Almost as if keeping design isolated as its own independent function is a measure of success. At the same time, engineering leaders want their engineers to focus entirely on code output rather than spending time working alongside designers. Both of these mindsets create walls between disciplines that slow teams down and introduce waste that better collaboration would prevent.
Good leaders create the conditions and set expectations that enable cross-disciplinary collaboration. Shared boards where design work sits alongside engineering tickets. Open design critiques where engineers are not just welcome but expected to attend, present, and give feedback. Processes that require both disciplines to be involved in the problem from the start. And when someone is struggling in isolation, a gentle nudge: Have you spoken to an engineer about this? A culture shift isn't something you mandate. It happens gradually, through practice, until one day teams cannot remember working any other way.
Small steps towards a better world
Not every team is ready for this kind of change. The organisational environment, the maturity of both disciplines, and leadership appetite all affect what is possible right now. That is fine. Wholesale transformation isn't the only option, and suggesting it is can make teams feel like they have failed when the reality is that this takes time.
Small steps can compound. Invite an engineer to your next design critique. Ask a designer to sit in on a technical feasibility conversation. Put one piece of design work on the same board as the engineering tickets. Each of these things is modest on its own. Across a year, they start to shift how a team thinks about the relationship between design and engineering.
Pay attention to where the gap is already closing in your team. Designers who prototype in code or use AI tools to generate components are already working closer to engineering than they might realise. That's a foundation worth building on.
What is one step you can take today to make the handoff irrelevant?