Hi, it’s Arek! Welcome to Fundament, a newsletter that enables growth in UX and product design. Not subscribed yet? Join for free now:
During the last decade, I’ve met and cooperated with a number of designers and done a healthy amount of recruitment. I can clearly tell the difference between a good and a great designer. By that, I don’t mean what they show in their portfolios (technical skills) but how they cooperate with other team members and stakeholders, present and defend their ideas, and balance different priorities (soft skills). Soft skills are super important to master if you want to grow and eventually become a great designer. Let’s explore the top five soft skills for product designers.
Presenting your design
As your work doesn’t end in a drawer, nor it’s a piece of art hung in a gallery, you need to collaborate with other people to accomplish your tasks. These people could be either your team members, stakeholders, or customers. You are required to discuss ideas and designs with Software Engineers, other Product Designers, and Product Managers daily. All these people will have to understand your big idea and how it solves the design problem.
Software Engineers use code to bring life into the design mockups. If they understand your design well, they will be able to align the technology better, so the final product is more consistent, reliable, and performs well. Also, the better the understanding between the team members, the easier the implementation in general will be. There will be fewer back-and-forth questions and misunderstandings.
It’s absolutely crucial to have a buy-in from Product Managers and other stakeholders. This is important because they are usually the people who give the projects a go or a no-go. If they subscribe to what you present early, the chance of getting a green light is much higher.
Tips for presenting design
Present in person.
If possible, gather everyone who has to see your project in one room or on a Zoom call and present the design by yourself. Don’t just send the link to your Figma prototype or a slide deck. This might be especially helpful when trying to convince stakeholders. It’s good to show yourself as a person who’s behind the idea. Also, you can respond to the questions or dispel doubts when you are there.Tell a story.
According to Hubspot’s Ultimate Guide to Storytelling, “storytelling can impact human emotions. It can also lead people to accept original ideas or encourage them to take action.” There are a few ingredients of a good story: a character (you), a conflict (decision), and a resolution (final idea). Remember that a story must be well-structured (design process).
Defending design rationale
So, you just presented the designs to the forum using the tips from the previous point. But the meeting is not over yet. Some folks decide to roast what you just displayed. You can’t bend over after the first punchline. You must prove to them that you know what you are doing and why you made your decisions during the design process.
Tips for defending design rationale
Bring data.
When the team asks why your design will work best, show them data. I hope you explore different solutions not only by thinking about them but also by testing them on users. Show how different ideas performed in the sessions of usability testing, card sorting, or any other UX research method that applies to your task. Bring the numbers from other studies that might be relevant.Be a team player.
You are an expert in your field, and you might think that some people in the room have little or no idea about design. That’s fine, but try not to be a douche when they give you feedback. It’s essential not to become dismissive of feedback. Instead, take the time to listen to concerns and consider alternative perspectives. You might initially not understand other people’s perspectives, but their feedback can be helpful.
Balancing the needs of users, business, and technology well
We have been taught that our job as designers is creative problem-solving. This is true, but not only: we are also educators, advocates, and negotiators. We are constantly trying to make the three parties equal:
Stakeholders and customers want to ensure they are not burning money on the project and, over time, it will return them some. The worst thing they can do is force the product team to deliver a particular feature because the competition already has it or they think it’s necessary.
Technology, which is the apple of Software Engineers’ eyes, can be a constraint, too. Depending on the stack, the complexity of the proposed solution, and the budget, some ideas might never see the daylight. Sometimes, the original solution has to be modified to be implemented.
Of course, the users, whom we as designers should advocate for, have certain goals, and they use our products to achieve them. That is all correct, but don’t get trapped into the thinking that they are the holy grail. If you ask them what they miss in the product, they will provide you with endless feature requests. Most of which won’t be worth building.
What can you do to make everybody relatively happy? Prioritize and communicate. There are many brilliant prioritization techniques, but let’s focus on the easiest one — The value vs Complexity Quadrant.
Value vs Complexity Quadrant
All you and your team have to do is quantify a task's business value and complexity. Ask yourself: will this feature contribute to our product’s success in a specific moment, e.g., will it bring us more users or increase customer satisfaction metric in the next quarter? Give it a number on a scale of 1–5, where 1 means no business value and where 5 means high business value. Secondly, estimate how complex the task is to implement it.
Low complexity and the highest business value items are your quick wins. Things that require more time to build but still can have a high impact are potential features worth the effort. High complexity and low business value items are time sink features, things not worth doing. Low complexity and low business values items you can treat as maybes. If your team has enough capacity, you may want to make a bet and try building one of these.
Putting ego in your pocket
I just advised you to defend your ideas and not be a jerk while doing that. But what if your idea is not being the best one?
Just use other team members' ideas as inspiration to iterate on your ideas and elevate the design to the next level. Don’t get upset or discouraged if you don’t think through all the aspects of a feature you are working on right now. It happens all the time. For example, when a software engineer points out that a particular element could be done differently so it would speed up the development and increase usability, you should modify the designs accordingly and thank them for an incredible piece of feedback.
I’m pretty sure you don’t need to be reminded about this, but just in case, you don’t design for yourself but for your users. Never forget about that. They will eventually use and evaluate your work. Don’t use this shade of blue because it’s your favorite. Use it because it makes a great combo with white, and it’s compliant with WCAG. Don’t use this font family because you just discovered it and think it’s great. Use it because it has great readability and a positive impact on usability.
Giving and receiving feedback
Feedback is a gift. Whether positive or negative, there is always a lesson you can learn from it. It’s pretty easy to accept positive feedback. When other team members love what you present, you will feel you do a great job. But what if they don’t like what you show them? How do you deal with negative feedback?
Tips on receiving feedback
If the feedback is negative but constructive, you can discuss it and iterate your designs based on this discussion. Always remember not to act like the smartest person in the room. Use such feedback to improve your designs.
If feedback is negative and not constructive, e.g., someone says, “I don’t like it!” — how do you behave? Ask for clarification. Don’t try to defend yourself or get into an argument. And definitely, don’t strike back. Try to get into this person’s mind and understand what is wrong and why they don’t like what you presented. If nothing works, the best option is to respond with “Thanks for your feedback” in a calm voice.
Tips on giving feedback
Only constructive feedback matters, so let’s learn how to give such. If you are a senior designer and provide feedback to your less experienced colleague and you know what can be improved with their design, don’t just tell them the final solution. Start with expressing how it makes you feel. Be clear and to the point. Say what works and what does not, but do not suggest the solution. Ask them if they feel the same way and how they think their design’s weak points could be eliminated. They will learn much more if they develop a better solution by themselves.