How do I get designers and developers to actually work well together?

Clients often ask me how designers and developers can work together more efficiently. There's no single recipe, but one rule of thumb has held up across every team I've worked with: communicate constantly, starting before the project even begins.

‍

Why collaboration breaks down

Especially with smaller teams, not every developer has worked closely with a designer before. And when they have, it wasn't always a great experience. Designers showing up with fully finished screens and expecting them to be built pixel-perfect is a common friction point. Developers raising technical objections at the end of a design process that could have been flagged at the beginning is another.

Both happen because the two disciplines are working in parallel rather than together. The fix isn't a process change — it's a communication change, and it has to start earlier than most teams think.

‍

Start before the design starts

When I join a new project, one of the first things I do is introduce how I work. Not in a formal onboarding sense — just a conversation. What does the development team's current process look like? Where have handoffs broken down before? What do they need from me to make their job easier?

That conversation changes what happens next. If you say you'll bring developers into the process early, show them rough sketches, and align on technical requirements before anything is finalized — you need to actually do that. Saying it and not delivering on it is worse than never saying it at all.

‍

The smaller the team, the closer the connection needs to be

In a team of three or four people, there's no room for isolated work streams. A lead developer in that environment often has real input not just on technical constraints, but on product direction — what should ship and what shouldn't. Treating that as noise to work around instead of insight to use is a significant mistake.

I've been on projects where early conversations with developers surfaced constraints that changed the entire design approach. Not because the design was wrong, but because the developer knew the codebase well enough to flag that a particular interaction would take three times longer than expected. That's valuable information. Getting it at the sketch stage costs nothing. Getting it after a design is finalized costs days.

‍

Overcommunicating early avoids most problems

Work in isolation, hand off a finished design, and you're likely to hear that half of it isn't technically feasible, doesn't match the existing component library, or conflicts with something already built. Overcommunicate from the start, and you avoid most of that friction entirely.

This doesn't mean constant meetings or a slow process. It means being intentional about when developers are looped in — early enough that their input can actually change something, not so late that it only creates conflict.

‍

The goal isn't to dictate — it's to integrate

The biggest mistake I see designers make when joining a new team is treating their process as the standard and expecting everyone else to adapt. The goal isn't to walk in and dictate how things should work because you're the designer. It's to understand how the team already operates, align with that, and then find the right moments to introduce better habits.

Teams that work well together aren't following a prescribed collaboration model. They've built trust over time, they communicate openly when something isn't working, and they've figured out a rhythm that suits their specific context. That takes time, but it starts on day one — and it starts with the designer making the first move.