The last fifteen seconds of an interview are sometimes the most insightful
How to address ‘doorknob questions’ that might give you crucial users insights
Sometimes, the last fifteen seconds of a user interview can be the most shocking and insightful.
One of your last user interview or testing questions is likely to be, “Is there anything else you would like to tell me about?” Most of the time, the user will likely say no or re-iterate an earlier point that they made, but sometimes that’s when they’ll drop a bombshell on you.
This is known in many fields as the doorknob question: someone’s halfway out the door when they ask a question or comment that adds a layer of complexity or urgency to the situation.
For example, one thing that I’ve encountered, right as the user was ready to pack up, was a baffling but straightforward comment: “I hope the new application supports copy and paste.”
Digging deeper, I found out that some text fields in the current application would mess up the formatting so severely that it was faster for users to re-type 500–1000 word statements they received through e-mail rather than fixing formatting after copy-pasting.
Users might not want to bring this up earlier in the interview for many reasons, such as wanting to be polite or expecting a task to address this earlier in the test. Still, these statements can often give you insights that would otherwise be completely hidden from you.
However, a little bit of preparation for structuring your user testing can make sure that you hear these statements when you have enough time to address them.
Flipping the script and giving yourself time
One of the most important things to do is to give yourself more room to work with (and make sure that you aren’t entirely taken by surprise), which is to change the wording of that question.
Instead of asking, “Is there anything else that you would like to tell me about?” ask the question phrased slightly differently:
“Is there anything I haven’t asked you that you think is important for me to know?”
Instead of thinking about everything they could have missed, asking them directly about what’s crucial that they haven’t talked about is a great way to start conversations that they were expecting.
Perhaps they expected to see a task (or scenario) related to something they face in the current system, but it didn’t come up. At the same time, they might not have wanted to bring something up just because there was no reasonable opportunity.
Asking the question allows them to talk about the subject directly and budget time for these situations while they’re still willing to talk. If the user has started to pack up their belongings or is shifting towards their next meeting, they’re less likely to want to sit back down and talk about things in detail.
Ensuring that they’re still in ‘user interview’ mode and not ‘preparing for the next meeting’ mode when they drop is crucial to ensure that you have enough time to capture what they might tell you.
If that’s the case, what exactly should you do? The good news is, in the age of remote user testing, we have a valuable tool for this purpose: screen sharing.
The power of screen sharing
Sometimes, it’s easier to see what the user is talking about instead of having them describe this. As a result, adding a single sentence to our informed consent forms and our introduction can sometimes yield great insights:
“We may ask you to share your screen if needed.”
Users tend not to have a problem with this, especially when you emphasize how the information will be stored securely and won’t be shared. I’ve only encountered problems with this when the organization disabled screen sharing for every employee.
As a result, seeing what they’re talking about can clue you into their process, even if you don’t understand everything.
However, there are two things you should keep in mind as they show you whatever they might:
Is this relevant or something that matters to the design of this application?
Is this something that I have the power to change?
Sometimes, they’ll show you something that may be outside the scope of your project. For example, your users might show you another system that they use to access your application, but that might be outside the scope of what you can change.
Or, they might show you something that seems unrelated, only to discover that it is part of how they currently do things (that your design will improve).
However, what if you are doing in-person user testing? In that case, make use of paper printouts.
Have printouts for in-person testing
If you’re doing in-person testing, it can be helpful to have paper printouts of the website that the user can write their thoughts on.
It may seem strange to rely on paper in the age of computer-based testing, but sometimes paper is the proper fidelity for users to scribble their thoughts. If they need to explain things, sketch out what currently happens, or if there are things they want to comment on, sometimes having it written down helps a lot.
Having just a couple of extra printouts of pages in case users need to make notes can be constructive. What’s most important, at this point, is that you’re able to capture everything that they’re saying as accurately as possible.
Understanding post-user-test what you capture
There’s no getting around it: sometimes, it’s better to spend your time just capturing things verbatim and then figure out what they were talking about afterward.
If you don’t have a lot of time, and it’s not crucial information you need to ask your user about, spend time Googling acronyms or asking your co-workers after you ensure that you’ve captured the problem or comments in detail.
What matters, at this point, is that you can use what information you found to get to the root of the problem. There should be no ambiguity about what the user said: if it’s still confusing, try to ask if it’s okay to follow up with them through e-mail.
You don’t always have to know everything during a user interview
Despite your best preparations, you might sometimes be surprised by user responses and comments during user testing. After all, you often talk with people who have years more experience than you with a product and might understand the surrounding systems you might not even be aware of.
So to avoid getting blindsided by these comments, do a little extra preparation so that you can follow up with what’s most appropriate. For example, if the person has time to talk and elaborate further on the subject, it’s great to spend the time elaborating on the problems so that you understand them right away.
However, if it’s not, the main goal is to capture as much about their problem (or ideas) as possible and then try to learn more about it afterward. Whether through the debrief, asking more experienced colleagues, or seeking information from the organization, once you understand what’s going on, you’ll have additional information to help you make a better design for your users.
Kai Wong is a Senior UX Designer, Design Writer, and Author of two design books. His new book, Data-informed UX Design, explains small changes you can make regarding data to improve your UX Design process.