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.