Maybe you have heard the saying "we'll take care of that in user training". The notion that problems users have can be resolved by user training is severely flawed. Yet entire departments rally around this belief and worse many companies seem to wrap product management around it.
The idea that you can educate users about how to use a user interface is misguided. The goal of usability is to create intuitive user interfaces. Intuitive means the design does not require understanding. Help and "user education" presupposes that both of these goals are possible.
My personal and professional experience tells me they are not. Maybe I am not typical: I don't read user manuals, I struggle with help systems and I go for defaults over configuring options. In fact those three behaviors are very typical of the "average user".
At Experience Dynamics, I occasionally work with clients who have structured their entire user experience efforts around a User Education Department. This type of department writes documentation and help manuals and systems in order to "clean up" on confusion created by complex software, Web applications and Web sites. The idea is that with a little help, a user can be trained.
As someone who spends a lot of time with end users observing them interact with these same interfaces and help systems created by those same user education departments, I can tell you categorically that the intention does not match the reality. If it's not intuitive, you're in trouble...help or not.
Should you design help systems if they don't help?
Last week in Seattle there was a User Assistance (UA) conference, a regular conference for professionals in this area. Even usability thought leader Jared Spool spoke at the conference...
If 'help doesn't' then what are UA professionals such as those at last week's conference doing wasting their time? What is a company doing wasting time putting a help system in a design?
UA seems to be a 'necessary evil' in interface design. While user "training" can help ease the burden of disorientation, it is ineffective as a method for increasing the important usability metrics of ease of use, ease of learning or ease of understanding.
Don't get me wrong, you still need to build help systems-- just don't rely on them as a mechanism that will realistically save your design. What I object to is not the existence of UA, but rather the reliance on it by developers, designers and product managers as a way to brush away usability requirements. I have been in too many meetings where everyone nods their head to the sound of "that's just a user training issue" or "the user can just hit help or click here for help".
User Error, Lazy and Stupid Users and What to do about Them
While preparing this post, I mentioned to a colleague the premise of this article and he said:
Please tell that to my current project team. Man, they get so angry at the users' "incompetence" and "laziness" because they struggle and don't read the massive bibles of "User Assistance" for our web application...
Stupid and lazy users are often found in the same mental space as user education. I once talked to a manager of users using a system who told me the problem with the users was that they were lazy. There were no usability issues with the application, it was their laziness and stupidity that were to blame. In the next moment she told me that she was having terrible issues with the app's ease of use and that a competitor's application was so much easier to use!
Humans are extremely intelligent but it's a different intelligence than the linear intelligence of a machine. As a result humans will commit errors. Errors are actually inherent in how we learn. You remember "trial and error" right? Or Lean's "fail fast and quickly"?
Since you can't adjust your users but you can your design, how about this for a new belief: "There are no user errors, only designer errors"?
User help as a product management approach?
If your belief about users is that help does, or that a sprinkle of training is the answer, then you probably need to spend more time with your users. Even technical users, business users, scientific expert users, PhD users, and others you would expect to master an interface, show the same pattern as average users in our studies at Experience Dynamics.
Virgin Atlantic Airways took a user assistance approach to the design of their first-generation of their in-flight entertainment system. The last few Virgin flights I took to London last year had that system in them. Tired and ready to view the great British TV content they have on those flights, I experienced their product strategy first hand:
- Virgin forced a repetitive start screen asking if you had read the directions before continuing.
- Console controls were so confusing (simultaneous criss-cross left and right thumb navigation) they often triggered the friendly help video (forced watching).
- The in-flight media guide had a cartoon character proclaiming "the system is EASY TO USE!" explaining why it was easy to use and offering pages of instructions on how to use it.
Needless to say, on every Virgin flight I struggled to figure out how to use the system. Instead of interacting with the content, I was forced to interact with the belief system used to design the experience: That user education and help was the answer to leveraging potential usability issues.
Virgin's redesign of the system, called RED, (pictured top of this page) looks remarkably more pleasant and usable. Designed by Charles Ogilvy, you can see some images of it here. The new system is a complete rework, and it looks like they made user experience the driver and gave user assistance more of a back seat.
Virgin learned a difficult lesson that many designers and developers make: make it intuitive, to begin with, design to accommodate human error, and leave user assistance as the safety net, knowing that it might catch falling users (or more probably it will not).
In summary: User education and assistance is a supplement that users might access in a frenzied state of helplessness, confusion or anger. It rarely helps to save a design that has failed to support a user. Help should be there as an 'FYI' not as a substitute for a non-intuitive design.
Best Wishes,
Frank Spillers, MS