5 Soft Skills Every Product Designer Should Master
I once asked a friend that works for a big name design company what he looks for in potential hires? He said that he hires people with great communication skills and who trust in their process over designers with a stand-out portfolio. He explained further that when things get tough at work, the last thing you need is someone who can’t communicate clearly with others and get aligned on goals.
He is right. You can have a great portfolio, but more than anything, your communication skillswill make you stand out from the crowd. As designers, you are told to develop skills such as empathy, design thinking, critical thinking, how to do research, etc. But fewer people talk or write about how you also need a different kind of skill set to succeed.
Confidence, discipline, and good communication are essential soft skills designers should strive to develop, and there are a few specifics within these traits that I’ll elaborate on in this article. Keep developing these soft skills, and you’ll be well on your way to impressing both hiring managers and clients alike.
It doesn’t matter if it’s your client, partner, product manager or developer:
Always over-communicate your project requirements, business goals, work process, product vision, and so on.
Keep in mind, there’s a significant difference between communicating and overcommunicating. When working on a complex project — especially if you don’t have enough people or you hired remotely — the last thing your team needs is to have to guess what you mean by saying “x”.
You must be consistent with your communication. People forget and deviate quickly from what they heard a week ago. At least once a week, remind them what the business/product goals are, what the plan is if things go wrong, and what to look out for.
Quick tip: If you think that the information is trivial and your team will figure it out, they won’t. Write it down or say it.
The same applies to your design process. People don’t know what you do and how it works. Always explain and (re-explain) what you are working on so others can trust you.
During my first job, I was asked to redesign the company product dashboard and present it to the entire team. Fifteen minutes into the meeting, I lost control of everything. People began throwing in their opinions, criticisms, and a market talk began. Later they dropped the project, and I was back to just listening in on meetings again. This happened because I did not trust myself. I thought I was faking it.
Most designers aren’t confident in their value. Every other designer deals with impostor syndrome regularly. But just because coming up with solutions comes naturally to you, doesn’t mean you’re cheating clients because it’s an easy job. Don’t doubt yourself. Trust yourself.
This doubt is going to be reflected in your work. When you present a project to someone, you will easily get carried away with other people’s opinions and criticism. Because you don’t trust yourself, you won’t be taken as seriously and you’ll be seen as the “person who pushes pixels” or “makes it pop”.
The biggest losses in my career happened because I was unable to ask the right questions. When I was just starting out, I couldn’t understand why designers weren’t taken as seriously at companies when it came to high-level decision making for products. I worked at several startups, and the attitude was more or less the same — after the management team defined the path and solutions we needed, they came to the design team for the “candy look”.
A couple of years later, I understood that if we change the conversation from, “Ok, I will get right on it” to “Sure, but what business problem are you trying to solve? Will the change achieve the goal?”, we can start to reframe the perception of our role as designers. Asking the right questions will only make you a better designer and will help you lead a proper business conversation. And with time, patience, and constant hard work, you’ll get that seat at the table.
The type of questions UX designers ask during interviews says a lot about the state of the field. They are rarely specific, actionable, or practical. Lots of expert quotation, too little problem definition and hard thinking. Too much of ‘How can we be taken seriously?’ and too small talking about the work— Ryan Singer, Head of Strategy at Basecamp
What questions to ask?
When you define a problem, never accept it at face value. Instead, try to uncover what the real problem is — the problem behind the problem — by asking a few questions:
- What is the main problem we are trying to solve?
- Is this the right problem to solve?
- Is it worthy of our best efforts?
- What other problems could we solve that would bring more value to our customers than this?
- If we don’t fix this, will our product fail?
- Will this bring us closer to our product vision?
Then confirm the problem:
After you discuss the issue in general terms, now it’s time to put some indicators behind it and align it with your business goals.
- What are the business goals?
- Which business goal(s) will the problem solve?
- What do the stakeholders think about the idea/project ahead?
- What are the measurable KPI’s for those goal(s)?
- What is the value of those goals to the business? (money? more time to do N things?)
- How will we know when we achieve the main goal(s)?
- Are there enough resources for this project? If we need more time, will there still be enough?
- What are the risks and problems we have to overcome?
- Have you accounted for the opinions of all other departments that will be affected by your end product/feature/UI change?
You get the point.
The most important qualities I am looking into a person when hiring them is their ability to speak clearly and communicate their thinking process. How did you come to that result? Recently when I hired a designer for a temporary job, I saw an eCommerce project in her portfolio. I asked her why she designed the checkout this way? Then I asked her:
- Can you tell me what you think about your solution and why?
- Why should we listen to you?
- What brought you to that conclusion?
- Did you consider alternatives? What are they?
- Why are they not good enough for us to care?
- Can there be consequences to this solution?
- What do the users think about it?
- Did you talk to them? Personally?
Because she could answer all of them, I got a better sense of how she thinks and hired her. These are the type of questions almost anyone has when you present your work to them. The broader and deeper you go with your answer, the better.
People trust others whom they know. To know someone, you have to see and hear how they think and act. So remember, the more effectively you can communicate this to others, the more trust you’ll gain.
We live in a world where every decision is data-driven which means we are less likely to rely on our intuition. Making decisions based on intuition is often considered reckless — subjective. But if I had to choose between trusting myself or having a data set tell me which feature to design next, I will go with my gut.
Don’t get me wrong: If data shows that customers are not satisfied with my product, I will listen to them and look into it. But when you design a feature just because “X” people requested it, that’s when things get reckless. Why? Because you can easily deviate from your product vision and bloat up your product with unnecessary clutter — which will only drag on your roadmap for months and months.
I worked with a client who couldn’t change anything about their product because their roadmap was full of features that needed to be implemented in the next year and a half.
Here is where the ability to trust yourself and communicate comes into play. When you believe in your approach, you also have to describe what led you to that thinking. Explain why it’s not a good idea to follow the data. Explain, show, and prove.
“The final look of anything is the by-product of the clarity (or lack of it) during its design phase. Clarity of intent will translate into clarity of result.” — Massimo Vignelli
If you leave with only one thing from this article, remember this — a messy mind will result in a messy product and communication. Always try to remove the clutter from your thinking because it will impact the result. Stray away from using too much jargon, complex writing, talking only to sound smart, and bloating your product with useless features.
- Always be concise
- Write and talk always on point with others (whether it’s through your website copy or when working with a developer)
- Always overcommunicate and if needed, repeat
- Ask good questions and be ready to answer them too