Imagine youre responsible for implementing an app that shows you swanky cafes in your city.
You know how Dave ticks, and you know how this throw in of request usually ends.
But hey, this is your job, so you do your best anyway.
Three weeks later, you go back to Dave with the finished prototype.
It’s free, every week, in your inbox.
According to him, you totally ignored his teams instructions.
Now youre mad at Dave and his team, too.
During those three weeks, they didnt check in with you at all.
Thats not because theyre nasty people.
It takes more than a little magic to turn a prototype into a working product.
There are also developers who dont understand the hard work thatdesignersput in, however.
If it goes totally wrong, the designers will take the shitty product as-is to avoid conflicts.
This may not show immediately, but three years down the road everybody will be frustrated.
Technical debt is a beast, and an engineers lack of experience racks it up to ten times quicker.
Inexperienced designers can be a plague too, though.
This ties back to some designers lack of technical know-how.
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 dont 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 cant succeed on their own because dont speak the language of the users.
How to stop developers and designers from getting lost in translation
Maybe get a translator?
No worries, that wont be necessary.
Also, this maximizes over-the-shoulder conversations and minimizes the need for icky stuffy time-consuming official meetings with everybody.
If product designer Dave isnt sure if a feature is technically feasible, he can quickly ask a developer.
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 jot down of informal dynamic resolves problems before they occur.
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 others craft.
This means that developers may want to enroll in a software design course.
Designers and developers speak different languages.
But if they keep close enough, they start to understand each other.
For designers, envisioning computer code in their day-to-day work is daunting.
Luckily, there are software tools to the rescue.
AnimaAnimais a design-to-code platform where designers (and developers!)
can develop prototypes and export developer-friendly code at the end of the process.
Framer XFramerintegrates 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.
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 cant solve all the friction that arises between humans.
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 dont understand that, thats not your problem.
But maybe youll want to speak to his manager before he speaks to yours.
This article was written by AriJouryand was originally published onUX Collective.
it’s possible for you to read ithere.
Special thanks to Ofir Sever for pitching the idea for this story.
