Empathy in Design

Too often I see products that don’t actually fill a user’s need and exist simply to exist. Or, even worse, attempt to fill a need and do so poorly. I believe this comes from a lack of empathy, whether purposeful (“I don’t care, we need to get it done”) or accidental (no time to actually iterate on the design or connect with users). I believe you need empathy in order to create a good product – product being an actual marketable product or a solution to help someone. Without empathy, you cannot understand a user’s pains – and more importantly, what solution they need. This is why as an IT professional I always try to understand my users’ pains and issues. At the end of the day, I want my users to be happy and productive. They can’t be happy and productive if I’m not making sure their needs are met. And I can’t properly ensure their needs are being met without understanding what those needs are. That’s why I believe empathy is so important in decision making and when creating solutions.

It’s also important that I don’t put myself in a position above my users, either. I believe that in order to make good decisions regarding the direction of a product or solution you need to be in the shoes of your user. For example, in my IT work, I don’t think it’s a good idea to get myself a better computer or give myself more internet bandwidth than my colleagues. Not only is it abusing your power; but also, if there is a genuine issue due to filtering or bandwidth limiting, I want to know about it. Or, if a user is having performance issues with their laptop, I want to know what that’s like. Plus, I’ve found that people are more likely to act on issues when it affects them. This is why you need to be in your end user’s shoes when making decisions regarding your IT systems, and, well, just solutions in general.

Another facet of solution designing I think is good to consider is looking at things from a beginner’s mindset. This plays into the whole empathy thing. I don’t think you need to design overly complex solutions in the name of designing overly complex solutions (looking at you, vim). If you want to design a solution that truly can work and work well for an end user then it should be accessible to beginners. As in, someone unfamiliar with your solution or the problem should be able to navigate the basics of the solution without hand holding. My test for ease of use is the proverbial “Janice from accounting”. It’s not a reference to anybody specific but just the stereotype of the technologically inept person. The idea being, if someone who calls their computer a “CPU” can use this technological solution, then anybody can. I like to apply that to any kind of solution or explanation I make.

Another topic I’ve had come up recently is conflict in groups. Group conflict is something that can seriously slow down a project. Navigating that conflict can be difficult, as much as I wish it wasn’t. One way I think conflict can be navigated is by tackling it head on. Have those uncomfortable conversations with your team members to figure out what’s wrong and work out your differences. Oftentimes it’s not necessarily malice that can be causing issues, but just poor communication. I’ve found that once communication breaks down, everything else falls with it. Also, another source of conflict I’ve seen is when one’s ideas are rejected. It’s often damaging to your pride to have your idea rejected. But I think sometimes you have to just suck it up and roll with it. If you have legitimate concerns – by all means, bring that up to the group – but forcing your idea on others is just bad for your team and collaboration.

Leave a Reply

Your email address will not be published. Required fields are marked *