Product designers and developers don’t always play nice — here’s how to work together

Imagine you’re responsible for implementing an app that shows you swanky cafés in your city. Dave, your product designer, has created a beautiful wireframe, and he wants the prototype to be ready within three weeks.

You know how Dave ticks, and you know how this type of request usually ends. With a tight timeline and a few sketchy instructions to go with, you’re definitely not going to impress him. But hey, this is your job, so you do your best anyway.

Three weeks later, you go back to Dave with the finished prototype.

And he’s furious.

According to him, you totally ignored his team’s instructions. You didn’t implement the exact pixels they specified, you didn’t get the color shades perfectly right, and — oh — where are all the special effects?

Now you’re mad at Dave and his team, too. During those three weeks, they didn’t check in with you at all.

And now, after weeks of you pushing overnight shifts to get the prototype shipped on time, all Dave wants to see is your manager so he has someone better to yell at.

How tension and bad blood arise

As a developer, you do your very best to avoid conflicts, and so do productdesigners like Dave. Why, then, do such uncomfortable situations keep happening?
Some product designers want all their detailed and complex products ready by yesterday.

That’s not because they’re nasty people.

Designers like that tend to lack the technical know-how about all the frameworks and labor that goes into the back-end. It takes more than a little magic to turn a prototype into a working product.

There are also developers who don’t understand the hard work that designers put in, however. They’ll get sloppy with design details like alignment or font choices, and then blame the designers for making the product look shitty.

If it goes totally wrong, the designers will take the shitty product as-is to avoid conflicts. You can imagine the product owner’s reaction when they see the ugly result of their beautiful idea.

Some developers, especially those who are still inexperienced, also make poor engineering choices that make updating a design difficult. This may not show immediately, but three years down the road everybody will be frustrated. Technical debt is a beast, and an engineer’s lack of experience racks it up to ten times quicker.

Inexperienced designers can be a plague too, though.

If they don’t carefully consider how their design scales and performs in the long run, there’s only so much developers can do to fix their faults. This ties back to some designers’ lack of technical know-how. Of course, they don’t need to know everything about software engineering — that would make developers obsolete — but a little savoir-faire goes a long way.
Such knowledge would also help designers communicate their ideas in greater detail.

A handful of wireframes, no matter how beautiful they are, aren’t going to replace the value of a prototype that is detailed, dynamic, and created with the underlying technologies and their challenges in mind.

The moral of the story is this: There are myriads of ways to upset a designer if you’re a developer. And if you’re a designer, there are as many ways as there are fish in the sea to make a developer bite you in the ass.

Fundamentally, it boils down to this: Designers and developers speak different languages.

The designer speaks from the direction of the user. They know exactly how the product should look like, feel like, and behave. But they don’t know how to make it happen. The developer, on the other hand, knows about all the tech to build stuff. Ok, not all. But some at least. Developers speak with code. But developers can’t succeed on their own because don’t speak the language of the users.

How to stop developers and designers from getting lost in translation

Maybe get a translator? No worries, that won’t be necessary.

In some companies — those old-fashioned ones that still do in-person work at least — product designers and developers sit at the same table. This helps immensely because both teams can see each other working in real-time and learn to appreciate the different challenges that they face.

Also, this maximizes over-the-shoulder conversations and minimizes the need for icky stuffy time-consuming official meetings with everybody. If product designer Dave isn’t sure if a feature is technically feasible, he can quickly ask a developer.

Likewise, if a developer has questions about why a particular feature is necessary, they can quickly tap the responsible designer on the shoulder. This works remotely, too. To make informal discussions more efficient, some companies pair each designer with a developer. The two of them can then discuss as much as they like. This type of informal dynamic resolves problems before they occur.

If pairing developers and designers isn’t an option, and it’s impossible for both teams to work at the same table, scheduling regular check-ins may work. This gives developers the opportunity to review the designs, and the designers the opportunity to give feedback on how the development is going.

Scheduling regular (and often long) meetings that cut into productive time isn’t everybody’s cup of tea, however. If the teams can conduct such meetings in an enjoyable way, nothing speaks against them. But the success of such meetings depends highly on the teams and the overall company culture.

Finally, developers and designers should learn a little about each other’s craft. This means that developers may want to enroll in a software design course. Designers might want to learn more about the software architecture and the programming languages that the developers are using in the team. Designers and developers speak different languages. But if they keep close enough, they start to understand each other.

Software tools to bridge the gaps

For developers, getting a skimpy little wireframe for a complex project and having to code all the details from scratch will take more than an overnight shift. For designers, envisioning computer code in their day-to-day work is daunting. Luckily, there are software tools to the rescue.

Anima
Anima is a design-to-code platform where designers (and developers!) can develop prototypes and export developer-friendly code at the end of the process. For developers, this code is available in various popular frameworks, such as React, vue.js, and html. Plus, designers can bring their prototypes to life easier than with more traditional design tools because they can add interactive effects like hover effects, entrance animations, GIFs, and more.

Framer X
Framer integrates with Figma and, like Anima, helps designers make static elements alive and dynamic. That being said, Anima integrates with Figma, too. Whether you use one or the other really boils down to your personal preferences.

Handoff, Visly, Modulz, and more
There are plenty more design tools out there that transform prototypes to code. However, there is one problem with most of them: They don’t address the dynamic part of prototypes like Anima and Framer. This leaves a lot to the imagination of the developer in charge. In other words, it leaves a lot of potential for conflicts on the table.

Then again, the power of software tools is limited. They can help, but can’t solve all the friction that arises between humans.

The end goal: Good tools, good people, good culture

At the end of the day, we all want happy, productive teams that ship high-quality products and bring value to their customers. But that only works if the teams communicate well with one another, have the right tools to work with, and are embedded in good company culture.

This sounds vanilla, I know.

But so many product designers and developers have horror stories to tell. Misalignment is common because the teams speak in different languages, and operate from different viewpoints. Both languages and viewpoints are necessary. To make them work together, they need to be involved in each others’ processes. Only then can they start understanding each other.

Software design and development can rarely be done by one team alone. If the Daves of this world don’t understand that, that’s not your problem. But maybe you’ll want to speak to his manager before he speaks to yours.

This article was written by Ari Joury and was originally published on UX Collective. You can read it here. Special thanks to Ofir Sever for pitching the idea for this story.