Shift Left: Bringing Developers into the Design Process Earlier

Most people agree that devs aren’t included early enough. Shifting left improves how teams work—not just when they work.

Research consistently shows that developers are not included early enough in the design process. According to the State of Designer-Developer Collaboration 2024 report, only 10% of designers feel collaboration is smooth, while 51% of businesses report inefficient use of specialist time due to unclear handoffs.

This highlights a fundamental issue: teams are still operating in silos, treating design and development as separate phases rather than parts of a unified workflow. But the real problem isn’t just about timing—it’s about changing how teams collaborate.

We often get caught up in debating each other’s processes, domains and expertise. Instead, we should adopt a product team perspective. In fact, Scrum itself states that there are no fixed roles, only accountabilities. We are team members working toward the same outcome.

When we talk about handoffs, we often imply a linear process, where designers complete their work, then developers take over. The larger this gap, the more expensive and time-consuming the handover becomes. While improving handovers can help, it only treats the symptom. The real solution lies in eliminating the gap with continuous collaboration.

For designers, early developer involvement brings valuable technical insights that shape better design decisions.

For developers, participating earlier means increased understanding and a more efficient implementation. Instead of handing off work, teams should co-create solutions from the start, aligning on constraints and possibilities together.

The Shift

Teams are not creating perfect solutions—they are finding the best possible solution within constraints. Product development is an economic challenge. Teams must balance cost, debt, time to market, potential gains, customer needs and overall commercial value.

Return on investment is critical for both designers and developers.

Gathering evidence is key. Developers provide critical insights into what is feasible and sustainable. A common mistake designers make is assuming they know the best solution without factoring in engineering constraints. Developers, on the other hand, can build almost anything—but at what cost?

As one developer I collaborated with often put it, “I can turn our software into a coffeemaker. The question is, how much time and money do you have?”

This quote perfectly captures the reality of product development. It’s not about whether something is possible—it’s about whether it makes sense given the constraints.

Early developer involvement brings essential technical insights that directly impact design decisions. Instead of designing in isolation and later discovering feasibility issues, teams should align early.

This is the essence of Shift-Left—bringing collaboration, decision-making and problem-solving to the beginning of the process, where it has the greatest impact.

Because in software development, timing matters. The later a problem is discovered, the more expensive and time-consuming it is to fix.

The Hack

But many of us operate in environments with mature processes, complex product politics and a rushed reality.

Change is hard. But there’s a way to introduce real collaboration without too much disruption: Hackathons.

Recently, I worked on a project where we ran hackathons with domain experts and users. Instead of following our normal Scrum cycle, we used real-time cross-continental collaboration:

• Users pitched ideas.
• The team gathered the requirements together.
• Designers and developers brainstormed in the same room.
• We focused on prototypes.
• We documented learnings and follow-up work.

The outcome? A shared understanding, quicker feedback and smoother collaboration—without the friction of a traditional handoff.

Hackathons remove a lot of constraints. They help teams focus on solving the core problem first. They also foster deeper collaboration, helping designers and developers understand each other’s thinking.

This doesn’t have to be a one-time event. Embedding “feature hackathons”—even for half a day—can greatly improve collaboration.

But a hackathon does not deliver production-grade software, so what does?

The Spec

After you run hackathons, the next step is integrating this in your normal cycle—with interactive refinements.

Refinement sessions in Scrum can turn into hour-long lectures or document reviews. Instead of another passive meeting, an interactive refinement works like a mini-hackathon.

To make it work, the lead developer or architect, product owner, and designer should prepare the scope beforehand to make most out of the time.

The session follows the 4C’s framework:

• Collect – Gather context, requirements, ideas and constraints.
• Choose – Identify critical decisions, align and choose direction.
• Create – Work together to generate solutions and specifications.
• Commit – Finalize agreements and update the Spec.

By the end of the session, the team should have a Spec covering most of the work. The remaining work can be refined individually.

The real benefit of interactive refinements is pre-aligning on the why, what, how and when. If the team is already in agreement, do you really need a Figma file to show every little detail?

But the reality is that teams are communicating mainly through meetings, messages and discussions—outside project management tools. Only 28% of collaboration happens in the designated project tools, meaning key decisions and rationale often get lost, and shared documentation is not prioritized.

But design is about capturing decisions in a specification document, verifying alignment before development begins.

I often instruct designers to spend more time on a well-written user story rather than a pixel-perfect Figma file. A spec isn’t just a written document—it’s a collection of all necessary materials, whether visual, textual or graphical. Together, these elements form the foundation of design.

In one project, I worked closely with architects on C4 diagrams before starting the designs. This kind of alignment removes a lot of ambiguity and is a great example of a visual spec that helps both designers and developers stay on the same page.

Shift it, Hack it, Spec it

The ultimate hack isn’t just about moving things earlier—it’s about bringing the right people together at the right time. By involving multiple perspectives early and collaboratively defining a shared spec, teams align from the start.

Instead of simply bridging the gap, we start together, diverge to explore both design and technical perspectives, and then converge toward a unified, well-informed specification document—the Spec.

This shift improves how teams work—not just when they work.

• Involve developers early to surface constraints before they become problems.
• Use hackathons to foster real-time collaboration and shared understanding.
• Go beyond passive refinement meetings. Turn them into interactive working sessions.
• Capture decisions where work happens—inside a Spec, not buried in messages or design files.

A great spec isn’t just documentation—it’s a commitment to clarity, collaboration and execution.

Start small. Run a feature hackathon. Transform your next refinement session into an interactive workshop. The earlier you align, the better your software will be.