I’ve been puzzling over a strange contradiction in our industry. Design and development teams are simultaneously collaborative, yet also disconnected. They work toward the same product goals but operate as though building entirely different things. Is this disconnect an organisational inconvenience? Or is it a fundamental misalignment in how we create digital products?

Designers, developers, product brains, business owners and leaders—Makers X had the whole crew in one big, brilliant photo.

The handoff paradigm is failing us

At Stampede Makers X last month, we discovered something unsurprising yet just as disheartening: 51% of teams still operate in what we call the “Handoff stage”—where design creates specifications, transfers them to development and hopes (mostly prays) what emerges weeks or months later, still resembles their vision.

Stampede Makers isn’t your typical event. We created it to address the industry’s elephants in the room—persistent problems everyone experiences but few discuss openly.

For our tenth edition (the “X”), we tackled the design-development divide. Like past Makers events, we put a challenging question out into the world to see if others were just as bothered by it. They were—and they came in droves.

For the first time, we brought together equal numbers of designers and developers, all searching for better collaborative approaches. What emerged was a genuine conversation about breaking down the handoff model that has kept these disciplines working apart while supposedly working together.

William Heng, Senior Vice President and Head of the Fintech Ecosystem and Innovation at UOB Malaysia, welcomed the guests to their beautiful venue.
A vibrant mix of Makers in multiple disciplines gathered on a Saturday morning.
As always, Stampede Coffee Bar is back by popular demand!

The handoff model persists not because it works well, but because it’s the path of least resistance. When we observe teams operating this way, three patterns consistently emerge:

  • Products require extensive rework when technical constraints surface too late
  • Market opportunities slip away as competitors with more integrated teams move faster
  • Users receive experiences that feel “almost right” – visually polished interfaces that don’t quite work or functional systems wrapped in confusing interactions

There is clearly inefficiency, and we’ve become good at normalising it.

But what if the handoff model is not only poorly practised? What if it’s fundamentally misaligned with how digital products should be created?

Why do we keep running this ineffective relay?

Now, if the handoff model creates so many problems, why does it persist?

The easy answer is inertia. We continue using it because we always have. Looking deeper, I realised something more interesting could be at the centre of this: the handoff model aligns with how specialists prefer to work and how organisations prefer to structure themselves.

Li Hui, our UX designer, showing the result of our live poll. Overwhelmingly, 51% of attendees recognise they’re currently stuck at Stage 1: Handoff in dev-design partnership maturity.

This made sense in an earlier era. When digital experiences were simpler and user expectations lower, the gap between design intent and technical implementation didn’t matter as much.

That world no longer exists. Users now expect seamless experiences across multiple touchpoints. Technology has grown exponentially more complex. Speed to market increasingly determines winners.

We’re using a 2005 workflow model in 2025. This misalignment becomes more costly every year.

A developer’s perspective shift that changes everything

During Makers X, Stampede’s full-stack developer Syazwan Zubir described his first usability testing experience. He watched real users struggle with a government website that, from his developer’s perspective, was logically structured. Some users simply gave up in frustration.

The crowd is tuning in as Syazwan Zubir, a full-stack developer at Stampede, shares his perspective on bridging development and user-centred design.
Unpacking common developer frustrations—like unimplementable designs—and calling for better collaboration between design and development.
With clarity, Syazwan reflects on bridging the gap between ideal designs and real-world constraints in product development.

“It was a wake-up call,” he admitted.

This observation reveals something profound. When developers directly witness users struggling with their creation, something fundamental shifts. The gap between building and using becomes visceral. The handoff model suddenly feels not just inefficient but absurd.

Syazwan shared his experience joining a usability testing session.
During it, he sits face-to-face with actual users to learn about them
A mindset shift happened to him, making him curious about the users of the product.
Now, instead of just implementing a design, his curiosity leads the way in solving user problems.

What’s fascinating is this shift doesn’t require developers to become designers. It simply requires them to expand their perspective to include the people using what they build.

Far from diluting technical excellence, we’re contextualising our solutions within human needs. Syazwan calls this “user-centred engineering“, a concept put forth by Addy Osmani, Google Chrome’s senior engineer.

Addy said, “A user’s experience is the ultimate measure of engineering success. Great engineers care deeply about the user and their needs – this includes sweating the details and making sure their experience is a valuable one.“

It does not mean abdicating your development responsibilities. It means maintaining your technical rigour while embracing empathy for the users.

Moving beyond the relay race

