Transforming The Relationship Between Designers And Developers — Smashing Magazine

The Real Cost of Design-Developer Friction

After two decades of ever-evolving design tooling, methodologies, and workflows, one constant remains: the friction between the people who design products and the people who build them. Clients still request bigger logos, designers wince at six pixels too little bottom-margin, and developers still brace themselves for late-stage changes.

This isn’t just an annoyance. The way design and engineering partners relate directly shapes the product you ship. Missed context and minor misunderstandings accumulate into micro-inconsistencies that customers feel but QA never catches. By the time you discover these in user research, you are already playing catch-up, bleeding time and money in a race against your competitors.

The solution starts before a single design mock or line of code. It starts with the culture of the team itself.

Laying the Cultural Foundation

Process tweaks will only take you so far. The working culture determines whether design and development teams thrive together, and there are three pillars holding that culture up:

• Alignment on goals. Teams need to share a definition of success for the project and for the business.
• A “robotic” attitude to feedback. Passion is fine, but feedback should be processed through logic before emotion. This does not mean dulling enthusiasm; it means building a reflex to step back and assess before reacting.
• Proactive communication. No process catches every edge case. You need people willing to flag issues and poke each other when something feels off.

Common sense as it sounds, plenty of organizations operate without this foundation. And if you think your own team already has it, check. A one-to-one chat with each member of the team, or a short questionnaire, can uncover gaps you never noticed. Treat the criticism you receive as valuable; it is information that puts power back in your hands.

Once established, that foundation needs protecting. Keep reviewing it and consider how well potential new joiners would fit it. That brings us to hiring.

Hiring for Empathy

Scaling a team rarely makes collaboration easier. To protect your culture as you grow, screen for empathy and positivity during the interview process. Both the developers and designers you hire need to respond to tension with curiosity, not defensiveness.

To probe that, show candidates a screenshot of your product and ask a role-specific scenario:

For a developer candidate

“You’ve just built X, and the designer wants to change Y. How do you respond?”

Follow up:

“The designer and PM reject your suggestion because of _______. How do you respond?”

For a designer candidate

“The developer says, ‘We can’t build X quickly; can we do Y instead to deliver faster?’ How do you react?”

Follow up:

“The product owner says they are then disappointed with the design. How do you react?”

Ask these midway through the interview, after you have built some rapport. At ease, candidates are more likely to reveal real attitudes. Many will openly stereotype the other discipline or recount frustrating past scenarios with visible irritation.

Technical skill and work ethic still matter most, so a shaky answer here is not automatically a rejection. But it flags something to work on—or watch—if they join the team. In many cases, the stronger candidates respond to these character tests with balanced, thoughtful answers naturally.

Involving Everyone Early (and Staying Involved)

For teams already in the middle of tension, the cure is to break the silos between disciplines. A developer joining only after designs are final will have ideas that arrive too late to matter. A designer who disappears after handoff never sees how their product lands, or gains the user feedback that should inform the next iteration.

There is no single right workflow, but there is a common non-negotiable: early and ongoing collaboration. This takes several shapes in practice.

Scoping as a Team Sport

Feature discussions too often involve only stakeholders and a product manager. Designers and developers need to be at that table from the beginning. They contribute original ideas, visualize concepts quickly, connect proposals to other parts of the domain, and occasionally block a genuinely bad idea before it gains a foothold.

It can be hard for developers to mentally step out of the current sprint and think ahead. But their guidance at the scoping stage saves the entire team far more time than it costs them.

Dave Clarke, product manager at SquaredUp, describes how that team folds engineering input into the process:

“Developers are looped in during the design stage, and we’ll test interactive mockups with the engineering team as well as other internal stakeholders before going out to external audiences for feedback. This means that when a feature is ready to be built by an engineer, they’re already really familiar with what we’re building”

— Dave Clarke

SquaredUp goes a step further by keeping that collaboration alive from the very start; engineers attend events to hear customer pain points first-hand. That shared context is exactly what the cultural foundation is built on; everyone gains a genuine understanding of the user and comes at the problem from the same side.

Design Presentations: A Forum for All

For teams iterating on the next big thing, a design presentation for the entire team serves as a crucial touchpoint. It is a session to see a proposal in full, question the details, offer alternatives, and sketch how a design can be sliced into smaller releases that deliver value faster. When designers and stakeholders agree on a design in isolation, developers are left with lower-quality output and a feeling that their perspective does not count.

For designers, it is also a release, because it allows them to present a complete product vision rather than just a single screen. Let the designer set the pace: some will prefer fielding questions throughout and adjusting live; others will want to present straight through and take questions at the end. Both formats can work.

Give the ritual a name of its own. It all depends on team culture; one squad calls it Design Time, while a colleague’s cheeky poll entry resulted in the Itty Bitty Refinement Committee.

Facilitation and Conflict

Design presentations carry the risk of veering off course. A clear agenda and a firm facilitator keep them moving. When conflicts do surface, look outward for resolution rather than arguing tastes. Where can the data live?

• Is there an answer in our analytics?
• Which option best serves the company goals on the table?
• Can an A/B test settle which approach is more effective?

Acknowledge new ideas positively and promote deeper exploration. Some discussions resolve in minutes, while others need to be tabled for a future refinement session. The important thing is that all voices stay in the room and out of their silos, all the way from scoping to release.

Shared ownership: the gray areas that fall through the cracks

