6 degrees of separation in understanding user queries
Be grateful. Be flattered. Be outright ecstatic. Why?
Because users think you’re a mind reader.
For some reason, they think telling you “I can’t do X. Please help.” is enough. They don’t tell you
- which application it is
- where or which screen in the application it is
- any error messages they see
- what they did (before they got the error message)
They sometimes just don’t tell you enough.
6 degrees of separation is already too much. Users expect you to make amazing leaps in intuitive logic from their pathetic amount of information to whatever is ailing them at that moment. That’s one giant step of deductive debugging.
How do you understand their queries better? Just ask. Ask for more information. This is where your people skills come into play. You’ve got to ask them in the way that makes them feel good about themselves. Basically, you want them to feel like they’ve done everything correctly and it’s really the fault of the software, even if you think they’re complete morons.
You’ve got to coax them into telling you stuff. And it doesn’t help if you keep calling them an idiot.
This brings us to the next problem. Users lie. They don’t lie outright. They just don’t tell the truth sometimes. And it’s not because they purposefully and specifically lie to you. Sometimes they just don’t know they’re telling a lie.
The spelling misunderstanding
For example, I recently had this user say he couldn’t use an application X because of an error. I probed further and managed to pry an error message out of him. Something about a missing file. There was this part “Pls check and proceed”.
Well, I thought, the more unique the error message is, the easier for me to locate where in the code the error occurred. Ever since I took over maintenance of legacy programs, I love it when there are unique error messages. Incorrect spellings, short forms of words, unusual text (like two consecutive spaces), incorrect grammar. Searching entire source code with unique search phrases means there are fewer search results, increasing the speed of finding the actual code.
So I typed in “Pls check” into the search box and ran the search. Nothing. What? I looked at the whole error message and nothing stood out as unique. So I got the user to give me a screenshot. The actual error message was “Please check and proceed”.
Did the user lie? Not really. He read and interpreted the error message correctly. It’s when he’s conveying the error message back to me that information was lost. For him, there’s no difference between “Please” and “Pls”. For me, it’s absolutely critical that every single letter was correct. Sometimes even letter casing matters.
This is the heart of understanding user queries: Understand the user.
I maintain many programs and applications, and I work with different sets of users. These sets of users usually don’t know that I work with other applications and users, so sometimes they ask me something expecting me to know the context of their query (when in fact I have no clue).
Here’s a list I use for probing
- Ask for screenshots
- Ask for error messages
- Ask which application they’re using
- Ask which screen or web page they’re on
- Ask which button they clicked to get the error
No information is redundant. Debug like a CSI because you should “Follow what cannot lie, the evidence”. In this case, any information you get is evidence. If their version of the error message contradicts the one in the screenshot, then you can ask further. One or the other must be wrong. Either way, you get more information.
When you’re trying to understand user queries, there’s no such thing as too much information.
Your lifesaver, the screenshot
There’s another case where the user was asking why the update button doesn’t work and the application keeps hanging. No error messages, and he told me which application and screen he’s using and even which button (the update button).
In the end, I asked for a screenshot. Everything looked to be in order. Then I looked at the taskbar in the screenshot. He opened 3 instances of the same application, performing the same task at the same screen. That was the problem. Due to data concurrency and locking, the application instances simply got stuck. I told him to use just one instance and everything was fine after that.
Did he lie? Yes, because he didn’t tell me that he’s running 3 instances of the application, which wasn’t designed for that. Was it really his fault? Not really. He thinks doing different updates with 3 separate instances will speed up his work. Like he’s multitasking or something (a mindset shared unfortunately by many of my users…).
What you should strive for is answering the user query with whatever the user first supplied. That’s ideal of course, and usually hard to reach. The next ideal case is this:
- User sends you email with query (with insufficient information)
- You understand whatever is given
- You formulate intelligent questions
- You call (or email) the user and ask those questions
- You finally understand what the user wanted
- You close off the query, whether it’s fixing bugs or answering questions
Calling is usually better than sending another email. You can save a lot of emails bouncing back and forth if you can just talk on the phone. Your ultimate goal is to minimise back and forth communication.
You may not be able to understand and answer user queries in 1 degree of separation. But with a little thinking first, you can do so within 6 degrees of separation.
Tags: answering user queries
Comments
5 Responses to “6 degrees of separation in understanding user queries”
Sign up now to get your free ebook of "How to self-publish an online magazine". Your email is kept confidential, and is used only to send information about the magazine.
Hi! I write about maths and programming and other topics of esoteric interest. I'm also the editor of the online magazine Singularity, and you can get the latest issue at the top (it's free!).
[...] For example, in one of my user task requests, there was this requirement about entering random input. Based on the business context and the web form that was to support this feature, I deciphered it as being able to enter any range and any number of input in a specific format. I checked with the user, and it was indeed that way. Sometimes users lie, unwittingly perhaps, and in this case, using the wrong words to describe what he wanted. [...]
[...] because the other 2 are more urgent. Now, you are already half way through the email query, finally understanding what the user was trying to ask in the first place. Then the data patching request comes [...]
[...] said she couldn’t see the PDF file. She only said there’s an error. This was where my user querying skills came into play, and I finally convinced her to send me a screenshot of the error (it was fortunate [...]
[...] best weapon for handling user queries is the screenshot. User: Hey Vincent, I’ve got an error when doing X. Me: Send me a [...]
[...] than a few seconds to think through. Sometimes, you have to really push for lots of hints, like clarifying the user’s query, ask for screenshots (even if sometimes they aren’t enough…), and dig through code [...]