Empathise with your users or you won’t solve their problems

13 May 2016
| |

This post is about UX in the enterprise. Changing how we think about our clients, who our clients are, why we should empathise with them and how we can use empathy to motivate us to produce great software.

Software applications are created for people to use. This is a pretty obvious statement for anyone who has ever operated a modern digital device, more so anyone involved in software creation. Historically, however, it was an alien concept that users should be at the centre of the software design process.

In the past few years there has been a trend towards seeking to understand more about the user, their motivations, goals and required outcomes. I think this is a move in the right direction, we are beginning to empathise with our users, and this is a good thing. But it’s just the beginning and we need to use that empathy as a driver for us (the development team) to deliver a great product for our clients.

Bring up the subject of user empathy with some engineers or product owners and you’ll probably hear comments that fall into one of the following categories:

  • Why do we need to empathise when the requirements tell us all we need to know about the problem at hand?
  • Is this really going to improve anything?
  • Sounds like an expensive waste of time
  • They’ll have to use whatever they’re given

These aren’t unexpected responses, it’s easy to put empathy into the “touchy feely”, “let’s all hug and get along” box of product management.

To very logical, cerebral and metric-orientated people (i.e. engineers and product owners) being asked to consider what a user would feel is not part of the deal. As part of the software delivery team we think deeply, learn quickly and solve the problems.

Why empathise?

Empathy does a number of things, but mainly it increases the likelihood that the delivery team will think of a user and their pain points when delivering a feature.

If an engineer, UX designer or product owner will has sat with a user, watched them interact with their current software or device they will have an understanding of their frustrations, concerns and impediments to success. The team will be focused on creating features with the things they have witnessed in mind, they’re thinking about how their software will affect a human being and no amount of requirement documentation will give them that emotional connection.

As part of this emotional connection comes another benefit, when we empathise we are more likely to try to help the person in need solve their problem (search “empathy and prosocial behaviour” for some studies into this).

Empathy can also help to develop a shared trust in the application development process. The users see that the delivery team are interested in helping to solve their problems and the product delivery team see the real users behind the application.

With empathy there comes deeper understanding of the triggers, impediments, risks and goals of the client organisation. This helps the engineering team align more closely with the client team(s), which in turn helps in delivering a product that users and client groups are more likely to want to engage with.

One of the nicest things empathy can do is help surface non-functional requirements. How the application or device should feel to use or how it should work with other applications in the user’s workflow.

It’s important to remember the drivers behind all of this are the delivery of value to the customer in the form of increased productivity and engagement from the users of the software.

How can we develop empathy for our users?

If we accept that empathy is a driver for a better delivery how do we go about developing empathy and including it in our daily work? The answer is that, as Agile practitioners, we are most of the way there already.

In the requirements engineering or product research phases of a product delivery you would have:

  • Researched the client and client teams
  • Interviewed users
  • Visited the main work or usage environment(s) of your user group

The only difference is that the next time you do it, keep your eyes and ears open. Here are some pointers to get you started.

Learn about your clients and their users

Find out who the potential users are by speaking to your client or internal subject matter experts. You want to find the users directly affected by the product, those on the periphery and those who could be indirectly affected. In a corporate environment you’ll be looking for the teams for whom the product is being built, the teams that feed into them and the teams that are ‘clients’ of the product output.

If it’s a public-facing product you need to identify the target audience and then define the peripheral groups around them. This is the start of your persona development (for more information on Personas click here).

Interview users with a structured questionnaire so that you can have a set of answers that allow for easy comparison. Don’t be afraid to let users go a bit off topic (this can uncover valuable information), but guide interviewees to keep them focussed on your core points of interest.

This is a qualitative research activity and as such you need to prepare in advance of your interview phase. The aim is to interview the smallest number of people from whom you can generate valuable insight.

You should also be prepared to update or change your questions as more information comes to the fore.

Visit the space in which the product will be used and note the clues of problems in the current state of their workflow. Do they have sticky notes or calendars? Are they all in small cubicles? Is the environment loud or quiet? If it’s a consumer product are users more likely to use it in the home or on the move? Answering these questions (or at the very least noting these environmental issues) will help you understand what your users currently do. This in turn will help you make their world better.

Immerse yourself in your notes Read and reread your interview notes, watch your interviews and space visits. If there were any user sketches in your interviews review them, add notes, write follow-up questions.

Your aim is to get deep into the heads of the users. You want to have an understanding of the characteristics of each user type, their workflows and their interactions with others.

Where possible start using any products your users currently use within your target workflow. Sit with your users as often as you can (user shadowing can feel creepy to the user being shadowed; less is more) to get a good feel for their day-to-day.

Start working with your client

With all this good foundational work done, you should be in a better place to start considering how to make the world a better place for your users.

The next steps are all the things you would do in a project normally, but now with the benefit of deeper insight into the problem(s) from your user’s perspective.

You should now:

  • Develop story maps
    • Storymapping (read more here) helps define activities and actions required in a product. A well-crafted storymap will help define priorities and even release plans
  • Create personas
    • You will want to align your user story writing with your personas.
  • Paper prototype UI workflows
    • Before you start pushing pixels, learn to tell your product story using paper. Extremely useful in screen-based products to demonstrate and get feedback on interactivity, UI and information architecture
  • Host UX workshops
    • This is where you’ll debut features and get feedback. Zuhlke product teams use them to help refine requirements
  • Create user workflows with emotional states
    • You need to know for each feature how the user will proceed to success or failure (e.g. the See|Do method). With workflow diagrams you will uncover details required for your user stories.
  • Create your backlog
    • You should now have enough information to write your User stories and start the process of creating a backlog

Moving forward

So now you’ve got your backlog started, you’re able to consider how your different users need to be serviced through your product, your engineering teams and client teams have a healthy relationship and you’re hosting UX workshops with some regularity. All good.

Here are a few things to remember:

  1. You are not your users. No matter how deeply you understand their issues, you must always back your suppositions up with proof
  2. As with all things in Agile projects you must repeat, review and improve all of your processes, including how you work to gain empathy
  3. Your engineering team must be encouraged to interact with their users (find floor walks or desk visits to do process shadowing)

At Zuhlke we use all the techniques listed above where appropriate to help us gain insight into our clients and their issues. Focussing on users helps us to deliver great products, and more importantly keep our clients and their users happy.

Comments (0)

×

Sign up for our Updates

Sign up now for our updates.

This field is required
This field is required
This field is required

I'm interested in:

Select at least one category
You were signed up successfully.