Empathetic design

How designers must deal with different levels of empathy when designing products

In my previous articles, I’ve mentioned about the importance of empathy for any designer. Since I keep coming back to this I thought about bringing a different perspective on that topic.

Before I start, let’s check the dictionary definition of empathy:

"The action of understanding, being aware of, being sensitive to, and vicariously experiencing the feelings, thoughts, and experience of another of either the past or present without having the feelings, thoughts, and experience fully communicated in an objectively explicit manner; also: the capacity for this" — Merriam Webster Dictionary

As designers, we need to have a great connection to other humans and a profound sensibility to understand how people from different backgrounds, cultures, and languages behave.

There are, of course, many tools to help us getting into people’s minds. An important one is user research, which is meant to guide and engage the product team on the user’s problems, so they can deliver a usable and helpful product that solve those very same problems.

The reason I believe designing products is a complex thing is that because the level of empathy is directly connected to the quality of your work. I’ll try to exemplify that with 3 fictitious scenarios:

1. Designing a learning numbers app for kids
2. Designing a code deploy manager for developers
3. Designing a blood pressure hardware interface for older people

What would be the approach for those 3 situations? The designer would need to use empathy in two directions: the target users (or personas) and the field or context that the interface is being designed for. The trickiest part is not only understanding deeply the user needs but to really understand the context in which the product is being developed. Being designing a medical software, an app for kids or a tool for developers, the designer must be able to, not only deep their toes in, but getting the water up to the neck in the subject.

Besides the aforementioned user research techniques, another way to build empathy is asking questions, lots of them. They must be asked frequently and insistently throughout the entire process. And you, as a designer, must make sure that you have the answers properly answered and documented for further use. This answers can be part of a design briefing, a product specs or any other document that your team uses.

Here are some example questions I'd start asking:

1. Designing a learning numbers app for kids:

- What is the target age for the app?
- How the learning process happen in the age span the app is designed for?
- What are the most used methods for teaching numbers in normal education?
- What environment will the kids be using the app (school recess, during class, at home)? 
- What type of device should the app run at?


2. Designing a code deploy manager for developers

- What is the deployment process?
- What are the common issues when developers are deploying code?
- Do they normally use a GUI (graphical user interface) or command line?
- What are the other tools involved in the deploying process?
- What are the common errors and pitfalls that developers face when deploying applications?
- Are there other products designed for the same purpose, and if yes, how do they approach the problem?


3. Designing a blood pressure hardware interface for older people

- How does blood pressure measurement work?
- Why do people need to measure their blood pressure?
- What are the steps needed for measuring?
- What are the limitations older people have on operating digital devices (poor sight, difficulty with technology, movement limitations, etc)?
- What are the technology limitations for the project (device screen type, screen size, number of colors, etc)

Please note that we have some questions that relate directly to users and other that are more inclined to the development requirements.

Asking questions is one the most important tools for any designer. It allows us to slowly become experts in different fields. It’s a tough (and potentially) overwhelming process, but after some time, you’ll be comfortable enough to make some assumptions and, by testing them with real people, you’ll keep learning and becoming a real user advocate inside the team. That’s the best part! ;)