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.

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.

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.

“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.

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:

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.

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?

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.

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?

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.

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.

The post Rethinking the design and development relay race at Makers X appeared first on Stampede: the strategic design & technology company.

Design after familiarising yourself with a platform

Take the time to get to know the platform, web technologies, and end output you’re designing for as each platform has design and functionality related limitations. If you don’t do this first, there’s always the danger that you’re going to design something that is completely wrong for the platform or cannot be coded within a reasonable amount of time. So make sure it’s possible first!

How do I do this? The easiest way to do this is to use the platform and see how it works. Being aware of what scenarios and platforms you’re designing for will help you figure out how big your sandbox is. It also means setting the right expectations for what’s possible with tech. This way, you don’t over promise to your client or product owner only to later say that a key feature you designed can’t be coded.

For example, within WordPress, get to know:

• The content pop workflow in Gutenberg and see what the output is on the frontend
• Widgets
• Custom post types
• Popular plugins like Gravity Forms, FacetWP and FooGallery

For web tech, get familiar with knowing:

• Solid responsive design knowledge from small to 4K screens
• Bootstrap components
• How social sharing works
• How designs will affect website performance

This is by no means an exhaustive list, but it should give you a good idea of what you need to know. Still unsure? Talk to a frontend (FED) and backend (BED) developer for some guidance.

Keep in mind coding effort

It’s very possible that a little bit of design will result in a lot of coding. A typical scenario I’ve encountered is when a designer has designed a seemingly simple feature in a minute, however, it ends up taking much longer to code during FED and BED. The reason for this significantly longer development time is that making designs functional may require more complex backend logic. The danger of not considering coding time and effort is that you’re designing development heavy features that are time-consuming to code which can result in your product development running behind schedule.

Say you’re designing a product sash for products on an ecommerce website. The designer has already designed several product sashes like Sold Out, Popular and On Sale that have backend logic (rules that dictates behaviour) attached so that these sashes will only appear in certain cases. For example, the backend logic for the Sold Out sash means it only appears when the product inventory is 0. Now let’s say that we want to add a new sash for “Popular”. Design and FED-wise, this would probably be pretty fast because there’s already an existing sash template for the designer to modify and existing sashes implemented from which to create a new HTML element in FED. However, the effort to backend code the Popular sash is much higher.

Track time with Toro Timer

Toro helps remote teams stay productive no matter where they are.

Get early access

In order for the BED to code the Popular sash’s backend logic, they first have to know the rules for what constitutes as “Popular”. Different versions will also take different amounts of time. For instance, one possibility is where the product owner wants the Popular sash to show if more than 20 units have been sold within the last two weeks. Alternatively, they may want to be able to manually control what is labelled as “Popular” in which case the admin can tag the product as “Popular”. So depending on these two types of BED logic, there would be a big difference in the time needed to code.

Now, developers generally do not shy away from coding (or at least we hope that they don’t!), but you have to consider how much work you’re creating for them down the line. This is especially important when you have multiple designs and products to juggle and client or colleague expectations to manage. In this light, it might be better for you to give up on this feature (for now) or coming up with a pared down version for the sake of staying on schedule and not overworking your developer.

What should I do? Think about what kind of logic would be needed to execute your design first then consult your client, product owner and friendly neighbourhood developer before proceeding with design. You may find out that what you want to do is not realistic or of low value to the end user. Alternatively, you may find that it’s easy to design, code and has great value! Either way, you’re better informed about the effect of your designs.

Design reusable UI components

It’s important to remember that designs need to be practical, not only in terms of how it will be initially coded but how it will be managed in the long term. In tech terms, this means thinking about designing UI components so they can be reused across the website or app. This adds to the longevity of a design because it can be easily maintained from a backend standpoint while still looking good on the frontend. In order to achieve this you may have to reach a compromise with your design’s aesthetic elements in favour of ease of maintenance.

Let’s explore the consequences of this in an example. You may have chosen to design a website which has varied irregular shapes (think jellybeans and splats). Though this may make for a more visually interesting design, it might become hellish for developers as variations might lead to the writing of bad or unmaintainable code. This is because every unique shape has different margin and padding requirements and the more variations there are, the more low-level coding is required to fine tune them. If the developer is inexperienced, there’s a possibility that the way it’s been coded may not be so readable, elegant or maintainable. This means that if another developer, or even the same one, comes in later, they will have trouble understanding the code and will therefore have more trouble fixing it. More design and coding variations also means that the developer cannot use a blanket fix on them and must spend more time coding a fix for each one. Another problem is that with more code comes more opportunities for older code to break. The end result? Massive headaches.

The last point is that people usually do not end up using all the bells and whistles you designed. Though the website may look fancy after you initially deploy it, your client or whoever ends up doing the content updates and maintenance may not choose to follow suit, or, may even get confused if there are too many options. They may very well end up sticking to one or two elements that they’re comfortable with for content population and forego the other options. All the other stuff you designed and coded will then be wasted effort.

What should I do? Although it is possible to use as many shapes as you like, think about how they’re actually going to be coded and maintained later. One strategy is to design UI components in a way that makes them reusable. Set a fixed number of variations e.g. 4 and stick to those only. The definition of maintainable code is that it’s code that is easy to modify, extend and debug. By designing a custom shape that you can then flip horizontally and vertically to make “new” shapes, you will get the visual variety that you need while still making it easier for the developers to write fixes if ever they break. It’ll also hopefully be simpler for whoever maintains the website in the end.

There you have it folks! Though it’s easy to create aesthetically pleasing designs and features, you have to consider the direct effect design will have on FED and BED and beyond. Remember, design isn’t just about how it looks, it’s also about how it works and what the experience is like for others that you’re working with. Talk to your developers often to discover limitations and peek into what it’ll be like to maintain the design in the future so that you design with development in mind.

The post Designing with Development in Mind appeared first on Stampede: the strategic design & technology company.