To create good solutions you need to understand your users. Plain and simple. For this, you have many methods. Usability testing, log analysis, questionnaires, helpdesk knowledge, user observations, and user interviews, to name some of them. So, why choose interviewing users as your first task in a project?

Ask questions and get answers

User interviewing is a simple and good concept. Simple, meaning easy to set up, and cheap. And good because you can get a lot of good insight.

You ask questions and get answers back. It means you can do it before you have drawn a single drawing, designed anything or written a single line of code.

What you need is yourself, a person that somewhat represents a user and possibly a notetaker. You can take notes yourself, but it makes it a bit harder to concentrate on the flow of the interview.

So, with this in mind, user interviews should be one of your first tools used to understand your users.

Figure out what you want to know

 

Users are people. And people have a lot of different aspects to them. What you want to know is the overlap between that person’s interests & tasks to be done and the business goals of the organisation you work for. This means you need to figure out the business goals of your project before you do an interview.

 

The interesting part for the team you’re in is where the outcome of the user interview analysis overlaps with what’s technically possible. You can leave the mapping of the technical limitations until after the analysis of the user interviews. Yes, you should do more than one =).

 

Turn on the stream of consciousness

You want to get your users to tell you freely what’s on their mind. For this, you need to find their on-switch. Show interest, make them feel comfortable. And let them talk without interrupting them.

 

Don’t tamper with evidence

Or tamper as little as possible. If the person you’re interviewing is not talking about something that is interesting for you, you need to steer them towards something that is. But it is really easy to take too much control and make them give you what they think you want.

 

To avoid taking too much control, these tips can be really helpful:

• Prepare a script with questions that will cover the topic or topics you want to hear more about.
• Ask really open-ended questions and general ones. At least in the beginning. Every time you find something interesting, you can dive in and ask more specific questions.
• If you can, don’t tell them what you are working with, and use need-centric words rather than solution-centric. An example is the word “find” instead of “search” if you’re working with a search solution. “What is hard to find in your daily work?” instead of “What are you searching for but don’t find in your daily work?”
• Prepare the person you’re interviewing with the notion that any answer is a good answer. No answer is wrong. You are there to learn from them.

 

The outcome of user interviews

User stories

And here I mean real user stories, the ones with a role, a task for this role to perform and a business reason to perform that task. You need the interview subject to get down to the nitty, gritty details. Use the five whys to get to the bottom of things when you smell a user story.

 

Users’ mental model

Another outcome from a user interview is often the user's mental model for how things are organised. These are the entities they structure their understanding around. It is often different than how the organisation is structured. How they map and structure a topic can help you understand how to communicate and structure what you are creating in your project.

 

Throw away or store for later

Sometimes you don’t get people to talk, or the words you get out of them are not that valuable. That’s okay. You can throw that away.

There are a lot different reasons why you don’t get people to talk, the answers they give are not honest or the stuff they say is not interesting. Reasons for this can be many, here are some:

• Bad chemistry between you and the one you’re interviewing.
• Interviewing the wrong person.
• They want to impress you. This is normal behaviour in user interviewing and user testing.
• They fear repercussions.

Sometimes you also find interesting knowledge, but just not for the current project. Store it for later. This is good. You know have a broader understanding of the field you’re working in. It will probably help you in the future.

 

Go interview a user!

That’s it. Short and sweet. You can get some really good user insight talking to users, and it’s the cheapest insight you’ll get. Write some questions, start asking people and be empathetic, patient and curious!

Or, if you need, create the user interview script first:

And if you want to assume less while building an application:

Usability testing: Easy re-testing of your assumptions with Teston