top of page

Stop Guessing: How to Actually Learn What Your Users Need

Ever built a feature nobody uses? The most-effective software products are built with how their users actually work in mind—not how you think they work. If you engage with a professional designer, they’ll want to lead this process. But if you’re undertaking this effort on your own, here are some guidelines on how to structure that user interview.


Choose wisely

You don’t need a ton of people in your sample audience. It’s best to think about how many broad types of users you have and get 2–3 of each. If your app has both customer-facing and internal users, that means 4–6 interviews. The key idea here is to get more than one perspective, but to keep things manageable. You’re looking for overarching themes, not hyper-specific feedback.


Put them at ease

Set the stage at the beginning of your interview. Draft an introductory script that you’ll read each time. Explain the purpose of the interview to them. Sometimes people come to these sessions feeling like they’re under a microscope. Do what you can to make them feel at ease.


Hi, my name’s Brad. I’m helping to redesign the assset tracking app. Your candid feedback will help us better understand how people use it today, what works, and what could be improved. There are no wrong answers! Just respond with whatever first comes to mind when you think about the questions I’ll ask. 

Make it experiential

People generally aren’t great about remembering how they do a thing (especially a thing they are experts at). This is why it’s often better to watch someone do a task than to ask them about it. If observing them isn’t possible (as it often is not), ask them to tell a story about their work. 


Story time

If you’re taking the storytelling route, try this approach. Let’s say you’re redesigning a grants management system. You might ask…


Tell me about the last time you processed a new grant application in the tool. What steps did you take?

Give them space to talk at length and take notes of areas you want to follow up on. Listen for places where you didn’t follow the progression, they seemed to jump ahead, or things just didn’t make sense. Ask for details. Other things you might listen for include:


  • Changes in emotion (positive or negative)

  • Allusions to workarounds or shortcuts they’ve developed

  • References to other tools or people they sometimes employ

  • Indications that things worked differently before (good or bad)


Ask for the good and the ugly

Now that you’ve gotten a sense of their workflow, dig into what works well and what could be improved. These can be direct questions such as, “What works well in this process?” and “What do you wish worked differently?” Some of this may have already come up in the prior section. That’s fine! These interviews are rarely linear, so you might find yourself jumping around your guide. This is a good sign that you’re facilitating a natural conversation. 


If you’re struggling to get responses to this one, you can make this experiential as well. 


“Tell me about the last time you had a problem logging a maintenance request. What made it difficult? How might you fix that?” 

People generally will remember especially difficult (or successful!) scenarios. At this point, it’s less important whythese scenarios were hard/easy and more important that we capture them. That brings me to the next point…


Their answers ≠ the answer

You’ll hear a lot of ideas during these conversations. Here’s the crucial thing to remember: you’re not interviewing users to capture their wish list. We’re interviewing them to understand how they work and how their existing systems are helping/hurting. If there are challenges to solve, the solution may not be immediately obvious. Sometimes a minor tweak in back end processes or how information is presented can have a major impact. Other times, seemingly obvious quick fixes can have negative downstream effects. The reason we’re conducting these interviews is to get a better sense of the big picture, but each interview is just one datapoint within a larger whole.


emphasizes that users' answers are not the definitive answer for what you should build

Let them talk

Finally, a key point to consider throughout these interviews: let the interviewee talk. Most people are uncomfortable with silence. Ask a question and then let the respondent answer. When they come to a natural stopping point resist your natural urge to fill the gap. Let the silence hang. Your interviewee will often have more to add! 

This approach can be a little uncomfortable at first, but you can pretend you’re focusing on your notes. You can also use phrases like “Say more about that” and “Tell me more about processing return requests” to help pull more out of quieter respondents. 


What to do next

Next time you’re planning a feature or redesign, block 3 hours on your calendar and schedule 4–6 of these interviews. Your future self will thank you.

 
 
bottom of page