| back to the List |
The niche for this question is pretty narrow: Usually it comes up when I’m working on updating or enhancing an existing product in an enterprise setting. That is, it’s a product someone needs to use as part of their job. It is one of several flavors of “pain points” questions in my repertoire. The word “coaching” here does a lot of work to position the person I’m speaking to as an expert, helping someone else. It implies that there are difficulties with the product that they have had to overcome, and they have an opportunity to pass this wisdom along to others.
It can be hard to get someone to admit that they have problems with a product, because it might reflect poorly on them. They may also be at a point where they’ve become expert with a product, so they don’t see the problems any more. Asking them to look at the product from another’s perspective gives them an opportunity to highlight the challenges they’re having, and the aspects they know need attention.
This question presumes that the person I’m speaking to is already a user of the product, and perhaps has extensive experience. It presumes they have not only had to learn it themselves, but also that they’ve had to devise work-arounds or hacks to accommodate their own process. This person may not be responsible for training other people how to use the product. The prospect of a new user getting coached may not even be in the realm of possibility. Instead, this question acknowledges and taps into their expertise, and prompts them to think about the product’s learning curve.
Note that this is not a question I could ask about a new design concept, or a product that someone hasn’t seen before. The intent is to tap into their cultivated expertise and experience, setting them up against a (maybe) fictitious inexperienced user.
Sometimes this question yields very “in the weeds” details. I like hearing about usability issues as much as the next designer, but my purpose here is generally a little broader. What I’m listening for is aspects of the product that don’t line up with how the work gets done. For example, if the product treats data as static, and the people using the product see it as dynamic, they may have to do things in the product to accommodate their reality. “Since the product doesn’t save a version history, we actually create a new instance of the data every week. It’s not perfect, but it does give us a bit of version control.” One product I was working on had a notes feature that expert users used to record everything they did in the system because it didn’t have activity logging natively.
Although this is a question about the product, it’s really a discovery question. That is, a question to help you learn about the situation and context. While it can shed light on product design problems, our aim is to discover more about the environment in which the product operates. Through the product experience, we seek clarity and depth in our understanding of the organization. A person’s experience of a product they use as part of their work sheds light on the disparities between the product’s model of the domain and how the organization models the domain.
Be sure you’ve asked “and what else?” to make sure you’ve heard all the ways in which the product doesn’t align with the organization. Beyond that, you can ask them to speculate about a better way of designing the product. Again, you’re not looking for actual design ideas – though that would be a nice bonus. Instead you’re listenening for what concepts they would bring into the product to make it align better with their own mental model.
If a new person were joining the product team, what aspects of the product would you focus on?
If you don’t have the opportunity to talk to actual users, you can ask this version of the question of the product manager, owner, or other leader. The intent remains the same: get them to look at their own product from a new perspective. The hook in this question is injecting a person with no experience and asking your subject to empathize with their lack of experience.
Take me back to when you were first learning the product. What was the hardest part for you to learn?
Instead of introducing a fictious new person, ask the subject about their first experiences with the product. Perhaps the idea of coaching a new user is so far outside the realm of possibility that such framing would be a distraction. Instead encourage them to remember their earliest days of using the product and what challenges loomed large.