A designer’s guide to talking with users

Qualitative research is the basis of a solid digital product that people can relate to. This is why I wrote a blog post or two (in Dutch) about how important it is to involve users in your design research.

1. What do you want to know?

It may sound silly, but it is the essence of your research. If you don’t have questions, you can’t find answers. Identify what you already know (in spreadsheets or on a whiteboard) and indicate how confident you are about it. This helps to see which topic you still need to dive into.

First up: What is already there that can you measure? Check the analytics for existing apps, and the trends and market research for start-ups. You can often learn about the popularity of a certain feature or how someone uses it from software analysis tools, so you don’t have to ask about these things.

You want to talk with users about context, nuance, and feeling when the topics make you spontaneously think: “Why the hell do you act like that?”

Those subjects are suitable for interviews.

2. Who do you want to interview?

You should aim forfour or five people per persona.

A persona is a name and description that you paste on a subgroup of users. You can subdivide users by mapping the use, needs and context of the subgroups, usually with a combination of quantitative and qualitative data.

We built the initial personas at Flexmail based on what subscription they have, how often they use which feature, and what content their e-mails have. Most of them send invitations for events, by the way. The more we spoke to users, the clearer we could describe the different personas.

If you have spoken to five people per persona, you often hear the same elements come back. Then you know that you have interviewed enough people. Unless of course you come across a new persona 🤯.

3. Organise the interviews

For me, this is the most difficult step in the process. Many people cancel at the last minute or simply don’t show up. Not completely incomprehensible if you know that there is actually little in it for them. They might have to travel a long distance to give their opinion on something that only results in changes six months later. In addition, people would like to know what the project is about and what you will do with their opinion. You sometimes cannot or will not answer that question in order to prevent influencing their opinion and responses.

The tricks I apply:

• Outsource the recruitment to your customer, often the support or sales department has a good network of interesting users.
• Lower the thresholds with video conferencing. I agree you miss a piece of non-verbal communication, but you compensate for that with more interviews.
• I usually don’t give people a gift in exchange for their cooperation. There is still a bit of influence then.
• After the conversation, I always thank them with chocolate to generate enthusiasm for the next rounds of testing.

4. Ask the right questions

This is extremely important. Your chances of bias are very big here.

People that agree on an interview take the time and the effort to help you. So this person will answer in a way she thinks is most helpful to you. And this is often by giving you the feeling you’re on the right track.

This is absolutely not what you want. You want to know how people behave when you’re not there, because then you can understand which features they need in your product and which will be a waste of time.

To get the right information:

A. Ask what happened in the past

How are you doing that at the moment? What service or app do you use now? What if you didn’t have all that? When was the last time you did that? How was it?

With this type of question, you’ll get stories, real things that happened, and how people felt and reacted. This gives you hints to work with. After enough stories, you will see patterns appear and know where to keep digging.

B. Never ask why

It is a very hard question to answer! People have to reflect on their own behaviour and their thought processes. It is very easy to draw the wrong conclusions from these answers.

Better: What did you feel at that moment? When did you do it for the first time? Where were you at that moment? Who taught you that?

You’ll get much more useful insights.

C. Double-check what you just learned

If you hear stories, you automatically relate them to your current knowledge and expectations, so you can understand them. This frame of reference is also a possible bias. That’s why it is good to rephrase the insight and check with the interviewee if you understood it right. Many chances you’ll get additional nuances and insights.

D. Dive into feature requests

Don’t write down feature requests since chances are you’ll make only that one person happy. Ask more about the request, in what situation the user wants to use that feature, how they work around it now, when was the last time… You get it right?

Research may reduce your risk, but the risk is still there.
A good designer embraces this uncertainty.

5. Process the stories

I admit, I don’t have a system for this. I just read everything, I empathise with the people I met and try to pinpoint the problems — the big picture and the small details.

TIP 1: Write while listening to users and annotate (!) where you think something important is hidden.

TIP 2: Visualize. Draw on the whiteboard, in notebooks, and on post-its. Make sense of your mess, make a new story out of all stories. This helps a lot to communicate with team members or clients.

When you reach a point where you think: “I got it, I know what the problem is we have to tackle. And if we do it right, we’ll conquer the world!” that is the moment you go back to your client and ask for feedback. Then create prototypes and test them with future users.

Research may reduce your risk, but the risk is still there. A good designer embraces this uncertainty.

Good luck!