Our panel of cross-disciplinary experts revealed several patterns that transform the traditional handoff model:

Atif Aiman from Decube reflects on his developer journey, emphasising empathy as a key ingredient for smoother, more human-centred collaboration.
Alexis Oh from IKEA breaks down practical strategies for collaboration—like pair programming and embedded teamwork between designers and developers.
Ikhwan Nazaruddin from Time shares leadership lessons and tactical resources to strengthen design–dev collaboration within teams.

Embrace your productive friction

Rather than avoiding tension between disciplines, Ikhwan reframed friction as creative energy – like hands creating warmth through friction. “Every meaningful problem needs this kind of productive tension,” he explained. “It’s where innovation happens.”

This perspective shift changes everything. What if friction between design and development isn’t something to eliminate but to harness? Alexis shared how her team’s most innovative solutions emerged precisely from challenging cross-team discussions that initially felt uncomfortable.

The practical application is surprisingly counterintuitive. Instead of smoothing over differences, successful teams create structured spaces for productive disagreement. Ikhwan’s Tower Defense Retrospectives from Tasty Cupcakes does exactly this—it gives teams a framework to visualise both their strengths and challenges without the conversation becoming personal.

Atif added that when development teams are confident enough to push back on design decisions with technical context and design teams are open enough to explain the reasoning behind their choices, the result is almost always a better solution than either discipline would have created alone.

Learning is best done through direct experience

The most powerful catalyst for change wasn’t process frameworks or tools but direct exposure to each other’s worlds. Designers who understand technical constraints create more implementable solutions. Developers who understand the “why” behind design decisions implement them more thoughtfully.

Syazwan’s journey exemplified this perfectly. His approach to building applications changed after watching real users struggle with an interface. In his own words, “I realised that logical code doesn’t matter if users can’t figure out how to use it.”

What’s striking is how this cross-disciplinary understanding develops. It doesn’t come from documentation or presentations. It emerges from shared experiences and direct observation. Alexis described how IKEA’s most effective teams regularly include developers in user research sessions and designers in technical architecture discussions – not to turn everyone into generalists but to build shared context.

Create artefacts that serve both worlds

All panellists emphasised the importance of shared artefacts that bridge disciplines. These aren’t just deliverables to be handed off but tools for ongoing collaboration.

Alexis shared how her team tackled this at an enterprise scale. When designers would look at implementation and say, “This isn’t what I designed,” the root cause wasn’t usually developer indifference. It was that collaboration had started too late. Her solution was a shared artefact—dependency maps between backend and frontend teams—that made complex systems visible to everyone, regardless of their technical background.

What makes these artefacts effective? They’re co-created rather than handed off. They make complex systems visible to everyone. And they focus on neutral territory rather than individual ownership.

Ikhwan expanded on this last point, recommending moving critique sessions away from individuals to the artefacts themselves – discussing “this user flow has friction points” instead of “your design doesn’t work.”

Several artefacts you could consider that worked particularly well as bridges:

  • Component libraries with both design tokens and code implementation
  • Journey maps annotated with both user needs and technical constraints
  • Service blueprints that visualize both frontend and backend interactions
  • Design systems built collaboratively by both disciplines

Communicate across boundaries

The classic question—”But I already told them that!”—resonated across all panelists’ experiences. Ikhwan’s practical “five channels five times” method addresses this reality. Important messages need to be communicated multiple times through different channels to penetrate domain boundaries.

Alexis noted that at IKEA’s scale, they discovered that documentation works best when it’s co-created, not handed off. “The process of creating it together is often more valuable than the document itself,” she explained. The document becomes a record of shared understanding rather than instructions from one team to another.

Atif also shared a simple but effective practice from his experience: regular “design+dev pairing” sessions where designers and developers sit together to work through implementation challenges in real time. These sessions build communication muscles and shared vocabulary that makes all other interactions more effective.

Shaza Hakim, UX Principal at Stampede, joined by the panelists and Amirul, who moderated the session.

The Partnership Evolution

These insights helped us map a progression that teams typically follow:

Handoff: Sequential work with periodic transfers of ownership. This is where most teams begin and many remain.

Coordination: Working side-by-side with regular check-ins. Issues surface earlier, but disciplines maintain separate processes.

Integration: Shared ownership and combined practices. Team members develop cross-functional literacy and focus on collective impact.

Partnership: A unified culture with resilient practices that scale. Design and development flow together toward shared objectives.

What’s fascinating is how each stage delivers tangible improvements – faster delivery, better quality, less rework. But the most significant gains emerge at the partnership stage, where teams operate with an entirely different rhythm.