Between design and development lies a gray area where responsibility often goes unclaimed. In many organizations, this ambiguity means essential aspects of a product are simply forgotten. Two areas seem especially prone to this, though the list is hardly exhaustive. It's worth asking whether anything else in your own organization has slipped into this void, and then agreeing on a way of working together to address it.

Animations

Most development teams today work on JavaScript-heavy applications, and CSS transitions are widely available. Yet it's still common to land on new projects where animations aren't being used to enhance the customer experience. Animations can be time-consuming to create in design tools — loading states especially are often fiddly to prototype.

At Floww, I collaborated with designer Hidemi Wenn on an animated progress bar. Hidemi had started with an idea in After Effects, and I replicated it in a CodePen, suggesting we add bubbles to highlight changes in the numbers.

This let Hidemi see her creation working in the browser early, before it was fully implemented into the product, and we then collaborated further on enhancements.

"Working together like this was awesome! We could easily bounce around ideas, and tweaking the animation was a breeze."

— Hidemi Wenn, Product Designer at Floww

The tools for collaboration are better than ever, yet many designers and developers still choose to operate in silos.

Accessibility

One of the first things I do when joining an existing digital project is run Wave, an accessibility testing tool — and then slump into my seat in despair. Accessibility is something that always suffers when designers and developers stand off. Some claim it belongs to the realm of design; others would argue it's quite technical and lives in dev land. The truth is that it is a shared responsibility.

Take :focus, for example. It's always the first thing I check when reviewing code, and it's often missing. Ask the developer, and they'll say: "We didn't have designs for it." Well, perhaps ask the designer to create them, just as I'd expect the designer to query an unimplemented state they had designed for.

Reverse-design presentations before release

As implementation winds down and a feature approaches release, developers should stage a reverse-design presentation. When mentoring developers on this, I always remind them not to take the feedback personally. Likewise, I ask designers never to hold back — to be persnickety, in a kind way, and make sure all their concerns are addressed.

It's natural for a developer to behave defensively in these scenarios, and designers may hold back feedback to avoid upsetting them. Developers are often vocal, and delivering a barrage of design feedback can seem daunting. To prevent the silo, consider having a third party — such as the product owner or manager — attend the meetings; they can diffuse tension by referring everyone back to business value.

I've also seen rare cases where a developer nodded and agreed with all the feedback, then never implemented any of it. Make sure all feedback is captured in your project management tools so it can be followed up. Sometimes, when changes are small and frequent, we create a single ticket on the board to implement all feedback changes rather than creating a work item for each.

Another common issue: many designers never actually test the products they design. They're missing out on the opportunity to hone their work and learn. If you're a designer, ensure you can log in to the app or website, get a test account, and try to break things. Once all feedback is in, you can create work items for those finishing touches and ship the masterpiece.

Design systems as a relationship tool

Focus states, mentioned earlier, likely made you think of design systems. A design system plays a key role in maintaining consistency and ensuring accessibility is baked into the component library. There are many articles on the subject; here, the focus is on how it affects the working relationship.

Because a design system encourages reuse, it encourages thinking about other teams in the organization and being more mindful. If the basic building blocks are covered, teams can focus on solving more complex challenges together — getting teams on board with this value is important.

Design systems can also cause friction. Some designers feel restricted creatively; some developers are frustrated at having to update the design system instead of working on their own features. These attitudes not only slow you down but can harm the working culture. It's crucial for any product team, big or small, to have a design system that the majority buy into. I've seen organizations neglect their design system, and that ends up worse than not having one at all — some people go off-piste and keep reinventing the wheel (probably without focus states).

The GOV.UK approach

The UK's Government Digital Service has built a design system serving a vast spectrum of services and tech stacks — an enormous challenge. Product designer Ed Horsford, who has worked on government services using it, explained the approach.

"GDS provides the GOV.UK Prototype Kit, so as a designer, I can create something in the kit, make full use of the functionality of the design system, and point developers towards the prototype."

— Edward Horsford

Many organizations use tools like Figma's Dev Mode for handover, but this requires naming conventions to be aligned between codebase and component library. What's impressive about GDS's approach is that the provision of its own prototyping tool makes it clear to developers which components to use. However, good tooling doesn't always guarantee smooth outcomes, as Horsford explains:

"It can be a bit of a mind-shift for developers new to the UK government or using design systems in general — they may default to hand coding the HTML and CSS to match a design, rather than using the components from the design system to match the prototype."

"If there is a bespoke requirement outside of the design system, then I will always call it out early so I can discuss it with the team."

— Edward Horsford

This again comes back to communication. As a designer, Horsford was actively looking at front-end code to assist the developer, ensuring the design system was respected so its benefits were embedded in the product.

When the relationship breaks down

Much of the advice here requires planning and trial and error. What if your designers and developers are already in conflict? Pause and ask each team member: What is our goal? What are we working towards?

If people are angry, in some ways that's a good thing — it means they care. People who care should be open to a reset. Discuss openly what everyone wants, and you'll likely find how aligned people really are. Sometimes we get so tangled in details that we forget what's truly important.

The greater risk: apathy

For every angry team, there are probably many more that just don't care — a far worse situation. Every problem described in this article could be present. Designers make mockups, developers build them without question, everyone gets paid. Who needs to question anything?

Fixing this requires a much deeper dive into company culture to revive team spirit. I've worked at places like this, and it's challenging to implement solutions when people aren't bought into the organization's vision. Whether this is feasible depends on your role and the organization. I've walked away from situations where the organization was unwilling to change or even acknowledge the problem.