Don’t Say These Things During User Interviews
500+ User Interviews
5 Years
60+ Product Teams
User interviewers often talk too much, ask overly-specific questions or just ask the wrong type of question.
You can avoid this and you don’t even need to be an expert.
You just need a few tips to keep you on track.
After conducting and watching 500+ user interviews, I have seen patterns emerge and have developed tactics to solve these problems.
Use these tips to improve interviewing skills, get better feedback and even shorten interview length.
Don’t Talk So Much
Are you worried about bias?
Talk less
Do not "we, we, we" all over the user
Focus on the user's point of view
Don't fill the silence...
...even if you feel the urge to EXPLAIN what's in front of the user
When your product is live someday, you won't be there to guide the user
So don't guide them now
Embrace the awkward silence and wait for them to react
Don't narrate the on-screen options to the user
User confusion is a signal you need to look for...not gloss over.
To make interviews move smoothly without interrupting, it's a good idea to make on-screen options more OBVIOUS in prototypes.
This way you can get a reaction without guiding the user.
And when you see confusion, don't wait...tweak the solution for the next user and see if you can improve.
Don't help users through a prototype
When the user says "I don't understand", you might be tempted to help...but DON'T...just wait...like 10 seconds
It's common for a user to SAY they don't understand
But, in a few seconds they often figure it out
Avoid These Questions
Don't say...
- "What do you see?"
- "Describe this screen"
- "What do you think about this screen?"
This solicits feedback that is not actionable for the team
You already know what the prototype looks like so no need to ask the user to tell you what they "see"
You need to be focused on whether you can solve their pain point or attract them to an opportunity
Instead say "What would you do next?"
Avoid always saying "Why did you click/tap that?"
You don't need to stop the user at EVERY tap/click to explain their thinking
You can just let them continue through the prototype if they are still going...maybe remind them to think out loud
Going through a prototype without help shows great usability and possibly high value as long as they are thinking out loud
Later, go back and ask about their decisions
Avoid saying "What's missing here?"
This question is not easy for ANYONE to answer
You're asking the user to put the whole experience in their head and then tell you what's missing
In over 500 interviews, I've only known a couple users advanced enough to give that level of feedback
This is precisely why Product teams need to create multiple (fake) solutions so that users can choose from options
Don't ask users to "Read an email"
This will introduce a bias since a user in an interview will actually follow the prompt and read the entire email.
When not in an interview setting, most people will SCAN an email reading significantly less.
A better, less biased test is to give the user 5 seconds to scan/read any written content.
This better approximates how users consume text content. This applies to on screen instructions, onboarding wizards and other content that users rarely read.
*Todd Caponi was the Head of Sales at PowerReviews. “We we we” was a term he used to remind us not to talk about ourselves when selling to prospects. Instead, we should encourage prospects to talk about themselves and describe their needs and problems. Here’s an excerpt from an interview transcript: Todd Caponi: ...you don’t need to be Johnny Salesperson, “Wee, wee, wee, this is how great we are.” You present as though to talk to the client about how great they can be, instead.
Here’s a link to the excerpted interview.
Jim knows how to build and scale successful products.
He co-founded PowerReviews which grew to 1,200+ clients and sold for $168 million. He product-managed and architected one of the first ecommerce engines at online retailer Fogdog.com which had a $450 million IPO.
These days, he coaches Product teams and leaders at startups and corporations to use Product Discovery to validate and test their ideas before building them. He’s created a custom curriculum and training program that pulls from his 25 years of experience and the best minds in Product Management. He graduated from Stanford University with a BS in Computer Science.
Jim is based in San Francisco and helps clients engage their customers to test and validate ideas in ecommerce, machine learning, reporting/analysis, API development, computer vision, online payments, digital health, marketplaces, and more.