What if the endpoint isn’t better handoffs but their elimination?

The 4 stages of Dev-Design partnership maturity: where does your team currently sit? And how do you advance?

Small changes, outsized impact

If your team operates in the handoff model, transformation won’t happen overnight. Evolution occurs in stages, each requiring different skills and mindsets.

Here are a few approaches to consider that would consistently produce results:

Put developers in front of users. Not through reports or recordings – have them directly observe usability testing. There’s no substitute for witnessing real people struggle with something you built.

Build an understanding of adjacent disciplines. Designers don’t need to become developers, and developers don’t need to become designers. But they do need enough fluency for meaningful conversations. Basic literacy in both domains transforms collaboration.

Create artefacts together. Journey maps, service blueprints, component libraries – these become powerful when both disciplines contribute to and use them regularly. They’re not just deliverables; they’re collaboration tools.

Share meaningful metrics. When design and development align around shared success metrics, they naturally coordinate their efforts. The metrics themselves become a common language.

None of this requires reorganizing your company or hiring rare multidisciplinary unicorns. It simply requires recognizing that these perspectives are complementary, not sequential.

Learning from our own experience

At Stampede, we’ve been fortunate to learn from 19 years of cross-disciplinary collaboration. Our founding team included both design and development perspectives – not from foresight about these challenges, but from necessity. This accidental advantage gave us insight into what works when these disciplines work closely together.

What’s striking is how consistently the same patterns emerge across organizations. The relay race creates identical friction points whether you’re a startup or an enterprise. And the solutions are surprisingly universal.

Suhail and Amirul—developer and designer, co-directors of Makers X. Their partnership is proof that great things happen when tech and design collaborate at Stampede.

When we collaborate with clients, we don’t arrive with predetermined solutions. We start by understanding how their teams currently work. Sometimes we integrate design-aware developers into their team. Other times we add developers to design teams to validate ideas earlier. We’re not replacing workflows – we’re connecting disciplines within them.

Over time, clients experiencing this approach ask how to build this capability internally. This led us to develop workshops sharing practical techniques. We don’t have all the answers, but we’ve learned what tends to work, and we’re happy to share with teams ready for something different.

Evolving deliberately, not dramatically

If your team still operates in the handoff model, start with small steps:

  • Invite a developer to your next user research session
  • Schedule regular collaborative working sessions
  • Create one shared metric that both teams contribute to

The changes don’t need to be dramatic to be effective. They need to be deliberate.

In the past, we could get away with handoffs. Today, they’re becoming a competitive disadvantage. The organisations that thrive going forward will be those that see design and development not as separate functions but as complementary perspectives on the same challenge: building things people actually want to use.

What if we stopped thinking about improving handoffs and started questioning whether we need them at all?

Makers isn’t just about insightful discussions and knowledge sharing—it’s also a great space to connect with like-minded people

The community that makes it possible

What I found to be the most striking aspect of Makers X was the community itself.

UOB provided their thoughtfully designed space—creating an environment where candid conversations flourished naturally. The coffee that flowed throughout the day (courtesy of our dedicated barista) catalysed cross-disciplinary discussions that rarely happen in typical work contexts.

The Makers X committee and volunteers, all smiles on stage after wrapping up a successful event!

Behind the scenes, our organizing team—a mix of designers and developers—delivered the entire event without experiencing the handoff problems we discussed. There’s something particularly satisfying about embodying the principles you’re exploring.

A huge shoutout to our amazing volunteers—Faiq Uzair, Amir Ali, Sandra Yeoh, and Ahmad Alfhajri! Coming from diverse backgrounds as developers, designers and product managers, their dedication and collaboration were key in making this event successful. They truly embodied the spirit of cross-disciplinary teamwork!

Perhaps the most revealing observation is that over a hundred people dedicated a Saturday to examining how we might work differently. This suggests something important about our community—a shared recognition that our current approaches have limitations and a collective curiosity about alternatives.

Thoughtful questions, honest stories and willingness to reconsider established practices aren’t just personally valuable—they’re gradually shifting how our industry approaches these challenges.

See you at the next Makers 11, where we’ll continue exploring uncomfortable questions, sharing experiences, and yes, enjoying good coffee together!

Need better design-development collaboration? We help in two ways: through integrated project teams that deliver results while modeling better practices, or through practical training that builds this capability within your organisation. Both draw from real experience. Drop us a line to explore what makes sense for your team.