Using Experience Map to Analyze User Data for Creating a User-Centered Product (UCD).

User-centered design (UCD) is to give your customer an experience that is seamless, easy to use so that it meets their needs and in turn makes them more productive and happy. If they are more productive and happy the more they will engage with your product and even recommend it to other people. That in turn, will make your product more successful. So, the first task in the user-centered design process is to understand your “User”.

User research can be either qualitative or quantitative. Qualitative means the rich data that you get just by observing people performing the task with the product and noting down minute details of the whole experience it can be either a product, software, or even a competitor’s product. Quantitative means getting data from statistics and metrics you gather from web analytics, surveys, or other tools used to gather research data. In short, Quantitative data tells you “What” is happening and Qualitative data tells you “Why” it’s happening. So the first step in being user-centered is to know who is your “Users” and what are their pain points. The best approach for getting qualitative data is to see the user using the product and get that high-quality data and making a note of it. And lastly, user-centered design is a team activity unless everyone on the team has a good understanding of user needs they won’t be able to design a good solution for those needs.

Turning Observation into Actionable Data 

It’s very important to get good actionable observation from our target audience because that is the first set of research data that will be used as a foundation in the rest of the design process. Without a good understanding of the user’s current pain points, we won’t be able to create a goal for product improvement and secondly, we won’t even come to know whether the product idea we came up with will resolve the issues that the users are truly facing in their daily lives. So the first step in this process is to observe the user.

Observe Users

Unfortunately, users aren’t that good at vocalizing their task, and many times they get so used to that task that they don’t think about the alternate way to doing that same task. So, if you ask your user about the problem they are facing and what procedure might fix that they will answer you but that tends to be incomplete and will always miss the bigger picture which is the “root” cause of the problem. A simple solution to this is to watch your user performing that task and make points of all the tasks performed without thinking about the solution. However, there are a few guiding principles one must follow to make the most out of visiting users.

• Work out whom you care about and who is your target user?
• Where do they do their work?
• What type of activities do you want to observe?

So the only tool that will be needed for this task is a notebook and a pen and also a roll of duct tape. Notebook and pen are for taking notes as well as sketch the environment you see the user working in. And the duct tape is for your mouth. Yes, you need to remember that you’re an observer, not an interviewer. So if you are engaging in the conversation your not an observer. For this task first, you will need a well-defined user to get a well-defined product. Now you have to arrange a visit that matches your target user profile. And then observe them when they are doing the task that you care about and want to find a possible solution for it. Technically this visit has to be repeated at least 5 times wherein each time you make point’s and analyze it and again during 2nd meet, you again make a point but this time you even analyze the degree of changes from the previous meet and if any new things that you might have noticed which was missed in the initial visit.

Interviewing is less beneficial than watching behavior. If your focus is on an interview then make sure it is behavioral which is focused on people’s actual behavior while working with the product in past or present rather than asking people to talk about things they’ve never actually done. Be an active observant, not a passive one. Rather than writing “User doesn’t like another locking mechanism in the lid of the coffee maker” it always better to write the actual quotes the user uses like “ Sometimes these two locking mechanisms make me do another task which is little daunting”.

Things to do while Observing User 

• Write down what user say and do
• Take a photo of the environment (If allowed)
• Engage with people but not too much so that you distract them from their task.
• Ask open-ended questions

Things not to do while Observing User

• Engage in a conversation with the user.
• Writing down solutions.
• Turn the visit into a sales pitch
• Ask the participants to predict the future.

And in the end, it's always better to ask your users if they have any questions.

Experience Mapping

Qualitative information can lead to some interesting insights about your users. These insights are the things that are used to build the product that delights your customer. But what if we turn those observations into a visual story about the user’s task and pain point. This is something that can be achieved using an experience map. An experience map is somewhat similar to an affinity diagram with few improvements. So after you’ve observed your user, you create an experience map to extract pain points, goals, and persona information. The experience map is the way of depicting the user path in that task and the decision they took while performing the task and the pain points they experience along the way. The tools that will be needed for this task are a large whiteboard and loads of different color sticky notes.

Fig 1: Experience Map Template

So, firstly as this is a group task every member of the group will mention their observations in a form of sticky notes and once all are ready with their sticky notes they will start sticking it according to the phase of the task done from left to right. Here we will be using yellow sticky notes and any color sticky notes can be used. Observation can have the following categories

• Direct Quotes, which the user said.
• User goals, things they said while they wanted to achieve in that task.
• User actions, observations of how they went through achieving that said task.
• Pain points, things that stopped them from doing what they wanted.

Once all the stickies are up, we can start with grouping similar observation and choosing the observation that better represent that particular task. If two people saw a different behavior during different visits then you need to dig deep into that area in more detail, so that you can resolve the disagreement.

After this step, the team needs to group those observations into a task that represents that observation. The green sticky notes here represent the task that the group of observations refers to. Make sure all the tasks are arranged chronologically. The last step here is to group the set of the task into activities by color coding it to blue sticky.

“ Design ideas aren’t user data, they’re your interpretation”

At this point in this process, your interpretation might be bad. But you must get that idea out of your head. If you think you can add more to this map you can add it freely like the question that you asked or any points. Many of the questions in the experience map will be answered in subsequent research. Wherein we will be using this data to create a “Persona”.

Tips for a good Experience map

• The majority of you're sticky noted should be quoted.
• As needed you can add the observes initials to the notes.

Actionable Data

Once we have all the observation data sorted in the columns in the form of an experience map, now it becomes pretty easy to identify the areas of current interaction that are causing the problems for users, the pain points. The best way to extract pain points is via dot vote. This process involves giving each team member a small limited number of dot sticky notes and they have to put the dots in the issue they think is very important. They have the freedom to choose any issues and the issue with more number dots helps them to identify the top issue the one with the highest priority for fixing. Using this dot method you can also list down the other pain points which have 2–3 dots and those pain points will also need your focus. Pain points are a great way of exposing issues, but it helps to describe how we intend to resolve the pain points in general terms by turning them into “goals”.

Goals can be easily listed by simply inverting the pain points for eg if your pain point was “ Don’t know whom to report issues to” so the goal will be “I know whom to report the issues and when”. However, goals aren’t much use without a way of understanding when you’ve met them for that we need to define “metrics”.

Metrics are a way of defining the success of any product or service. Measures such as efficiency, effectiveness, and customer satisfaction will let you know how well you have met the user needs with the feature you have implemented. To create metrics first we need to determine what success looks like for each of your goals. Then work out how you can measure that success in terms of efficiency, effectiveness, and satisfaction.

Efficiency

• Time to complete the task

Effectiveness

• Reduction in error

Satisfaction

• Happiness with system

Once you have determined the right metrics for each of your goals you have finished with your initial data analysis. Using the information that we got through the experience map, the pain points, the goals, and the metrics will serve as a great reference point for the next stage of the user-centered design process which is “Persona”.