Have you ever found yourself in front of your designer or developer and had the feeling you were speaking two different languages?

If you’re a designer, you might remember that project you refined down to the last pixel… until the developer looked at you with a resigned face and said:

“Yeah, nice… but we can’t build it like this.”

If you’re a developer, you’ve probably been dragged into endless conversations about shadows, alignments, and micro-animations while one single thought echoed in your head: “Can we make it work first without blowing everything up?”

Situations like these almost always come from a communication short-circuit: different perspectives, different priorities, different workflows. And yet, despite these frictions, designers and developers are aiming at the same thing: building a product that’s solid, useful, enjoyable to use, and easy to maintain.

So the big question is: how do you move from a dynamic full of misunderstandings and friction to a real collaboration, where each side actually strengthens the work of the other?

In this article we’ll share how, at Buildo, we faced this exact challenge and turned those differences into a genuine advantage.

The collaboration problem

Even after years of “Agile” and “Lean,” collaboration between designers and developers still suffers from misunderstandings and gaps. And these are among the main causes of inefficiencies and drops in software quality.

According to the DesignOps Assembly Benchmarking Report, there are several critical collaboration areas that keep slowing design and development teams down. The most problematic issues include:

• Adoption and maturity of the design system (68%)
• Organization of design files and the design ecosystem (67%)
• Design documentation (66%)

These inefficiencies aren’t just operational details: they have a direct impact on the business. The report shows that almost two-thirds (65.9%) of professionals say they waste between a quarter and half of their time because of issues in the design handoff.

The effects on the organization are predictable and pretty common:

• lower morale in design teams
• reduced designer productivity
• slower feature releases

All these numbers led us to ask one simple but crucial question: when there’s misalignment, what’s actually causing it?

According to the State of the Designer report by Figma, 91% of developers and 92% of designers believe there’s still a lot of room for improvement in the collaboration process. Surprisingly, the root of the problem is less technical than people assume. The most common challenges include:

• different assumptions and mental models
• different priorities and motivations
• poor understanding of each other’s workflow
• very different communication and language styles

In other words, it’s not just a matter of tools or methods: it’s about alignment, expectations, and communication. And better collaboration is exactly where this can be fixed.

Two separate worlds?

At the core of this recurring misalignment are mutual misconceptions: designers think developers don’t care about user experience and are focused only on technical challenges, while developers perceive designers as too aesthetic-driven and disconnected from technical constraints and implementation priorities.

Both assumptions are obviously wrong.

Developers and designers share the same goal, building high-quality products, but they approach it from different angles: developers cultivate empathy through performance, accessibility, and maintainability, while designers balance feasibility and value without giving up clarity and consistency in the experience.

The trick isn’t to flatten these differences or decide which perspective is “more correct,” but to leverage each role’s strengths in a complementary way. When balanced properly, they create a positive tension: designers push for innovation, and developers focus on making it real.

All this starts with transparency and communication: shared goals, shared context, aligned language, and a genuine understanding of each other’s priorities and constraints.

From “handoff” to collaboration

One of the questions we hear most often is: “How can we improve the handoff between design and development?”

But that question reveals a pretty linear view of the development process, one that still hasn’t fully abandoned a waterfall mindset.

In this model, developers see the design for the first time only when they have to start implementing it. By that point, however, many decisions have already been made: stakeholders have already approved the prototypes, and release deadlines have already been defined.

The handoff therefore becomes a critical and tension-filled moment: developers have not taken part in the process of gathering and defining requirements (and thus lack context around the decisions that were made), and there is little room left for technical input or iteration. At this stage, it is often too late to propose alternative solutions, negotiate technical trade-offs, or try to simplify the solution while keeping its value intact. The result is frustration on both sides, and “it can’t be done” often becomes the easiest, if not the only, possible answer.

What if we completely replaced the handoff with continuous collaboration from the very early stages of the project? Having developers on board from the start, even during the discovery or ideation phases, would make the handoff virtually unnecessary, because there would already be alignment on goals and decisions, while also making it possible to maintain a faster and more consistent feedback loop.

Ready-to-use strategies for project collaboration

Let’s look at how to act during each stage of a project with this different mindset.

Kickoff: Preparing the ground

The start of a new project (or a new phase of a product) is the perfect moment to define collaboration rules, introduce improvements, or fix what didn’t work before.

