FOCUS is an emerging customer development methodology curated by Justin Wilcox of Customer Dev Labs. I’m wiring myself into the first FOCUScon event a global webinar* style conference in preparation for it I am reminding myself about some of Justin’s interview tips.
These 4 tips are designed for finding customer product fit, but what I found is they are equally fantastic questions to use when testing your designs.
1/ No pitching!
User research is about listening and learning not pushing your ideas onto users.
2/ Don’t ask future questions.
Asking future led questions is asking a user to predict the future. Users are usually happy to validate your questions which often come across like a pitch. Would you go to the gym next year? Will you buy this product?
User response: Yes and Yes. Reality: No and No.
3/ How do you solve it currently
Opposite to future led and leading questions, asking historical questions gives you feedback of actual user behaviour.
“Did you go to the gym last year? How did you motivate yourself to go? Why did you motivate yourself to do it? And why did you do X?”
At which point they say “stop asking all the questions!”
4/ Ask Why
When a user does something, almost anything ask them why they did it. Then ask the patronising question, ask why. Then like a small child, ask why again. You can really dig into the crux of the users motivation or offline processes when you drill deep into their behaviours.
As an additional tip, warn your users ahead of time in your introductions that you’ll ask users a lot of pedantic questions and that they should go with it. But what’s great about asking Why is you can ask in any context. If you are in open value testing or usability testing it works just as well.
Further reading and watching
There’s a tonne more gold in the youTube video and it’s also scribed on their website. I get all my students to watch the workshop and when I’m consulting to product owners who are hands on in the interview process (which they should).
Some other tips I’m throwing in there
Don’t include the solution in your usability question.
I see this happen a lot, and a lot like pitching you’re going to invalidate your responses if you do it. It is easy to introduce bias by asking the question wrong way. So be very careful to follow this example:
If you say to a user “Add a new team member” to your account and the label on your site is called “Add team member” you’ve essentially given them the solution. Try to avoid this by first establishing a need with your user through the interview. If they don’t have a need for it, don’t bother testing it. More on that later.
For example “Who typically works with you on the project?”, “Why do they work with you?”, “Why, Why, Why”, “How do you expect this product to facilitate that?”, “Can you try and do that for me now”.
First that delivers you the user need, probably when and where they expect it to fit in the experience and how they expect it to happen too. Note how the questions switch from past to future tense. The who, what, why, when questions are historic while the how questions are future. Don’t show someone an interface and ask is that what you expected, they’ll more than likely say yes. Instead after showing them an interface ask them “how was that compared to what you imagined?”. Ask why they thought it would be that way.
*they vehemently deny it’s a webinar, but I bet it is.