Thursday, November 3, 2011

Experience Mapping

Quickly turn a pile of site visit observations into a visual story about users' tasks and pain points. Use experience maps - affinity diagrams on steroids.


Analyzing qualitative information like written site visit notes isn't as simple as plugging numbers into a spreadsheet. However, it's a lot more fun and it can lead to some really interesting insights about your users. These insights are the things you use to build products that delight your customers.
 The experience map data party
The idea is to get all the observations from every visit into one location. Doing this allows everyone on the team to see how the things they observed fit into the big picture. Because different people attended different site visits, this data merging activity puts everyone literally on the same page.

Building the map should be a team activity. Everyone who was on the visits should be in the room at the same time. This is where you find out how good your site visit observation notes were.

Write each observation on its own sticky note, and stick them all on the wall. If you have questions or think of design solutions, just write them down so they are out of your head and then keep going.
Making the map
The map making process is very similar to affinity diagramming. It starts the same way, but then adds the dimension of time to make it clear how users' tasks progress.
  • Everyone who attended a visit brings their visit notes. They copy each observation from their note books onto a sticky note. Offices tend to have more yellow stickies than other colors, so use those. 
    • It might help to put the observer's initials in the corner of the note for later reference
  • Observations normally fall into one of the following categories
    • Direct quotes - what the user said
    • User goals - what they said they were trying to achieve
    • User actions - observations of how they went about achieving it
    • Pain points - things that stopped them from doing what they wanted
  • Each person places their sticky notes on the wall 
    • Put a large sheet of paper up first so you can move the map later
  • Team members group sticky notes into tasks (label each task with a green sticky)
    • It's OK if people disagree. In fact the disagreements highlight where the interesting stuff is. If two people saw different behaviors during different visits, you need to dig in to that area in more detail so that you can resolve the disagreement.
  • Team members arrange the tasks chronologically and then group sets of tasks into activities (blue stickies)
  • If you think of design ideas, add them on a different colored sticky note (orange)
    • The idea is to write down the idea and then move on. Design ideas aren't user data, they are your interpretation. At this point in the process your interpretation may be bad, so just get the idea out of your head and keep going.
  • If you think of more questions, add them on a different colored sticky note (pink)
    • Questions - the things you wish you'd had an opportunity to observe - are an indication of how much more research you need to do before you can be confident that you understand the users' process.

Group stickies into user tasks, and group tasks into larger activities. Add photos, photocopies of paper documents that you saw being used, and any other artifacts that help explain the tasks.
Many of the questions stuck on the map will be answered in subsequent research, but if you end up with a lot of questions about user behavior, you probably need to get out and do more site visits before proceeding. Conducting more visits just makes the map richer.

Information radiator
Put the finished map in a busy place. It will tell a pretty compelling story on its own, but walking people who couldn't attend the site visits through the experience map will help them understand more about your users and the tasks they perform.

You will come back to the map many times during subsequent development phases. It forms the basis for writing scenarios, and you can "ask questions" of the map to resolve design decisions.

What the map shows you is the pain points - places where the current process is broken. If you focus on fixing these pain points, you'll create a product that your customers will love.

You can walk anyone through the experience map, telling them a story of how users work. Note how this map shows a task that some users skip.

What about observer bias and validity of the data?
People on the team who are used to gathering statistical information about users may be upset with how "fluffy" this exercise looks. Underneath its fun surface there is plenty of methodological rigor.

Observer bias occurs when the people writing down observations place their own interpretation on the activity they are watching. It also happens when people ignore some activities and focus on others instead. The experience map reduces bias by combining multiple observations from different observers, and by ensuring that the map creators focus on the problem, not the solution.

Validity is a measure of how well the information you collect matches the real world. Here, you gathered your observations from real people who you know are representative users. You haven't changed that data at all. The stickies on the wall contain direct user quotes and other contextual information. The path you took from observation to reporting of the data is transparent.


Creative Commons License 
RSS  e-mail


No comments:

Post a Comment

Please keep your comments respectful, coherent, on-topic and non-commercial.