Product designers and developers don’t always play well – here’s how to work together


Imagine that you are responsible for implementing an app that shows you the fancy cafes 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 works and you know how this type of request usually ends. With a tight schedule and a few sketchy instructions, you sure aren’t going to impress her. But hey, it’s your job, so you’re doing your best anyway.

Three weeks later, you return to Dave with the completed prototype.

And he is furious.

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

Now you are also mad at Dave and his team. During those three weeks, they haven’t checked with you at all.

And now, after weeks of working nights to get the prototype shipped on time, all Dave wants to see is your manager so he has someone better to shout at.

How tension and bad blood arise

As a developer you do your best to avoid conflicts, just like product designers like Dave. Why, then, do such uncomfortable situations keep happening?
Some product designers want all of their detailed and complex products to be ready for the day before.

It’s not because they’re mean people.

Designers like this tend to lack technical know-how on all of the back-end frameworks and manpower needed. It takes more than a little magic to turn a prototype into a working product.

However, there are also some developers who do not understand the hard work of designers. They’ll be careless with design details like alignment or font choices and then blame the designers for making the product crappy.

If things go wrong, the designers will take the crappy product as is to avoid conflict. You can imagine the reaction of the Product Owner when he sees the lousy result of his beautiful idea.

Some developers, especially those who are still inexperienced, also make poor engineering choices that make it difficult to update a design. It might not be seen immediately, but in three years everyone will be frustrated. Technical debt is a beast, and an engineer’s inexperience accumulates it up to ten times faster.

However, inexperienced designers can also be a bane.

If they don’t think carefully about how their design evolves and works in the long run, there’s little that developers can do to correct their flaws. This refers to the lack of technical know-how of some designers. Of course, they don’t need to know everything about software engineering – that would make developers obsolete – but a little know-how goes a long way.
Such knowledge would also help designers communicate their ideas in more detail.

A handful of wireframes, no matter how good-looking, won’t replace the value of a detailed, dynamic, prototype created with the underlying technologies and their challenges in mind.

The moral of the story is this: There are a myriad of ways to upset a designer if you are a developer. And if you’re a designer, there are as many ways as there are fish in the sea to get your ass bitten by a developer.

Basically it comes down to this: Designers and developers talk about different languages.

The designer speaks from the direction of the user. They know exactly how the product should look, feel and behave. But they don’t know how to get there. The developer, on the other hand, knows all the technologies to create things. Okay, not all of them. But some at least. Developers speak with code. But developers can’t do it on their own because they don’t speak the language of the users.

How to prevent developers and designers from getting lost in translation

Maybe have a translator? No worries, it won’t be necessary.

In some companies – the old-fashioned ones that still work in person at least – product designers and developers are seated at the same table. This helps tremendously as both teams can see each other working in real time and learn to appreciate the different challenges they face.

Additionally, it maximizes over-the-shoulder conversations and minimizes the need for stuffy and time-consuming official meetings with everyone. If product designer Dave is unsure whether a feature is technically feasible, he can quickly ask a developer.

Likewise, if a developer is wondering why a particular feature is needed, they can quickly slap the responsible designer on the shoulder. It also works remotely. To make informal discussions more effective, some companies match each designer with a developer. The two can then chat as much as they want. This type of informal dynamic resolves problems before they arise.

If pairing developers and designers is not an option and it is not possible for both teams to work at the same table, the regular check-in schedule may work. This gives developers the opportunity to review designs and designers the opportunity to provide feedback on how development is going.

However, scheduling regular (and often long) meetings that cut down on productive time isn’t everyone’s cup of tea. If teams can conduct such meetings in a pleasant way, nothing is against them. But the success of such meetings strongly depends on the teams and the overall culture of the company.

Finally, developers and designers should learn a little more about each other’s trade. This means that developers may want to enroll in a software design course. Designers may want to know more about the software architecture and programming languages ​​that developers use on the team. Designers and developers speak different languages. But if they stay close enough, they begin to understand each other.

Software tools to fill in the gaps

For developers, getting a lean little wireframe for a complex project and having to code all the details from scratch will take more than an overnight shift. For designers, considering computer code in their day-to-day work is intimidating. Fortunately, there are software tools to help you out.

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. Additionally, designers can bring their prototypes to life more easily than with more traditional design tools, as they can add interactive effects like hover effects, input 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 also integrates with Figma. Whether you use one or the other really depends on your personal preferences.

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

Again, the power of software tools is limited. They can help, but cannot resolve all the friction that arises between humans.

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

Ultimately, we all want happy, productive teams that deliver high quality products and add value to their customers. But this only works if the teams communicate well with each other, have the right tools to work and are rooted in a good corporate culture.

It sounds vanilla, I know.

But so many product designers and developers have horror stories to tell. Misalignments are common because teams speak different languages ​​and operate from different points of view. Both languages ​​and points of view are necessary. To make them work together, they must be involved in each other’s processes. Only then can they begin to understand each other.

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

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

Source link


Comments are closed.