User errors: they are not just idiots

We tend to think our users are dumb. "We" are tech support, developers, product designers, and entrepreneurs. We use various memes to express that conviction: PEBCAK (Problem Exists Between Keyboard And Chair), RTFM (Read The Fucking Manual), Layer 8 (from the OSI norm of communication - it has seven layers and the dumb user would be the 8th) or even ID10T (idiot in l33t). So when a user error happens, we are eager to dismiss it as just another case of someone who cannot use a computer.

Well, I’m a software programmer and CTO, and I am an idiot too.

I am an idiot too

A few days before writing this article, I was trying to insure my new bike. I registered on a cool new startup’s website and entered the details of my bike. I went to the payment page and entered my bank details automatically using my password manager. The payment failed and I was met with an ominous "Unknown error". I was not discouraged and opened the developer console's network tab. I saw that they were using Stripe and found a "declined code". Looking at Stripe’s documentation, I learned that my bank had refused the payment. I went to my bank account and found that the card details I entered were wrong. I recently changed this card and forgot to change the card verification code in my password manager. I swiftly changed this code and managed to pay.

If I did not have development skills, I would have contacted their support. They would have figured out that I did not use the right card number and probably called it another case of PEBCAK - which it indeed was. But that would be missing the point. As a new customer of their service, their error display did not help me: I did not know what went wrong and I did not know what to do about it. I assume that the product and development team did not think it was necessary to properly guide the users through the 47 Stripe decline codes. This had two consequences. For one, my trust in their system has been hurt because I spent a few minutes on this when payment should have been immediate and easy. Second, in my experience, more than 10% of payments end up with a card declined code. I would bet that potential customers regularly contact their support because of this error, or just drop off. In fact, right after paying I had to sign the insurance contract. It failed again, with no visible error or way to track down the issue this time. I ended up contacting the support who told me to “never go back to a previous page in the onboarding flow because we have a known bug there”.

If a company pays a support team to compensate for a buggy product, it’s a good sign they should change their perception of user errors.

Respect for people

Let’s take a different view of these PEBCAK issues. My starting point is a lean concept called “respect for people”. It is a practical, managerial concept built on the following points:

• Listen to the obstacles people encounter in their daily work
• Give them the tools to do their job well
• Make them autonomous to solve their problems

We can apply these concepts to our customers too. Back in my example, I wanted to insure my bike. How could the startup website’s developers have increased my autonomy? Let’s revisit the error message.

This way of thinking should permeate the whole product and not only the design of error messages. The challenge becomes: how do we turn user errors into opportunities to increase user autonomy?

By improving user autonomy, we not only get fewer requests and more happy users; as engineers, we also get challenging and interesting errors that pick our brains and make us better engineers, as I covered in my previous piece.

Boring user errors are a signal that we need to clean the window.

Empathy with the user

The most useful tool I use to put myself in the shoes of the user is the “client complaint analysis” framework. It takes the form of three sets of questions that I ask myself with each new error:

• What is the user really trying to do in their context? Why is this a problem for them specifically?
• Where is the difference in perception of the problem between what we see and what they see?
• Is there a surprise element?

These questions help analyze user errors. While it is tempting to rely solely on user support to provide us with the answers to these questions, harder problems will benefit from having an engineer reach out directly to the user, by text or ideally by video chat.

At Apricity, where I was CTO, we had tons of people complaining that they could not access their newly created accounts. After dismissing them as user errors, we started to really look into them using the client complaint analysis framework. We realized that:

• the initial emails at account creation were too unclear. We clarified them.
• at the time of account creation, the “password strength” component would fail in corporate environments that deactivate javascript. We made a special page that showed when javascript was not enabled and kindly asked users to try again at home.
• users using Gmail would have our emails - both initial and reset password - shown in the promotion tab. We iterated on the emails with the gmass service but we could not reach a good trade-off, so we explicitly invited users to check their promotions tab.

We made these changes and kept this knowledge as part of our internal training plan. Since Apricity is a healthcare company, we had to maintain a security trade-off with the OWASP standards as some users may be malicious. In the end, we barely had any problems reported regarding account creation and we were able to keep up with the user growth.

How are user errors considered in your company? Do they turn into PEBCAK jokes or do you use them as a means to improve user autonomy?