Why does help still kind of suck even after so many years?
Tom Johnson asks this poignant question in his post Do We Need a New Approach to Help? Why Are Users So Apathetic Towards Help after 50 Years of Innovation?
Tom provides a great survey of the trends and ideas in help design, starting with John Carroll’s seminal work on minimalism and suggests multiple possible ways forward.
I think there is enormous promise in many of the paths Tom invites us to explore, but at the same time, I am struck by the need to recognize that there is limit to how much help help can be, and a real danger in trying to do too much.
One of the lessons that Carroll stresses in The Nurnberg Funnel, and which is all too easy to forget, is that there is a hard limit to how much any form of instruction can help people learn. Learning is, essentially, resolving a mismatch between the mental model you have and the thing you are trying to learn. In a sense, the process of learning is a series of challenges to the real world to prove itself different from our current mental model. Thus, as Carroll emphasises, making errors is an essential part of learning.
You can’t document a way around this process of challenge, error, and response. As Carroll puts it: “[learners] are too busy learning to make much use of the instruction. This is the paradox of sense making”.
Errors are a result of the learner’s challenge to the real world. In this sense, they are neither fruitless nor a waste. An error is information. This accords well with information theory, which tells us the the best experiment is one that has a 50/50 chance of success or failure, because the result of such an experiment yields the most information by cutting the list of possibilities neatly in half. In a very real sense, therefore, making errors is learning.
There is thus a hard limit to how successful help can be. If it stopped users from making errors, it would stop them from learning. Thus minimalism’s emphasis on encouraging users to act and helping them to recover from errors when they inevitably make them.
In this sense, the ideal way to improve the learning experience would be to ensure that all the reader’s experiments had a 50/50 chance of success, though it is difficult to know if that could be achieved in a way that applied to all users, or how you would measure it.
Also, of course, the ideal help experience should excel at helping users recognize and recover from errors when they make them.
Whether we have reached the limit of help quality is to be doubted. Part of the problem is that it is very difficult to know when you are at the limit. Part of the problem is that when you have reached that limit, learning will remain for the user a frustrating and error-prone process, which makes it very difficult to say that you have done all you can for them and walk away. But the worst part of the problem is that when you attempt to push beyond that limit, you inevitably end up making the help worse, not better.
We need to recognize something important about how we generally try to improve help: We see that users are making errors. We regard that as a failure of help (though it is really a necessary part of learning). We look for ways to reduce those errors, and inevitably what we do is create more systematic instruction — which does not work because it does not match the learner’s mental model.
Minimalism says let them make mistakes, and help them up when they fall. That is a hard discipline to follow. Our instinct is to try to prevent them from falling. But like a child that eventually rebels against parental restraint, saying, firmly, “I can do it myself,” the learner simply ignores those instructions and goes about sense-making in the only way that really works for them. There is no real learning without scraped knees and bloody noses.
So, let’s not ignore the possibility that the reason help still sucks is that our efforts to make it better are actually making it worse.
But let’s also not forget that all this applies to learners, not experts. Learners don’t follow procedures because they don’t fit their mental models. But our audience is not just learners. It is also experience people, who need to look up specifics of certain tasks or values of certain parameters. Because they are experienced, their mental model is a good match for the product and the task, and so they can follow procedures.
We can’t stop writing the documentation that experienced people need, and we also can’t stop inexperienced people from consulting it as well.
Some blundering around is therefore inevitable. And when users blunder, product management will inevitably come knocking on tech comm’s door demanding that we do something to fix it. That, in the end, may be why it is so hard to maintain minimalism in general, and good help in particular. Good help lets the user fail, but good luck explaining that to product management.
Worse still, as Carroll also noted, the user’s idea of what they want in a help system is not the same things as what actually works well for them. Users a quite deluded about how they learn — or perhaps unwilling to admit to is — so they ask for systematic instructions, and declare their intention to use them, but in practice they don’t. They quickly abandon them and start hacking at the user interface. If you are asking for customer feedback on your docs, and acting on it, chances are you are making your help worse by making it match customer expectations rather than supporting how customers actually learn.
What, therefore, must we do? Maintaining an ideal minimalist help system can be very challenging indeed, both because it is hard to measure, and because it is hard to defend, even to the people who benefit from it. What we can do is to create content in a way that recognizes that readers forage through the content set stringing together their own ad hoc curriculum as they go. We can facilitate this by taking an Every Page is Page One approach to our documentation:
- Create Every Page is Page One topics that are self contained and serve a specific and limited purpose.
- Establish your context clearly in every topic.
- Conform your topics to a well defined type so they are consistent, complete, and easy to navigate.
- Assume the reader is qualified to read this topic, and provide links to background for readers who are not.
- Keep each topic on one level and provide links for users to change levels as and when it suits them.
- Link richly along all significant lines of subject affinity so that readers can easily go wherever their mental model and their challenge to reality leads them.