Mapping the User Experience

Mapping the user experience – How to find out what the real problem is before we start solving it.

Working in a project where the users are ignored since “We have to focus on functionality first!” leaves me exhausted. The constant flow of cartoons and jokes about developers not really caring about the real needs of users seem to go on. And just to clarify, with developers I include project managers, testers and anyone in the process of producing software. We laugh at the jokes and go back to repeat them in our own way, often thinking that usability is some other person’s responsibility.


To be perfectly honest our craft still seem to be very immature in the art of satisfying the users for what we build. So how can we change this? I for one have made a vow to myself that I will do all I can to help building systems that the users really like to use. I truly believe that change comes from people putting their foot down saying, “No more of this!”.

Moment of Truth

Try this though experiment with me. A lot of people get really sick from using badly designed computer systems. There is a lot of statistics on this. Swedish readers can have a read at Jonas Söderströms blog – the book is an eye opener! English speaking readers can read the slides.  So if we accept the fact that the use of IT systems are making people sick, think about who built the systems. That would be us – the developers, testers, requirement analysts, scrum masters etc. So indirectly we are hurting people by building systems that are hard to use. Now take a moment to reflect on your personal code of ethics. Can you honestly say that you are ok with continuing building bad solutions knowing what the effects are?

Mapping the User Experience

The UX community have some really great ideas on finding out what the real problem is, before we start solving it? Sounds like a fairly reasonable idea to me.

Collecting Data

The Lean movement have a core practice – the cool English-Japaneese term is Go to Gemba.The only way of really understanding what people are doing is observing them doing it, preferably in their natural setting. The same idea goes for mapping a user experience. Observe users as much as you can, ask them questions about what they are trying to do and what problems they are facing. Try not to impose too much since that will disturb the users and may change their behaviour. I find it good to go out and observe in pairs since we observe different things. We never do any video recordings since that disturb users and we never seem to have time to watch the recordings anyway. It can be exhausting to be an active observer. Try to focus on what you see and hear and don’t try to find solutions at this point. Make sure to write down quotes that really make a point like : “ I wish I did not have to enter that data once more”.

It may not always be possible to observe all the users you want but hopefully you can at least meet them for interviews. To be honest, in the projects I have participating in we have mostly worked with interviews and have made only a few visits to observe users working. Done the right way interviews can be very revealing. We still avoid video recording and instead try to be active listeners and ask clarifying questions. Good questions you may ask are open-ended like:

-“Tell me more about what you just did.”

-“What information would be good to have when performing this task?”

You can spend a lot of time collecting data and there are as usual no rules for how much is enough. I have mostly built systems intended for specific professional users which means that the number of user groups is fairly limited. It is a good idea to interview at least three people in each user group in order to get valid personas. For larger systems you may want to interview many more than this but we need to start somewhere.

Analysing Data

Now is the time to start analysing all the data from your observations. A great way of doing this is to arrange a workshop where all the people that interviewed or observed participate. Condense findings by writing the main points on yellow post-its and putting them up on a wall. It is I good idea to put some butcher paper or some taped flip chart papers on the wall to be able to move the information when needed. Group the post-its together for the specific actions users try to do.

Now create a chronological flow of tasks on blue notes where one task may consist of several actions on green notes. I does not have to be perfect as flows in reality seldom are. You now end up with something looking like this:



Sorted observations of user experiences

Note that what is on the wall now is the group’s collective observations of real user’s actions grouped together. We still have not solved any problems but we ought to have a pretty good picture of what the real problem is. We should all literally be on the same page.

I attended a great one day tutorial by Chris Risdon where our sorted tasks looked like this.


Tasks for booking a hotel


Creating the Experience Map

There are several models for creating a more formal map.

Here is a task map based on the free downloadable templates at cxpartners. The templates accompany the book Communicating the User Experience which is a great start if you want to dig deeper into this matter after reading this post. The flow describes how to order a specific medical drug and is loosely based on a recent project.


Task Map for Drug Application


Some more examples can be found in Chris Risdon’s slides. Read more about customer journeys and mood graphs.

Our hand drawn graph at the course looked like this



Since I strongly believe feedback is a key factor to any successful project this is a good time to show the graph to important stakeholders to make sure we all agree. If we find that we still have outstanding questions we may need to conduct some more in depth interviews.


This only a very brief introduction to the starting point of UX. The technicques are not the hard part – the crux is to become a great observer and interviewer. The ideas are not new – business requirements and processes have been a part of many development models. The problem is that thay have to often been ignored. UX is changing all that by really putting focus where it belongs – solving real problems for real users.

If you have read earlier blog posts you will recognise the four step flow of visual problem solving.

Visual Problem Solving

Visual Problem Solving














The experience map is a great way to start a project! There is plenty of information if you want to dig deeper in Mapping the user experience

The latest stuff I read and can recommend is

Communicating the User Experience: Caddick, Cable

Smashing UX Design: Allen, Chadley

Posted on 29 april, 2014 in Lean, Method, UX

Share the Story

About the Author

Response (1)

  1. Five Blogs – 30 April 2014 | 5blogs
    30 april, 2014 at 05:03 ·

    […] Mapping the user experience Written by: Torbjörn Ryber […]

Back to Top