From the course: UX Design for Developers

Recording and analyzing user observations

From the course: UX Design for Developers

Start my 1-month free trial

Recording and analyzing user observations

“

- [Instructor] User observations tend to be pretty unstructured. Here's how I bring some order to them. I encourage every team member who did observation of users to distill what they learned into simple sentences, like these. One session of user observation might generate a half dozen to a dozen such observations. With a typical team on a typical project, 100 to 200 observations can come out of user observation. Once we have our list, we need to analyze it, and there are multiple ways to do that. Traditional designers like a technique called Affinity Diagramming. They use a whiteboard or corkboard, and they divide it into categories of observations. Then team members write their observations on sticky notes and put them in the appropriate category. Some teams like to have each member have their own color of sticky note. There's nothing wrong with this, and designers like the tactile nature of this technique. But I prefer another means of analyzing observations that most designers wouldn't touch if you bribed them, a spreadsheet. Instead of infinity diagramming, I ask team members to simply email their observations to me as unformatted text. Then I drop everyone's observations into the first column of a spreadsheet, which then serves as the vehicle for the team to discuss and analyze all the observations, each is assigned a category and possibly, some additional notes. This is what that spreadsheet looks like when I first dump the observations into it. The observations are ready at this point for the team to walk down in order and discuss them. The team fills in categories and notes. Each item is discussed as much as it needs to be to ensure that everyone on the team understands it. Duplicates pop up from time to time and they should be noted. Such a meeting typically takes two hours or so, depending on the number of observations. It's really time well spent, though. At the end, every team member should have a strong understanding of the needs and psychology of the user population. Here's what the spreadsheet looks like after that meeting. All the items are categorized, but there's no order to them. But we do have categories, and priorities, and notes in place. So the next step is to sort the observations by category, and that will bring observations about a particular area of functionality together in the spreadsheet. Then when that area of functionality is being designed, it's often useful to open the sorted spreadsheet and look at the observations for that category. Here's an example of observations that have been sorted by category.

Contents