Saturday, April 14, 2018

Is empathy the missing link in user experience?

Some happenings at work in recent weeks have got me thinking about UX and empathy. It's been oft-repeated on blogs and websites, but it's such an important, maybe critical, point that I thought it worthwhile to put some more words on the topic out there.

In my view one of the major disconnects in the software industry is the gap between programmers sitting behind a computer and the real world impacts of the code they write.

What you often see in an IT department is this: a programmer gets a work order from a business person, a tech lead, a manager, or someone else in the hierarchy of their work place, like a signal passed down from the business Gods. They then spend some time understanding the work before hurriedly getting it done and moving on to the next thing.

In practice the programmer's time is spent on a treadmill where work is only looked at as a barrier between two states: in progress and complete. This is where the disconnect lies. Success is measured in terms of what's completed, rather than how well the end user is being served.

The issue here is that a developers job isn't to write code, it's to write effective code. And writing effective code means providing the customer with what they need. And so in practice the primary role of a developer is to understand what their customer wants, and then only secondly actually build it.

This is where empathy comes into play. Empathy can be defined as the ability to understand and share the feelings of another, but taking the poignant connotations out of the term it can be described as 'understanding another'. To build effective software a developer needs to take the first step of understanding their customer: what their wants and needs are, what their level of understanding is, what jobs they need to get done, what it is that they're actually going to do with the end product.

Imagine you've just shipped restaurant software to production. Your testing went well and everything worked as expected. Then your manager schedules some time for you to view your product in action.

Suddenly, when viewing it being used you notice how ineffective what you've built actually is. Waitresses are struggling to figure out your interface, and the restaurant is experiencing lower productivity because the assumptions you've made aren't quite right.

While at the restaurant you're seeing the experiences of your users. Their struggles with your software, how badly they want a better working system. All at once the real world impact of what you're writing is front and centre. No longer is your work order just a vague description of implementation details, it's something real that is going to affect real people.

And so empathy acts as a simple, but powerful heuristic when building applications. If you develop without thinking about the real experience of your end users, what are your decisions premised in? Granted, there are sometimes other things to consider than user experience, but if your main job is to support your user: you should look to them first.

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.