5 Habits Of Product Designers That Piss Off Developers

Many of you praise the UI, UX, and overall simplicity of Peerlist. But that could not have been possible if I had continued following bad habits while building Peerlist as a product designer.

Yogini and I recently talked about improving the design and engineering process here at Peerlist, as a few new folks are joining our team soon. And one of the most critical pieces of feedback I received from her was that I am not clearly communicating the design scope of a feature we build, which annoys her and other developers. Even if I have genuine reasons to tell them why it happens, it won’t change the outcome of pissing them off and sometimes missing the deadlines.

After introspecting myself, I realized that every one of us has to unlearn a few bad habits. During the 9+ years of my career as a Product Designer, I had to unlearn many things to improve myself as a team player, collaborator, manager, leader, and, most importantly, a designer. I just listed them so you can avoid them, and they might help you become a better Product Designer.

1. Not involving developers early in the design process.

This is a mission-critical mistake one can make as a product designer. Involving developers early in your design process will help you refine your workflows by identifying and rectifying apparent design mistakes.

Imagine, in a design handoff meeting; the developer tells you your design will break in different browsers even after being adequately developed. But suppose you show them your early mockups and ask for feedback at the beginning, and they enlighten you with this information 😃. You could have saved so much time!

In this case, one of the biggest problems is that developers often have no idea what they’re getting into when they start working on a new project and read through wireframes or mockups.

Involving developers early in your design process can even remove the need for developer handoff meetings.

At Peerlist, we don’t have developer handoff meetings because they are involved in every stage of the process, from brainstorming to designing to measuring the outcomes.

2. Not taking developer feedback.

Let’s accept that engineers are the most crucial stakeholder. Getting their feedback is essential because they are your first users; they find the edge cases in the workflow, which no one can. So listen to them carefully. Developers play a significant role in creating a better user experience for your product.

If they suggest making something different than what you have designed, ask them why they think so and why they feel that way is better. You may be surprised by their answers!

3. Using lorem-ipsum in design.

I am personally absolutely against using dummy lorem ipsum content in your design. Do not design with dummy text! I have written a small article around this: Lorem Ipsum is for Amateurs

Your design should have the final content developers will copy and paste into their code while developing. For example, all the button labels, input labels, help text, error messages, and other copies should have actual content.

Having final content in design saves a lot of time for developers and avoids spelling mistakes. Some might argue that it’s just a tiny change. Well, for you, yes. But, for developers, it’s not. They have to make the change, commit the code, create PR, merge the PR, deploy it to staging, then it goes to the production environment. It’s a long and lengthy process!

You, as a designer, can take care of this by involving a product manager or UX copywriter to help you with this.

4. Unclear Communication.

“We build this because users want it” won’t work every time! Communicate the hypothesis behind your design decision as straightforwardly as possible.

Communicate the WHY!

Another essential part of communication is clearly defining the rules that specify when a design is ready for development. Clarity here will help prevent situations in which the development team receives an unfinished design. Clearly define the definition of “done”!

5. Unorganised design files.

This is from my personal experience 😢

An unorganized or unhygienic design file can lead to developers’ frustration. Keep your design files neat and well-organized. Remove/move unnecessary artboards from the files, which has nothing to do with developers. They don’t need to know how many iterations you did before landing on the final design.

If you have a design system in place, designers and developers should know how to name individual elements, components, and variables in a design system.

Closing note:

Many people praise the user experience and simplicity of Peerlist as a product. But trust me, Yogini and other engineers contribute equally to the product’s overall experience. One of the most important lessons I learned in my life as a product designer is that;

Make developers your best friends, and they will help you become the best designer.

And don’t forget to join and follow me on Peerlist.