How to Make the Most of the User Interviews in a Sprint

Needless to say the user interviews are an emotional roller coaster, customer reactions are actually not merely reactions to you, but in a way it’s your very own academy award, obviously if the reactions are confused you’ll be frustrated, you’ll also be disappointed, but when they understand your product, something you have been working for years you will be elated.

This brings us to the question that how do you go about choosing these people who play such a pivotal role in your product design?

This usually is a process where you recruit participants that closely match the profile of your target customer and not only customers but your mentors.

We are now subjected to the question of when to stop? What is the exact number of interviews it takes to get an exhaustible data of things you need to work upon to get your product pixel perfect?

We say five is a magic number

We came to this conclusion when we were conducting user interviews for an in house product Mysish, we plotted how many problems in the application were revealed after 10 interviews, 20 interviews and so on.

These are our inferences

  • 5 people could point out nearly 85% of problems
  • Rest could point only 15%
  • Thus rest of them were a sudden drop in return of income

We would strongly suggest that aiming to receive a data that completely covers the entire spectrum of problems with your application is tedious and a futile task simply take down the 85% and test again.

, , ,
Previous Post
Date Time format for an ICS File using C#
Next Post
The Dilemma Of A Parallel Sprint