Readers of DFA know that I'm big on not immediately giving customers what they asked for, and instead asking the question "why" to learn what the real latent customer needs are. And for you internal analytics folks, remember your employees, vendors, etc. are your "customers" whether you think of them that way or not! Anyhow, some of you may be wondering why engagement is low, or you're not getting the results you hoped for. If you're not sure where to start, here is a super easy script:

1. Recruit your customers for a 1-on-1, 30-60min screen-sharing meeting, or in-person meeting (even better). Tell them you're doing some customer research to learn about what is working and not working about the tools/solutions you manage and work on. You can also share that no advance preparation is needed and let them know their feedback would be extremely useful in making your service more useful, usable, and productive in their work. Note: scheduling can take some time, and you can even outsource this effort. One other thing we sometimes do here with research is to avoid sharing the specific thing we're going to discuss, to avoid users going and doing "homework" ahead of time to familiarize themselves. This may not be possible though, but if you can obfuscate it a little, that is sometimes a good thing. Your customer is likely to feel like they are being "tested" during all of this, and so your job is to help them learn that you're there to evaluate the service, and not them. Avoid using the word "test" and use the word "study."
2. Open the session by asking them to tell you their background/bio. If possible, get permission to record audio/screen capture and mention it is only for internal review purposes. At the session, ask the person, if you don't already know, what their overall job responsibilities are and then ask how your service fits into that. At this point, the customer is self-reporting, so take this with a grain of salt. If they immediately start showing you interactions with your service, that is GREAT. Let them run wild, and keep asking questions that encourage them to demo the product back to you as they use it. Encourage them to "speak out loud" and give praise for feedback. I usually end up repeating the phrase, "thanks, this is awesome feedback" 20 times in a session. Note that you aren't praising their specific actions: you need to say this whether they do the right or wrong thing with the service because the feedback itself is what is being praised. Anyhow, chances are, after the short "bio" chat about their job responsibilities, they probably won't open up any tools as they will be expecting you to lead. As such, you now want them to open the tool and proceed further.
3. Ask the customer to open up the service/tool you plan to discuss. Note: the study has already started at this very moment. Take special note to focus on what you see them DOING much more than what they are SAYING. Take note of things like
   1. Was the service bookmarked in their browser or easily accessible?
   2. Did it look like they were fumbling around just to launch it (e.g. haven't used it in a while, but don't want to admit it?)
   3. Was the login/password forgotten or not immediately accessible? These are all good signs customers aren't utilizing the service.
   4. If they need help after a bit, help them, and state, "If you haven't used this in a while, it's not a problem. I can help you get access to the tool." Note that this is called an "assist," and you want to do this only after you have concluded that it is rather obvious the customer can't even get past the login. Typically, in research, your job is also to avoid assisting.
      • Remember too, that this is NOT a training session but a discovery session to learn about what is happening in the wild when you aren't around.
      • Additionally, your goal isn't to scold them for not using your service, but to try to solicit useful information and honest facts from them. As such, during this simple act of opening/accessing the service, this a great example of where Actions speak louder than Words. Your customer might have told you they "use it all the time," but in reality, if you see them fumbling to try to simply open your service, you can see that what they're saying may not be quite as true as what they are doing. Keep this concept of "doing" over "saying" in mind as self-reported behavior is often very misleading. This is one of the core things that I see my clients/stakeholders getting wrong. You cannot necessarily believe customers/users' needs as verbally stated. They do not always know what they need, and their reporting of past behavior is often flawed. Which leads me to my final / next step: the recent history question.​
4. "When did you last use the [service] if you can recall? Can you show me what you did specifically, speaking aloud as you go through it?" This question is specifically worded in such a way that you're not asking them in general how they use the tool, but instead, you are asking them to demonstrate a SPECIFIC use case they worked through to get some useful insights. This is much better as it forces them to use the service and show you their UX. You are likely to learn a ton here, and one of the best things you will learn is stuff you never even knew to ask about! You might see strange behavior patterns, ping-ponging between screens, opening up of external tools/spreadsheets, etc. This is all very good feedback.
   1. If the user fumbles quite a bit with your request and it's obvious they don't know how to use the service, it's ok to just tell them, "if you haven't been in here in awhile, that's ok. Can you tell me what you think this service might be useful for? What might you be able to use this for?" At this point, you're now observing their clicks, and encouraging them to "keep thinking out loud." Note that this is unscripted intentionally, so you want to let them take tangents and follow their instincts. Your job is simply to collect information and not judge their skill with the service.
5. ​At the end of the session:
   1. Invite them to ask you any questions they may have.
      1. ​If your service DOES have a way to solve the question they have, don't tell them this and instead ask, "Do you think there is a way to do [do that task]?" Invite them to "try" themselves. If they get entirely lost, but your service does have this feature/need met, provide an assist to them, and then ask them to continue. Remember to encourage them to think aloud the entire time, and tell them, "we're here to evaluate the design, not you." Most customers feel like they are "dumb" when they fumble for too long (we all know that feeling when we can't open a simple bottle, or figure out how to open the door, or some other poorly designed system that seems like it should be easy!).
      2. If your service does NOT have a way to answer their need/question, encourage them to explain to you what end goal they have and what would make the service awesome. It can be pie in the sky; that's ok. What you want to avoid is encouraging them to start designing out the system in that moment, and instead, focus on what they personally, would think is valuable. Users also have a tendency to want to talk for others and think they are unique so watch out for, "I think most people would X, but I probably wouldn't." You want to learn about Y and not X in this case so keep coming back to them with things like, "that's great feedback thanks. Can you tell me what YOU would need/do/want that's different from what you think everyone else needs? I am really curious about your own particular needs and it sounds like you think they might be unique."
   2. Thank them and ask them if you can be in touch with them again in the future as you integrate their feedback. Your job is to develop a long term relationship and let them know that you need continuous user feedback to make the service better, and that their feedback contributes to a better user experience. Most customers love helping out.

Need help? Set up a free micro-consultation call with me on my contact page.