Wednesday, November 2, 2011

Getting to intent - root cause analysis



Users will make lots of feature requests during research sessions. Listen, Probe and Validate to make sure you solve the underlying issue.



Getting at user intent
Users often give us feature requests without telling us the underlying problem they are trying to solve. Feature requests are problems bundled up as solutions, but in this instance the solutions have been designed by users who might not have the full picture.

To create a truly useful design solution we need to fully understand the problem, the context, and the user’s goals. In other words, we have to understand their intent.

Probing questions
The basic model for getting at intent is Listen, Probe, and Validate. We have to listen to the feature request, ask questions that probe the underlying behaviors, and then validate our new understanding of the issue with the requester.

Consider this interaction during a site visit to a shipping area of a company whose stock handling software you created:
Customer: "For items that I've already picked, I want a way to turn them all a different color so I know they're done."
At this point you could make an initial interpretation and decide that you need to create a checkbox and button combination that allows users to select items and then click the button to change them red rather than green. However, does this interpretation of the feature request REALLY solve the problem? Find out using the Listen, Probe, Validate process.
Probe: "Can you describe the last time you had to do this?"
Customer: "It happens all the time - when I pick one order off the shelves, I'll grab the components I need for the other orders on the screen, because I don't want to have to come all the way back here each time."
Probe: "How do you keep track of it at the moment?"
Customer: "I print off the screen and take the paper with me. When I get the parts, I cross them off the printout."
Validate: "If I understand correctly, you want a way to minimize the effort of picking each item, regardless of what order the item belongs to."
Customer: "Exactly. But it's important to keep them in separate boxes otherwise you'll end up sending them out in the wrong orders."
This leads to a totally different, more globally applicable interpretation of the initial feature request: You need a way to sort the picking list based on the location of items in the warehouse, rather than by individual orders, but with easy reference to the order numbers.

By listening, probing and then reflecting the user's statements back to them, you can quickly get to the root cause of an issue.

Creative Commons License 
RSS  e-mail


No comments:

Post a Comment

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