How to build a successful app or other solutions without understanding users’ needs? There’s no point in it. We’ll show you the 7 rules of a well-done problem interview. That knowledge should drive your actions in app development.
When building a new digital product or developing a solution that is already on the market, remember to talk to your users about their problems and challenges from time to time. They will help you set the right direction for your product development. Don’t forget about users’ needs, especially when you are going to build a new product and you want to make sure that you are not building something based on a hypothesis, but on real market feedback. Believe me, it would save you time and your money.
Why problem interview is so important? When and how should it be done? I’ll describe and explain it below. I’ll give you also a useful checklist at the end to enable you to find possible problem areas in your app development.
Why, for whom, and what for?
The first very significant thing that you should always remember is that when you build a new digital product like an application or a website, you do it to get someone to start using it, right? Users usually expect that it will solve the problems and challenges they face. Problems and summons aren’t the only areas you’ll touch. You will also touch user processes, you will interact with people, etc. In most cases, you will touch these 3 areas: processes, people, and tools.
If you don’t do it correctly and your solution, for example, will change your users’ current process too much, they won’t use it. Why? Because the applied solution of yours will need too much effort from the user. The same principle applies to people – if your solution requires changing half of your business because existing users can’t start using your solution. Also, if the way you solve problems is too complicated, your users don’t understand it. They’ll just quit and never come back. The key is to understand that you need to make changes that are easy for your users to adapt to them.
So when should you start doing problem reviews with users? The answer is quite simple: before you start creating or building anything.
How to do it right? Let’s start from the beginning!
An idea of an application that will solve specific problems of your potential users was born. You have certain hypotheses and you know the problems you intend to solve. But have you checked them with your potential users? Are they their REAL problems?
You should verify the market at this stage, and check your hypotheses by conducting a problem review. If it turns out that users do have these problems and you find out how they deal with them now, then you go in the right direction! The first interviews you conduct should help you achieve your basic goals.
Goals of the first problem interview:
-
Know the process. How do users deal with the problem without your solution? You need to understand the whole process. If you are going to change the process, you need to understand how they do it today, where they have to fight, where they need help, and what alternatives they use. Only based on that knowledge and understanding, you will be able to provide something valuable.
-
Inspire the user. When you show your users that you can help and provide something that will make their lives easier, you will find that many of them will be more than happy to help you, too. And it is the voice of your users that is the most important advisor you should listen to.
-
Get involved! Conducting problem interviews, remember that your role is to find people who will become the first users of your app in the future. When you come back to them with the solution, they’ll spend some time testing it if they feel it’s something they need.
7 RULES OF A WELL-DONE PROBLEM INTERVIEW
-
Don’t suggest the answer. Ask your users questions about how the process looks like today, what they do and how they do it, what they struggle with, and what tools they use.
-
Ask open questions about their problems.
-
Ask if something seems important to you! You must dig deeper when the user responds and the topic seems important to you. Surely after two, three, or five interviews, you will start to notice certain patterns and each subsequent interview will be easier to conduct.
-
Don’t forget to enter the correct entry. You should show yourself to the person you are talking to. Explain what the context is, what areas will you deal with, and what problems you are going to solve. Make a good introduction.
-
Present the problems you want to solve. The introduction should be short – not showing too much of the solution. If you show something, it should be more like an inspiration. You should ask questions about processes, people, and tools – not about the ready solution itself. For example: how do you communicate with your client today? How do your customers find you/how do you find the client? What kind of tools do you use and what are you struggling with? What are your problems? Pretty soon you’ll see that your client describes a process to you. You’ll be able to draw it very quickly, and connect with the people involved and tools that are used today. Sometimes you may be shocked to see how far this is from how you think people work.
-
Magic wand. Ask users how they would like to solve their problem if they had unlimited possibilities. Let them imagine that they have a magic wand and they can completely change the way their work or function today and the way they can solve their problems. Can they tell you about their ideas? What they would like to change? How would they change it? This is where the user can inspire you!
-
Ask for help. Ask your interlocutors if they will be open to help when you have your solution ready. This is that engaging, inspiring moment when you ask people for their help in the future. At this point, you will also detect potential early users, people who will be interested in using your product for the first time.
Mistakes to avoid
The biggest mistake you can do is to list the potential problems and ask users whether they had them or not. Surely most of these questions will be answered “no”. You will learn nothing, it won’t give you any value and very quickly you may summarize that there is no problem to solve because everything works correctly. But if instead of listing problems, you ask detailed questions about how the process is going, how you work today, and how you do things today, you will discover that problems exist and your solution can help users to solve them.
Summary
When conducting the problem interview, remember to get to know the user process well, inspire your interlocutors, and don’t forget to get involved!
As promised, at the end I am sharing with you a checklist that will help you find areas where errors may appear in your application and diagnose them. You can download the checklist here:
