When users complain that digital products are confusing, development organizations often bolster training programs and help systems. In doing so, they mistakenly seek to fix users rather than fixing interfaces. This approach avoids the real problem of poor usability.

Fixing the User

The Sisyphus of myth is eternally doomed to roll a large boulder up a hill only to see it roll back down every time. One imagines him monumentally frustrated. Every time he pushes it to the top of the hill, it defiantly rolls back down. The cycle repeats forever.

In extreme exasperation, he breaks down and angrily yells, “What the %&$@# is wrong with you? Why won’t you stay at the top of the hill? Mercury’s wings! This is maddening! You are a flawed stone!”

Poor Sisyphus is losing it. He’s displaced his aggression onto an innocent object. He is livid with the boulder when really he should be angry with Zeus, who consigned him to his eternal fate. Better, he should be upset with himself. His antics and trickery got him in trouble with the gods in the first place.

We often react like Sisyphus.

When users find our digital products confusing, we decide the problem lies with the users themselves. They must be somehow flawed. Why else do they struggle with software, apps, or sites that are so obviously easy to use? Essentially, we blame them for interface problems. But because we are enlightened, merciful, and eminently understanding, we train them. We offer them help.

Instead of a greater focus on interface usability, development organizations rely heavily on instruction and explanation. They teach people the proper way to use a system. On the surface, this approach feels obvious. Explaining software, managers claim, is cheaper than fixing it. But over time, underlying issues go unsolved. Interfaces remain confusing and infuriating, even to the people who have been taught to use them.

Neither the boulder nor the users have done anything wrong. Yet here’s what development teams and firms do:

1. Lean excessively on training.

Walk the halls of development, and you may hear statements like this:

• “This interaction is not ideal, but we’ll deal with it in training.”
• “That’s a training issue.”
• “We’ll teach users how to do that right.”

Organizations that rely on software products rely heavily on training. They boast an array of classes, programs, videos, and “onboarding” options. The more mission-critical the software, the more elaborate the instructions. Even simple apps are created with the assumption that users will be taught proper behavior. This is a standard arrangement. Training will occur. It’s how things are done: death, taxes, training.

Why It Fails

Training is not a cure-all.

Organizations act as if training is an expansive answer to all software ills. The trainer is the doctor, and the user is the patient who must be fixed. Beyond being flagrantly insulting to users, this deflects culpability for poor interfaces away from the development team, blaming the user instead. It’s the user who can’t figure things out. They are not as intelligent as those who built the product.

This perspective also leads to complacency. If the user just can’t get it, why should one focus on making products better? Cutting corners is far easier when trainers make it right later. If training solves all problems, why bother making excellent, usable software in the first place? Why try harder? Welcome back to our vicious Sisyphean circle.

Training is limited by subject matter.

The best trainers may not train textbook use of the system. More likely, they identify hyper-efficient workarounds, tricks and short-cuts that circumvent correct use. Workarounds are a tacit admission that an application is flatly difficult to use. Trainers know this. They spend significant time with users and hear the litany of complaints. They openly criticize the user-friendliness of interfaces, perhaps to avoid the embarrassment of association.

Let’s remember, users feel helpless in the face of confusing software. Patient, clear training rescues them. Trainers are loved. It’s not a trainer’s fault if most interactive systems are terribly difficult to use. No amount of stellar instruction can make a bad digital product into a good one. Training is decidedly not the problem. Reliance on training is. When we presume teaching makes up for poor usability, we offer resigned acceptance of poor, underperforming interfaces.

2. Create robust help.

Everyone makes mistakes. We fail to grasp the simplest software. Even power users encounter problems. This is normal. When we get stuck, we need targeted, concise guidance, and we need it fast. For this reason, nearly all apps, web sites, and software provide some form of “help.” It is a non-controversial best practice. But where to start? What kind of help? A dizzying array of options and techniques exist, including:

• Help Sections, Menu Options, or Help Desk (online and offline)
• Contextual Help, Inline Help, or Tool Tips
• In-Person, Real-Time Assistance (really)
• User Manuals, Style Guides, or Knowledge Bases (online and offline)
• Wiki, Chat, or Bots (oh my!)

From this list, a future information archeologist might deduce the information age was either chock-full of mystifying products or inordinately dense people. Based on the sheer volume of choices, they’d at least infer help must have been extremely important.

Why It Fails

Help is hardly ever helpful.

Help, conventional wisdom tells us, exists to explain interfaces. Organizations embrace this virtue, creating voluminous help content. Users routinely encounter copious explanation: paragraphs of tool-tip text, endless F.A.Q. pages, blisteringly expansive help sections, and biblically long introductory copy. Development teams act as if content alone equals comprehension. They assume people devour user manuals in full, and everyone loves reading online. If some is good, more is better.

But when is the last time you found help, well, helpful?

People seek help as a last resort, when nothing else works. But what if the glorious help content (if or when found) is just as confusing as the interface? Rules for appropriate content and baseline usability don’t stop at the entrance to the help section. People react poorly to jargon-heavy copy, assumed knowledge, poor typography, and annoying interactions wherever they are found.

Sadly, most help features would not pass a standard usability audit. Just because help exists doesn’t make it inherently useful or remotely effective. When we add help for its own sake, we are merely painting by the numbers. Ostensibly understanding and courteous, we are merely making another lazy assumption. 

Maybe it doesn’t matter. Maybe people just aren’t very smart. They’d be lost even if our help were perfect. Perhaps so. But this again deflects attention from the real problem. What is more likely: all people are dullards, or most software is bewilderingly complicated and most help content just as needlessly confounding?

Training and Help Mask the Real Problem

As end-user frustration increases, organizations must do something. Increased attention on training and help are logical, positive responses. Training and helping users isn’t wrong, but relying on either instead of fixing interfaces can be disastrous.

Misplaced Trust

How can self-evident best practices go astray? How can teaching enable poor interfaces? The danger comes from confirmation bias. When we want something to be true, we believe it to be true. Our pre-conceived notions affect our opinions. We believe training and help must be beneficial. Why? Because we know help is helpful. We know training works.

What if this isn’t true? If help and training made interactive experiences intrinsically wonderful, most organizations would have happier, more satisfied users, adoption rates would be off the charts, and customers would never flock to the competition. Something else must be going on.

That something is poor user experience. When we assume the interface cannot be the problem, or is only a minor issue, we blame users instead of ourselves for our products’ shortcomings. When we assume training or help will compensate for bad design, when we refuse to acknowledge and fix deep-rooted usability problems, we are in denial.

Misplaced Blame

Sisyphus is beside himself, absolutely certain the boulder is at fault for his predicament. But just as he cannot blame a boulder for being a boulder, we cannot blame people for being people. No matter how they are helped or trained, people will bristle against confusing, difficult interfaces. Digital products cannot be fixed with expensive help systems or training programs. They must be fixed at their core.

Training isn’t the only afterthought technique development firms use to try to make their products better. We’ll explore another tactic that often comes too little, too late next.

Next Post in This Series
Pretty Colors and Pictures Won’t Make Your Digital Product’s Experience Any Better

Part of the Modern Digital Tragedy Whitepaper

 Download the Full Whitepaper

All Posts in This Series

• The Impossible Standard of Digital Product Perfection
• Stop Relying on Process Change to Fix Poor UX
• Feedback From Customers, Users, and Competitors Can Lead Your Dev Team Astray
• Training and Online Help Can’t Fix Poor Digital Product Design
• Pretty Colors and Pictures Won’t Make Your Digital Product’s Experience Any Better
• Why Development-Centered UI Approaches Fail