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:
Warehouse worker: “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?”
Warehouse worker: “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.”
OK, but there’s more than that here, what else can we learn by probing?
Probe: “How do you keep track of it at the moment?”
Warehouse worker: “I print off the screen and take the paper with me. When I get the parts, I cross them off the printout.”
So it looks like we’ve identified a deeper problem than the initial request. Let’s check what we heard.
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.”
Warehouse worker: “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.
You don’t need to come up with that solution and validate it with the warehouse worker at that precise moment. What’s important is to make sure you captured the true problem.
By listening, probing and then reflecting the user’s statements back to them to validate, you can quickly get to the root cause of an issue.