Empathizing means having a deeper level of understanding of your target audience. It is a little bit different from sympathy where you just show emotions. When you empathize you really try to put yourself into the shoes of the person you are trying to empathize with.
When this word is used in UX design, mostly it is explained to understand users, their needs, problems, and expectations. When you really see what your users are going through, then you can come up with good solutions that help them achieve their goals with your product or service.
Empathizing with users is wonderful and I think that we should really embrace it. There are tons of examples when companies took this road and achieved great results. They made billions just empathizing with their users, customers, and overall target audience. One of the greatest examples is iPod. When this thing was released the world went crazy. I think the older generation remembers the old days when we had to use walkman with those cassettes. Listening to music was a challenging thing as we had limited options in those cassettes or we had to carry multiple ones with us. People needed a simple yet multi-option solution which is the exact thing iPod brought. With its slick, simple, and innovative design and of course tons of digital track options, it simply blew the market. Most people think that iPhone was the one product that brought up Apple from the ruins it was in, but I believe that iPod was the foundation of Apple’s success.
Empathizing helps us to become the favorite players in front of our customers. However, over the years I came to realize that empathizing should not be directed to users only. Any product or service goes through a long distance before it reaches its users. There are several types of stakeholders involved in the process of development.
As a UX designer, I had to work with a lot of teams. All those teams had their weaknesses and strengths. Some of the teams consisted of junior specialists who were just stepping into their fields. Some of the teams consisted of experienced professionals. It did not matter which team I worked with, all that mattered was how I worked with them. The more I communicated with the teams, the better solutions I came up with.
I failed with the teams that consisted of experienced professionals because I did not communicate well with them. On the other hand, I had a very successful experience with junior teams just because I learned what they needed. I’m not talking about just design here, I am talking about the overall product that went to the market.
The products we collaborated a lot to complete had a very successful result. The strange thing is that it also affected the usability of the product and the end users were happier with them. Besides, when I collaborated with the teams, the business had better results as well. Strangely, the products where I inclined towards UX a lot failed mostly. Most of them were not even released and were abandoned as concepts only.
I came to realize that when I learned about business needs, technical constraints, and user expectations, I could make better decisions. Especially, the results were even better when I balanced everything among these three aspects. This method works very well for startups where the budget is limited all the time. Besides, most of the case MVP versions of the products showed higher results than expected.
I had to sacrifice beauty over functionality, being within budget, and technically availability. My designs became a little less pretty but they were more usable, technically easy to develop, and user-friendlier. Of course, I could not just design whatever came to mind, and ugly designs. I started using the 80/20 rule in a different way. 80% of the time I align my designs with business goals and technical capabilities. I just learn about the business and its team. I make sure that I am within budget and that I understand the business goals, also I make sure the team can develop the designs easily. But 20% of the time I experiment and try to innovate. I design more user-friendly but slightly difficult things to develop. This way I push developers who are working with me to grow. It does not matter what level of specialists they are, it works all the time. Juniors grow to be middle sooner, middle developers acquire senior-level skills. I even had to push some of the senior software engineers when I worked at Amazon.
UX is not a one-time thing. UX is an ongoing process that continues over months and years to achieve great results. It took around 25 years for Amazon to become the e-commerce giant, and it took over 30 years for Apple to become the innovators they are today. These companies can spare tons of budget and can have super-packed teams of super-professionals doing things that are changing the world every day. We cannot compete with them right now, because we have limited resources to do things.
This is the exact reason I strongly believe that any UX designer working in small companies should balance things among “Business needs”, “Technical constraints”, and of course “User needs and expectations”. Empathizing is not just about the users, it also means understanding the business goals and technical capabilities of the development team. Sometimes, UX designers need to work with sales, marketing, and legal teams in order to achieve better results. Back in the day, I helped the operation team in our warehouse so that the company could deliver the shipments on time. You think that was a crazy place for a UX designer to be right. No, actually I learned a lot of insights about how the operation process went and I used them to design the company’s products later. I guess that is the exact reason why we need to try to see opportunities in every challenge. Empathizing with everyone is very difficult, but the result is mind-blowing even if you fail.
This is my one tip for UX designers, empathize with everyone on the team. It does not matter who that person is and what they do. When you really try to see what they do and how they do it, you will find tons of opportunities for innovative solutions.
Read the full article here