I’ve mentioned the importance of usability testing on this blog before. This time I’d like to talk more about the very beginning - the research part of the project. For the purpose of this post, I will assume that your project is a greenfields project.
Firstly you would have already analysed the market and noticed that no one has done it before, or at least no one has done it the way that you plan to. You and the core team you work with, perhaps your co-investors or specialists in the area you’d like to innovate, start working on your project.
You draw, sketch and ideate, plan and work on determining every aspect of how the idea will present itself to the users. You end up with a list of requirements or even some screen layouts or storyboards identifying what you want to achieve and roughly how. You then take this idea to development - either to a developer or perhaps you start developing it yourself you have existing programming skills. The reasoning behind it being: I’ll just get it out there, have a functional MVP that we can test with users and tweak later. While this approach has certainly worked for people in the past, I recommend trying something slightly different. Rather than approaching it from the viewpoint “here’s this tool, what do you think?”, approach it from a “do you need a tool?” angle..
Most software products aim to make someone’s life easier, so why not sit down with these people and get them to have a chat with you? Regardless of whether you are trying to automate existing paper processes in a very specialised environment or building a SaaS service for a more general audience, listening to people who are meant to be using your product helps. A simple 20 minute interview with a prospective user can highlight an incredible number of issues/concerns but also opportunities for the new software.
Some of the concerns you might have are: How do I make sure these interviews are useful? People have trouble imagining my app without seeing it, and it’s too complex to explain.
Simple answer - don’t. Don’t make anyone imagine anything. They are not there to react to your product or evaluate it. They are there to talk about their life without your product. Ask them how they get things done today and how they did it yesterday. Ask them what tools they use and what they like/dislike about them. Ask them to describe their current processes and what they find most beneficial and/or frustrating about them. Ask them to tell stories, mention an instance from their lives where they had to get something done that is related to what your app is trying to help with. If you have a question starting with: “So, if we built an app that does xyz, would you.” delete it immediately. People might say ‘yes’ just to be nice or they might genuinely think they will use it. Whatever the answer, it will be severely out of context and as such, unreliable. You run the risk of building it and it not getting used only because your interviewee imagined it differently.
Okay, but I don’t want anyone to steal my idea. How do I prevent it?
They can’t and won’t. If you follow the advice in the previous paragraph they will not find out what your app will be doing. All they will know is that you chatted a lot about their exercise routine, their online shopping habits or their childcare needs. If your interviewees found out enough about your app that they can seriously consider ‘stealing’ the idea and beating you to it, you need to quickly re-evaluate those interview questions.
I’ve done all these interviews, gotten a bunch of stories, now what?
After a couple of interviews, you and your team can sit down and think about what you learned. Some features might be cut, others changed, and some others kept exactly the same. If you find at least one thing that was obviously very useful to everyone in your team but your interviewees didn’t express any desire to have that area of their process improved, it was worth it. You may still include the feature of course, but at least you’ll know that you need to emphasise the benefits within the app somehow to try to get people to use it.
Of course there is a lot more to conducting effective user interviews. This post isn’t meant to be a “how-to”. It’s more of a “why to” and I hope this post managed to highlight some of the benefits of adopting this practice. Next time you are building something, especially something new, please consider this UX research method - it’s inexpensive, quick and very helpful.
