or How to get along with Product and Engineering folks and improve productivity

A couple of weeks ago, during a product, engineering and design sync where we were closing the scope for our next product iteration, a pleased colleague asked me with a sincere smile “Are you sure you are a designer?”.

I’ve been getting some variations of this comments over time “It’s nice that you don’t sound as a designer”, “Is your background technical?”, “Were you always a designer?” or, my absolute favorite, “I like that you have a pragmatic mindset, it’s just so easy to talk to you because you don’t focus only on the pixel”. These questions/comments were all meant as compliments and often are said when several individuals from different disciplines are discussing visual solutions meant to combine with constraints from desired technical approaches, while also meeting product opportunities.

It is often true that, as designers, we are used to communicate in pixels. I, personally, struggle to communicate without the support of sketches. Back in the days, where multidisciplinary teams were not a thing, communication was not an issue since designers worked in designers-only tribes and we only received tickets from engineers — sometimes we didn’t even knew who they were in person! — and we quietly designed in our isolated office rooms and delivered perfect pixels without major discussions. (Well… not quite, but I assume you get the ideia here). Designers and engineers didn’t fit together in the same spaces. Can you imagine? In the first big tech company I worked with, designers where even in a different building, far away from developers! Communication was not a major issue, because it was not frequent.

When people work in silos, it is natural that they don’t feel the need to speak the same language between silos, but this often led to an “us versus them” approach, because it was the reality back then: designers were part of “design teams” and developers were part of “engineering teams”. Product people were nothing more than engineers that wrote requirements, and requirements were, in fact, technical or functional translations from conversations they had with business people that had heard some news, from their friends, who were other business people, from other companies. No user-centered digital products, only feature driven software to beat competition faster.

Of course designers stepped up and decided to skip the “receiving requirements part” and, in the golden age of UX, designers started to observe the use of the product themselves and eliminated the bias of “requirements phase”. A lot of entropy was cut off, but then, designers would comeback with the collected data and they would lock themselves designing a pixel perfect solution that would fix the observed problem, ignoring if it would be feasible. After the solution was handed-off, they would fight to death with engineers for that solution to be delivered, because “data said so”, but, only in that moment, they would present the data to the developers, with an “in your face” attitude. So, the problem still persisted: inability of different disciplines to have common ground on communication. Then “the agile era” rose, but it also did not shine: it helped with interactions over processes but, as all cults that are followed blindly, it lacked understanding of how all the disciplines should interact to become a team with people that trusted each other, ending up with a lot of things getting lost in translation and with augmented friction.

I am glad that those days of process and methodology friction are over. Nevertheless, regarding communication, I sadly observe that they are not. I still see so many designers living in this loop of “us against them”… It is easy to communicate with people that share a similar mindset, that have the same references and that are used to the same ways of communicating that we are. (…and I am just mentioning disciplines and not even adding the cultural aspects in this article!)

Good communication is the basis of trust. Trust is the condition for a group of people to become a team. If we don’t understand each other, we will not trust each other and we will never be able to abandon the “us versus them approach”.

A key skill for every professional, especially designers, is to know how to effectively work everyday alongside people with different skills, practices, mindsets and communication styles. So, for me (having a background in UX Research), it was key to start understanding my colleagues’ reference models so I could effectively communicate with them.

In addition, I acknowledge by these comments I received, that our fellows from other disciplines were/are having a hard time to communicate with us, designers. Therefore, here is an unasked, yet hopefully life-changing, advice:

Focus on pushing a communication centered on pixel perfection is nice, since quality of the solution is important — it really is! — but, focusing on a communication centered on ideas flowing effectively, so we can move forward, and add value earlier, it is outstanding!

Now, that’s a fancy medium phrase!, but, how do we stop focusing conversations on pixels and start focusing on effectively moving forward, towards alignment/consensus/implementation/development?, you may ask.

Well, I have no magic potion, but I can tell you what worked for me.
First, I started with a unconventional approach and decided to play a game of interpretations. I drunk a dose of humility and chose the most positive interpretations of each setback I faced that, in te past, I had labeled as “against design approach”. *

It was a major effort of mine, but after recognizing that I had a lens that negatively amplified and biased the whys and intentions of others regarding my design approach, I tried to open my mind (and heart) so that I could deeply understand that:

• Engineers are not against the Design approach, they have valid technical concerns about it;
• Product Managers are not blocking the importance of tackling UX debt, they really have more important strategic opportunities to prioritize at the moment;
• Stakeholders are not against research and testing wireframes with users, to gather data to make better decisions, they are simply trying to push designers to trust and speed their work because designers already use UI patterns that are very well known by the users.

Some people call this “cultivate empathy.” I like to call it “take off the whining lens and act to change your point of view”. 🤗

Secondly, I tried something that is absolute key for communication and I dare you to try the same: listen. If you communicate what you think, and what you think is what you are, then we should all become listeners. Listening has become the most important part of my communication.

Listening helps me to absorve the messages, organize and comprehend what I receive and think about the value and clarity of what I will answer.

What you need to do is to listen three times:

• Listen to understand.
• Listen to unblock.
• Listen to align.

Focus on the pixel later. Focus on your agenda later. Focus on being listened later — please, absolutely stay away from the “non-designers need to be educated regarding design, so they are the ones that need to listen” approach. 🤢

“Ok, I will listen three times.”, — you are now saying — but:

How to effectively listen to people?

With interest! Learn about them! Learn about their references, about their mental models. Ask them questions. Read what they read. At least that’s what I did. I was concerned about inefficiencies on my communication, so I asked several people I work with for book advices and what were their favorite reads related to their practices.

I got a bunch of great suggestions, but, to simplify I would advice any designer to try to read this three books (product, engineering and research related) and I will promise that changes are going to be noticed.

In summary, you need to follow three steps to improve your communication:

1. stop complaining and acknowledge your bias;
2. stop talking and start listening;
3. learn about other people and focus on mutual understanding.

Also, since communication happens both ways, I truly and deeply, advise people from non-design disciplines to do the same.

You know… honestly, we don’t really have to think and talk the same, that is not the point about diversity!! What we really need is a way to understand, accept and trust each other. And, for that, establishing a good communication is key.
So, for non designers, please start making an effort to learn our language too, instead of only making remarks on how engineering-like or product-like our communication is. I know you mean well, so thank you!, but ultimately it makes you look and sound like inflexible people that only know how to communicate with like minded and it perpetuates the “us versus them” approach that I am trying to eradicate. Please take a moment and reflect on how non-inclusive that behavior, although well-intentioned, is. ❤

I couldn’t be happier that I decided to deconstruct my beliefs, and fight some of them, in order to invest on getting to know my peers from other disciplines and their references, instead of “everyday is fight-with-Engineers-or-PMs day”. There is still too little time to say that I am being successful at getting design a proper seat at the table, but, so far, I realize that we now work in a more organized, harmonious and aligned way. Together, we are able to brainstorm, discuss and ideate with clear improvements in the way we communicate and we are getting better on converging into a solution that is both right, feasible and delightful. Isn’t this the definition of “happy at work” for designers? 🤗

* I need a pause for a complete rant here , [you can skip this part if you wish] — if you are someone interested in data driven decisions, could you please do yourself a favor and try to quantify the amount of time spent by you, your design leaders or your design colleagues in complainingabout non-designers that questioned your approach and that you quantified under “against design / lack of design maturity” ? I dare you to think about measuring that much time you’ve spent playing the victim of the context, with an inability to provide a real solution, nor to have the impact you idealized in your head. Think about where that kind of behavior led you and your teams/colleagues but an “us versus them approach”. — end of rant, thank you for reading this.