Hi all. Could anyone please share experience or advice some resources (articles, videos, etc.) about user interviews on stage of idea validation?
I am in process of preparing questions, and got stuck. I’ve prepared some open ended questions about specific problems, their experience, pain points, how they currently handle it and so on. But when it comes to finding out if user would use the app - how do i do it without directly asking it? 
I’ve read it’s not good idea to ask users for predictions, so are there some magic tricks to avoid it but still to get the answers? 
Thank you 
let them use it, silently observe, take notes. after they’re done, ask questions why they did what they did, why they’ve gone a different path, etc. you can also do this with your competitor’s apps. you can do this remotely.
start with 5 people.
if you need more theory, Google for confirmative usability research.
1 Like
Thank you!
What if I don’t have prototype yet. Wanted to validate idea first. Or do you think it’s worth to create Low-fi prototype to have something they would try?
Well as you said, it’s hard to explain things in words. So just make a simple one. Pencil on paper is ok, or wireframes in some simple tool like Figma. Whatever you can create and change fast, or even throw away (in case it doesn’t work).
2 Likes
Thank you
Hi @julia_k, if you need to validate an idea, you must first think about what need this idea wants to solve, or what problem it wants to answer.
To do this you can interview your alleged users asking basically two things:
- Which is the biggest problem they face in doing something (and for which your idea is the solution)
- How they’ve solved the problem so far.
Never ask if they would like a certain feature, because people are much better at remembering something from the past than predicting the future.
Obviously ask open-ended questions and let them tell you as much as possible how they approach the need they have and for which your idea is the answer.
I hope that helped!
1 Like
Thank you:pray: yes, exactly, don’t want to ask directly if they’d use app, so thought there might be some tricky questions or tricks that may help 
But in general i get the idea. Will try to get as much as possible out of it.
Thanks 
1 Like
how about a storyboard?! i like them very much.
a rough board for yourself or your team.
and a customer board to pitch your idea.
telling the story and find the job that needs to be done
1 Like
If you have your interview subjects in the room with you (may be difficulty right now!), I’d say you could get results with well-made paper wireframes.
But as marasciofabio said, have you asked your users about their needs? I can’t tell from your original post if you have, so bear with me here, but here’s my approach to doing just that:
Ideally, you do user/market research first, identify a real pain felt by more than one person, then start the process of designing, prototyping and subjecting people to your prototypes.
If, however, you start with an idea, you risk ending up with a product without a real problem to solve.
When I say “real problem”, I mean something that really bugs an amount of people large enough to be profitable (assuming you want to at least earn back your investment) or to seriously alleviate some issue for people you really want to help.
If you try ignoring your current idea at the moment and think about why you think it could help someone, then you are thinking about your assumptions. Your current idea may be awesome, but as long as you haven’t proven the need for it through research, then you’re just assuming it’s awesome.
- You’re assuming certain people have a certain need, which can be solved with an app, but you don’t know…
- You’re assuming a certain functionality of this app will do the trick, but you don’t know…
- You may even be assuming this need is serious enough for people to bother solving it, but you don’t know
Of course, you may have something in mind which already exists in some form, but you feel you can improve it. Then at least you know there is a market, but to get a share you will need to solve some problems people are having with existing solutions. Again, you won’t know what those problems are unless you ask. Until then, you’re just assuming.
But your assumptions are your friends, because they will get you started asking questions of your future users. What I’d suggest, is an iterative research process:
- Do a round of semi-structured interviews, maybe 4-5 people in your interest group. Ask them questions which test your assumptions. Some of your questions will be relevant to your users, some will not. Some of the answers you get will surprise you - this is good! Keep it loose: Ask your questions, but let people talk, go off on tangents, etc. You want to know how they feel.
- Now process your interview data: Forget about your initial idea for the moment, and focus on actual needs expressed in the data. Use the data to weed out the questions which seemed irrelevant to people, keep the ones which made sense and be sure to include answers which surprised you; what you would never have guessed was important to your interest group.
- Do another round of interviews of 4-5 people using your improved interview guide. This time, your questions should be more relevant, because you got rid of false assumptions, kept the good ones and included new questions.
- After processing the second round, you have some actual knowledge about a few of your future users. You can use this to start ideating and prototyping, or:
- Do a more formal survey (perhaps online) to try and validate your data with a larger group of people. Doing this after a few rounds of interviews means you will have sharper and more relevant questions to put in the survey, thereby reducing the risk of wasting your own time, and, even more importantly, the time of your future users!
Sorry if this got a bit long! I am writing an article on the subject, so thinking a lot about it at the moment. It’s still in progress, but I have put together a quick infographic which (hopefully) shows the process I am talking about.
1 Like
Thanks! You mean also to show storyboards to users during the interview?
Wow, thank’s so much.
Few rounds of interview - that is it!
Regarding assumptions - yes, i understand it, my current situation is: i had few problems in mind and very general idea how to improve it. So i listed few assumptions and now want to validate them, to see if this is real problem for other people. But my mistake, probably, was that i wanted to fit in one interview (i mean 1 round) too many tasks - validating problem, assumptions and idea, and on top of it trying to figure out if users would find my solution useful. Yes, i know, i shouldn’t think of a solution at this stage 
Breaking it into few rounds is the best way to go, thanks for idea 
1 Like
You’re welcome. 
It really is the old “you’re not the user” problem: We can’t expect to guess what the user wants, based on our own feelings about a problem; we have to ask to find out. But before we can ask, we need to figure out what to ask - again because of our own biased minds.
Doing more than 1 round of interviews, then really digging into the data, tends to clear up a lot of ones own bias. You could do more than 2 rounds of interviews I guess, but it has to stop somewhere, right?
1 Like
Exactly! That’s why i wanted to prepare for it so thoroughly. If i ask wrong questions then interview is useless.
Another challenge now - conducting it online due to quarantine. Hate it 
Yes. And several rounds of interviews can be used to modify these boards. Maybe not the first round. but this approach needs a different interview style. storyboards helps when working together on an idea or pitch the idea. it is good to see the reaction when talking about a scene. but it will fail in a “standard” interview where your user is talking most of the time.
1 Like
Good point thinking in terms of “jobs to be done”: The user has a job that needs doing, and you want them to “hire” your solution for it. So to get hired, you need to know the specifics about the job(s) to be done. If you start out with a storyboard filled with your assumptions of the jobs-to-be-done, then modify it along the way, it will also help you keep a clear idea of what you want out of your interviews - it somehow has to be translatable to a job-to-be-done.
Btw: Innovation consultant Anthony Ulwick has written a lot about Jobs-to-be-done and what he calls Outcome-Driven Innovation.
The iterative research approach I mentioned above is inspired by these concepts, although in the organization where I have done research in this way, we took a slightly more relaxed approach than Ulwick recommends. His way seems more geared towards consulting firms doing major market research projects for clients.
1 Like
Yeah, but phone or video interviews can work well - whatever has the best audio 
1 Like
Thank you
great, thanks so much