Designers, engineers, marketers, content creators...we all need to learn how to interview users and learn things from them. Interviewing Users provides many examples and case studies for you, which is great.

The Book Review Podcast(Mandarin)

Video book review by Bear Liu

Why do designers need to learn interviewing users?

In my first design career period as a graphic designer, I didn't regard interviewing users as a task that a designer needs to do or need to know. The art director was my god at that time, even the clients didn't matter because I didn't have many opportunities to communicate with them directly.

When I became a digital designer, and then founded a design agency years ago in China, I knew the opinions from the clients are quite important. At that time, I knew that different clients do have a different perspective and their own needs, through those needs are theirs, not the customers.

Now I'm a UX/digital product designer, interviewing users became an essential part of my design process. I knew it is a critical part of a designer to validate your concepts and to find out the answer of 'whys.' User interview is the best way to find out what are the reasons behind a user's behavior or a user's needs. You can't skip this part. Otherwise, you will be the naked emperor in the Emperor's New Clothes.

Who needs to learn user interviewing skill?

If your job is related to the product or service for people, you need to learn how to interview the people who use your product or service, in other words, your users. Designers, engineers, marketers, content creators...we all need to learn how to interview users and learn things from them. Interviewing Users provides many examples and case studies for you, which is excellent. There are heaps of tips on how to interview users in the field in the book Interviewing Users by Steve Portigal. The book was published in 2013, now many things changed, but surprisingly most parts of the book work the same. That's the benefit of investing your time on the knowledge that doesn't change rather than on the trendings always change. People don't change too much in a few years, so the people skills such as interviewing users don't change too.

As a designer, I'd like to use three movies to describe my strategy of doing user interviews. They are Ocean's Eleven, Free Solo and King's Speech. Each movie stands for each period of the whole interview process.

Before the interview: Ocean's Eleven

In Ocean's Eleven, a movie about a complex robbery, the action only took a few hours, but the plan spends months. Ocean, the main character of the movie, started to plan his robbery by recruiting the right people. Then they did detailed research, divided the plan to small steps, set the goal for each step, worked hard, and rehearsal the plan again and again. That's what we are going to do before the interview.

Before you go to meet the users in the field and talk to them, at least do a little bit of research about the people you are going to meet. Read their profile, list the things you would like to know about them. You can write down a semi-structured script for all the questions.

Arrive at the place 10-15 minutes earlier and go through the questions you would like to talk, check the environment to get more information about the users.

Generally, plan carefully before the interview, like what Ocean did in Ocean's Eleven.

During the interview: Free Solo

I like what Steve mentioned in the book, 'I don't go out into the field with a very strong point of view. ' Actually, when we interview users, it's like the movie Free Solo. Do it with your intention and curiosity, but just let it go. Suggest to leave the note (your safe robe) and let your curiosity lead you to the questions you would like to ask. That's what the Free Solo means. I know for researchers this probably not the best idea, but for designers, curiosity does a great job on leading you to find out the answer of 'whys.'

I don't know what's the situation that other people have, but for me, I usually can't cover all the questions on my list. Many times I didn't ask the most critical questions, and I always regretted a lot after that. That's why I think to let go of your note probably a good idea. If you don't have a note in the field, you will naturally remember the questions you really would like to ask, maybe just 2-3 questions, but they are enough.

After the interview: King's Speech

What are the designer's outputs for a user interview? For me, they are personas, scenarios, user flows, and other artifacts. But I saw many times that a team didn't follow the data and feedback from the research, but fell back to the original plan. Some times I thought it was the stakeholders' fault. They didn't understand the problem, and they were afraid of change. But now I think differently. It's the designer's responsibility to share the insights you got from the interview to the stakeholders or the clients. As a designer, you need to take ownership.

But how?

I think the best way to keep everyone in the team on the same page is by telling the users' stories. The story contains rich data and could be easily understood by other people. Designers are always thinking artifacts (especially visual outputs) are important, actually, the story is more important.

Prepare the King's Speech by telling the story about the user you interviewed. If your story can touch other people without any artifacts, you are a senior designer.

Wrap it up

Interviewing users is an essential skill for a designer. Do invest some time on it, sharpen the skill by practicing a lot. You will become a better designer.

By the way, interviewing users is not exactly the same as user testing. Interviewing is about exploring, and user testing is about validating.

If you are interested in knowing your users, you could start by reading the book Interviewing Users. Thanks for reading, and thank you, Steve, for writing this great book.

Useful link

An article on Toptal “How to Conduct Remote User Interviews” which includes a discussion about the important steps to prepare for great user interviews, some useful tools, and a remote user interview cheat sheet.

Here's the link for your reference: