How a User Error Can Be a Constructive Tool

It’s always fun to sit and talk with 2nd line support folks – the ones who actually understand the technological whatsits and thingamajigs that underpin all our IT services. And it’s especially enjoyable if done over a drink or two, and when you get them onto the general intelligence level of the users they support.

What I’ve come to realize is that many have difficulty separating the concepts of intelligence and technical knowledge. I guess it’s because they have technical skill and knowledge, AND are intelligent; therefore, they sometimes see those who do not have technical skill and knowledge as NOT being intelligent.

Although it might be slightly mean, one entertaining aspect of this to discuss over a beer is the “fun” terms adopted to describe a common underlying cause of service issues – I’m referring to a “user error” of course (or a user’s lack of knowledge). The most common terms I’ve seen are PEBCAK (Problem Exists Between Chair And Keyboard) or ID, ten, T (written as ID10T). I even saw once a drop-down list of underlying causes to choose from that included “Muppet.” Yikes! 

When I’m not kicking back with a beer, it’s clear that these terms don’t imply much understanding or sympathy for the users, and don’t improve relationships if their use becomes public knowledge: generating phrases like “unacceptable attitude” and “lack of respect.” In fact, these terms mask the importance and value of the user error concept, and how we often fail to recognize and respond to it. When understood and addressed properly, spotting a user error can be a significant and profitable driver to service and business improvement.

Seeing Past the Attitude

Incident management – with its focus on getting users working again rather than understanding causes – uses closing categories to do just that: close the incidents. They are the means by which we close the incident, but the data they represent becomes the input for problem management, where the focus is not just to find the cause but also to prevent things from happening again. A user error can be seen as and end to an incident, someone to blame, a chance to move onto the next (more interesting) issue. But from a problem management perspective, it should be the start of a path that leads to understanding and prevention.

What “User Error” Might Actually Mean

“User error” is a symptom, and there’s always a deeper reason behind it – a cause that can be addressed to prevent recurrence. Some examples are:

• Mistakes were made about user knowledge. Users without the appropriate knowledge look like users making mistakes, but it’s rarely the users’ fault. Maybe the service designers made incorrect assumptions about what knowledge the users have, or even about who the users would be. Or maybe the knowledge hasn’t been passed on to the users, or has been passed on badly and isn’t understood.
• The system is not sufficiently intuitive. Training on using IT systems is becoming ever rarer, as industry follows the online world and expects apps to be intuitive enough to use without specialized training. So… either a service has to be obvious to the people who will use it (and see above, it might not always be who you think) or else training has to be created, delivered, and reviewed.
• The options and questions presented by the service are unclear or misleading. This may be due to language confusions such as:
  • Unclear wording, especially important if many users will be working in a second language.
  • Use of technical jargon that is not commonly known by the user community.
  • Mis-use of business terms. IT is not the only group of people who hijack words and give them new meanings. If your business community does that and you don’t build it into your applications, training and documentation, then the users will misunderstand, do the wrong thing and eventually it gets written off as a user error.

So, How Should We Action Things?

Firstly, procedures should not allow any significant issue to be written down as a user error without some finer level of detail and/or triggering further investigation to establish why the user made the error. Deeper analysis is required to determine where the required potential improvement could come from. There is a wide range of possible options including:

• Service design didn’t take appropriate notice of user knowledge, skills etc. Is the service sufficiently intuitive, are training and documentation adequate and followed? And if not being followed, why not? It is rarely just because users chose not to, more likely it isn’t clear, relevant or comprehensible.
• The user base has changed since the design specification. This might require redesign for new users, restricting the service to those it was intended for or maybe both.
• Users are not being properly trained or supervised. This might be an HR issue rather than an IT one.

The important aspect here is that things aren’t just written down to “stupid” users. If your users don’t understand, then it’s the service provider’s fault, either for failing to tell them or failing to know then well enough.

See the Issue, Take the Blame, and Fix It

The key messages here are:

• Designating something a user error doesn’t move the blame away from the service provider. Quite the opposite, it highlights lack of a service provider’s design, planning, communication, or understanding
• Documenting and investigating instances of a user error is important. Breaking these down to a finer level of detail is a vital first step. Often this needs to be captured at the time the incident is recorded or addressed, so service desk and 2nd line support staff need to be aware and able to capture it correctly.
• Users should be encouraged and supported in registering when they do not understand what to do. It isn’t their fault and we (the service provider) shouldn’t make them think it is. That’s just guilt transfer.

And a last thought – this is a situation where Knowledge Management should be involved. Knowledge isn’t just about your technology and infrastructure. You need knowledge of your user community, knowledge that costs time and money to capture and maintain but will be a worthwhile investment in ensuring a decline in user errors going forwards.

Did I convince you to rethink user errors? Please let me know in the comments.