It’s useful to set up one or more preliminary meetings where the team (directly or through key people) aligns on goals, timelines, and expectations, establishing shared ground and a shared language.

This is also where responsibilities should be clarified, or updated.

Beyond the main activities of each role (research, design, development, etc.), many secondary tasks fall into a no-man’s-land without a clear owner, often becoming the first source of conflict. Depending on the project, it can help to define things like:

• Who manages relationships with other functions (content, marketing, external stakeholders)?
• Who ensures technical desk checks between designers and developers happen?
• Who organizes demos for stakeholders?
• Who ensures requirements or acceptance criteria are formalized?

Defining these responsibilities early helps everyone feel involved, prevents misunderstandings, and lets you plan the support work needed for the other role (for example, scheduling time for a technical review of the design).

Every effective process is based on continuous improvement.

So it’s important to carve out moments to reflect on the project’s specifics, integrate past feedback, and define corrective actions, both technically and organizationally.

Alongside traditional kickoff activities (clarifying context, goals, and milestones) you can also add more operational discussions around tools, processes, and collaboration modes. This is a great time to reflect on past communication issues and plan changes to address them.

For example:

If you’ve had visual defects slip into production before, you might introduce more structured verification points.

If there were misunderstandings when the design reached development, you might try alignment meetings, co-design sessions, or more formalized design-involvement processes during development.

Every experiment should start from clear pain points and include metrics to assess whether things actually improved.

Discovery & Scope Definition: Exploring together

Too often, developers are involved only after the discovery phase has converged and been finalized.

Bringing them into research and ideation early, not as supervisors, but as partners, makes collaboration way smoother: you share context, the handoff becomes more natural (sometimes unnecessary), technical empathy increases, and solutions get validated technically before reaching stakeholders.

You might think this takes too much time or coordination, but there are simple formats that fit easily into existing workflows.

Sessions like Crazy 8 or 6-up 1-up let developers join brainstorming, align on goals, and contribute technical perspectives with minimal prep.

Value–Effort sessions help teams discuss and negotiate the value and development cost of features or alternative solutions, balancing user value with technical effort.

Finally, you can try shared estimation sessions: developers and designers estimate each other’s effort during ideation, prototyping, and development. Precision isn’t the goal, the value comes from the conversations that happen when perceptions differ wildly.

Delivery: Keeping the conversation alive

In the Delivery phase, the spotlight naturally shifts toward development work. But it’s essential to keep designers actively involved to validate implementation and handle requirement changes smoothly.

On one side, working together to define application requirements clearly helps unblock doubts and prevent future bottlenecks. In our experience, having a shared document, the single source of truth for product behavior (whether specifications, user stories, product requirements, whatever format you prefer), is incredibly valuable and continues evolving throughout development.

On the other side, internal demos, desk checks, and regular review sessions keep collaboration alive: they let designers validate work before it reaches stakeholders or clients, and give developers a direct line to ask questions or propose improvements quickly.

The culture of feedback

Everything we’ve discussed so far relies on one essential skill: communicating effectively and exchanging continuous feedback about what’s working and what isn’t.

Over time, we realized that practical issues almost always stem from underlying communication problems or misunderstandings between roles.

For this reason, and noticing how teams naturally tend to focus only on practical issues without addressing the relational ones, we experimented with what we call “Heart-to-heart Retrospective”: instead of only hosting standard operational retros (using formats like “liked, learned, lacked”), we added meetings focused on emotions and interactions within the team. With the help of an external figure (like People & Culture), we analyze real episodes to understand where collaboration or communication got stuck and how we can improve human interaction going forward.

As we mentioned during kickoff, it’s then essential to set up a process where issues and corrective actions from these retros actually turn into changes — for example at the beginning of a new development cycle. Without this follow-through, all those conversations risk going nowhere.

Conclusions

Real collaboration doesn’t mean removing differences, it means learning to make them work for you. When designers and developers share context, language, and goals, work flows more smoothly, decisions become stronger, and the final product improves in quality. At Buildo we learned that you don’t need to revolutionize your processes: you just need to create the right spaces and moments for each role’s skills to meet, challenge each other, and sometimes politely clash. That constructive friction is often where the real value comes from.

Want to keep exploring how to improve collaboration between designers and developers? Follow our monthly series DES ♥️ DEV by Agnese Ragucci on Instagram and LinkedIn: stats, insights, and practical tips to work better together.