Five Ways Users Self-sabotage When Reporting Problems

In desktop support and in software development, there runs a common thread - responding to requests for help from users. And this remains some of the greatest tests of patience known to man. Not because the problems are tricky, though sometimes they can be. Not because the users are rude, though on occasion, a couple would greatly benefit from some goddamn manners. No, because sometimes, the way users report problems, just does not help themselves.

Let's go through a few ways that users' requests for help inspires intense rage could be improved.

1. "It doesn't work."

This is probably one of the most exasperating things a techie can hear. Because that phrase, and its numerous variations, basically tells you there's a problem, perhaps a general area, and that's all. It doesn't tell you anything else. No, the user informs you that there's a problem, and expects you to figure everything else from that mysterious statement.

Printer is on fire.

For example, telling us "help, I can't print" is a statement about as useful as a can of diesel to Elon Musk. "I can't print" could mean anything.

- the printer printed blank sheets of paper
- the printout was garbled.
- the print button on the screen did not respond to clicks.
- the print button could be clicked but nothing happened.
- the print button flashed, beeped, triggered the Fire Alarm and rebooted your life.

For extra aggravation points, the user might even write an email with a few paragraphs while including no information as to what the problem is, beyond "we're unable to print", ending with "we would appreciate your help as soon as possible". That in no way sounds like they want our help as soon as possible. In fact, it feels distinctively like they'd rather we take our own sweet time to decipher what the problem actually is, before we do a damn thing.

How To Do Better: Users should actually describe the damn problem beyond "it doesn't work". Because if it did work, there wouldn't be a need for this conversation.

2. What are we looking at?

The user tells you what they see on screen. Sometimes they even send you a screenshot. Neither of which is helpful, because what you see isn't an error message. It's something that looks perfectly innocuous on screen, and only the user knows why it's wrong.

Except the user has neglected to tell you exactly what is wrong. No, apparently having a tech degree means that you can somehow infer what the problem is, in the absence of any other indicators. Which leads me to think that the problem is not that systems have bugs. It's that system users think tech is actually witchcraft.

Not witchcraft.

So if you see a series of numbers in a column, you're supposed to magically know one of those numbers is supposed to be negative instead of positive. If you're sent a screenshot of a message that says "Record Saved", you're supposed to instinctively know that the problem was that the record was, in fact, not saved. Or perhaps the problem was that the record was saved when it shouldn't have been. Or perhaps the problem was that it was spelled in English, when the user's settings were in some other language. Who can tell?

What is with all this vagueness? Do users realize that if techies were capable of reading minds, we wouldn't be working here?

How To Do Better: Users should tell us exactly what they expected would happen but didn't. Without that information, it's hard to tell whether anything is wrong in the first place.

3. How did they get there?

This is when the user tells you what went wrong, and maybe even why it's wrong, but neglects to explain how it came about. Which is kind of like Hansel and Gretel wandering around in some dark forest and neglecting to leave breadcrumbs.

Leave us a trail!

In order to properly diagnose the source of the problem, we need to trace exactly the steps that the user took that led to the problem. In certain cases, this can actually be a case of the user using the system in ways it was not meant to be used. For example, trying to log in to a system and being unable to... and failing to mention that the URL they're using is the UAT site's rather than Production's.

Some users want to avoid looking stupid and leave out that information, perhaps hoping that the air of mystery will help. If I need to point out the irony here, you haven't been at this job long enough.

How To Do Better: The user was doing something that led to this. Whatever the user was doing, needs to be properly articulated because it is probably relevant.

4. Screenshots

For some unfathomable reason, when there's relevant information in a string that needs to be passed to the software developer - such as an id, URL or IP Address - users seem to prefer sending them as screenshots.

Exasperating as all hell when there's info in there that you now have to type out character by character, and probably make a few typos in the process. Now with modern tools such as LLMs that can analyze the image, this has become only slightly less exasperating.

Don't send pictures
of text, please!

Why is this completely stupid? Well, when you're being asked for help, generally, you'd expect those asking for help to at least try to make it easier for you to help them.

Also, copying and pasting text is significantly easier than manually reproducing text from a screenshot. But copying and pasting text takes about the same amount of effort as pasting a screenshot. Now, I could understand if the users were inconveniencing me in order to make their own lives easier... I wouldn't like it, but I would at least understand it. However, at this juncture, they're inconveniencing me without actually making things easier for themselves, so this entire exercise of pasting screenshots remains a damn mystery. It has zero practical value.

The truly horrifying thing is that this isn't confined to laypersons - other techies do it as well. Yes, this brand of insanity isn't confined to people who aren't actually expected to know better.

Bonus points for writing stuff down in handwriting that would make a doctor proud and sending a photo of it, instead of typing it like a normal person.

How To Do Better: Unless the information is wholly visual - colors, layout, etc - and does not include text of any kind that needs to be used by the support - ids, ip addresses, dates, etc - screenshots should not be used as a primary means of communicating the problem.

5. Jumping to Conclusions

This is when the user self-diagnoses and ends up sending you on a wild-goose chase. To be fair, even techies are capable of jumping to wrong conclusions with alarming frequency... except that in the case of techies, their wrong conclusions tend to be directionally correct. In the same ballpark, even.

Laypersons, as mentioned, tend to treat tech like witchcraft, so their wrong conclusions can be comically inaccurate. I remember one fascinating incident where the user reported that the changes to the database were not persisting. The next point of escalation was to the database team, because naturally, support had no direct access to the data. After days of barking up the wrong tree, it turned out that the fault was in the front-end code - it cached the previous result even though the data had been updated, thus misleading the user into thinking that it was a database problem.

What users should do, in these cases, is stick to the facts. The user should have just reported the simple fact that her display was showing previous data even though she had already updated it. This would have set support further back on the path, but at least they would not have been miles ahead on the wrong path.

Barking up the
wrong tree.

In this instance, though, I blame the techies for taking the complaint at face value in the first place. When are we going to learn to stop giving users so much credit? If you consulted a doctor and proceeded to diagnose yourself while asking for medication, could you expect to be taken seriously?

How To Do Better: Skip the diagnosis. Lay out the issue properly. Nobody's interested in your opinion - in fact, it tends to muddy the waters. Stick to facts.

Don't make yourselves un-rescuable

If users want help from techies, they should try making it easy for techies to help them. Or, at least, stop making it so devilishly hard. When you report a problem, just try to put yourselves in the shoes of the ones receiving your report, and see if it makes any damn sense.

Whats your problem?
T___T