Mooer's Law and Findability

by Tom Johnson on May 9, 2011
categories: findability • technical-writing

I was recently reading about Mooer's law in Peter Morville's Ambient Findability. Morville contrasts Moore's law with Mooer's law. Moore's law (much more familiar) asserts that the number of computer transistors that you can fit on an integrated circuit doubles every two years. We're all familiar with the ever-increasing amount of storage space, processing power, memory, and other rapid advance with technology. But Mooer's law is perhaps both more interesting and relevant to technical writers and findability. In 1959, Calvin Mooer, a computer scientist, observed the following:

An information retrieval system will tend not to be used whenever it is more painful and troublesome for a customer to have information than for him not to have it.

Mooer expands on this idea in another article. He explains,

In the building and planning of our information handling and retrieving systems, we have tended to believe implicitly, and to assume throughout our writings, that having information easily available was always a good thing, and that all people with access to an information system would want to use the system to get the information. It is now my suggestion that many people may not want information, and they will avoid using a system precisely because it gives them information.

Having information is painful and troublesome. We all have experienced this. If you have information, you must first read it, which is not always easy. You must then try to understand it. To do this, you may have to think about it. The information may require that you make decisions about it or other information. The decisions require may require actions in the way of a troublesome program of work, or trips, or painful interviews. Understanding information may show that your work was wrong, or that your boss was wrong, or may show that your work was needless. Having informtation, you must be careful not to lose it. If nothing else, information piles up on your desk--unread. It is a nuisance to have it come to you. It is uncomfortable to have to do anything about it. Finally, if you do try to use the information properly, you may be accused of puttering instead of working. Then in the end, the incorporation of the information into the work you do often may not be noticed or appreciated. Work saved is seldom recognized. Work done--even in duplicate--is well paid and rewarded.

Thus not having and not using information can often lead to less trouble and pain than having and using it.

In other words, people usually take the path of least resistance. It's easier to continue doing things the same way, as you've always done them, without reaching out to learn some new process or information that might invalidate, challenge, and force you to reassess your previous assumptions. Information can be threatening and hard to deal with. It can be thick to interpret, exhausting to follow, and painful in the realizations it provides. That's why it's easier to just watch TV instead of read a book. It's easier to ignore the help file rather than slog through new chapters reading new techniques, strategies, and recommendations. It's easier just to keep doing things the same way -- the way that seems to work well enough.

Thus, no matter how findable your information is, people will avoid it because new information stretches you. And nobody likes to be stretched.

In general, people resist reading an application's help file for all these reasons -- it's tedious, sometimes hard to understand, requires interpretation, effort to locate, etc. It's seems so much easier to hack your way through an application with trial and error and guessing.

Apart from purposely building a bad user interface that requires users to consult the help (not a good practice, except for ensuring technical writer job security), how do we account for Mooer's law? Do we accept that users will click and select their way half-blind through an application rather than take the time to read a manual about it simply because it seems easier not to read it?

No, I think the answer is fairly straightforward. We have to remove the strain of absorbing help material. Here are a few ideas for removing that strain:

• Make the topic easy to find. Nothing is more strenuous than spending an hour trying to find the topic you need. If possible, bring the information directly into the interface. Or implement more entry points into the help based on different user interests.
• Make the information more visual. Long blocks of text, like this blog post, are not easy to read. In help material, you can simplify the content by making it more visual. Add a screenshot if a button is hard to find. Create an illustration if a concept is difficult to understand. Record a screencast if the process is a complicated. When writing text, make it visual through lists, captions, notes, and formatting.
• Keep it short. Here is yet another paradox, because concision doesn't always mean clarity. In fact, the more concise you are, the more obscure the content can become. So keep this principle reasonable, but remember that long texts intimidate readers. Give them a quick reference guide to start with rather than a 300 page manual, for example.

Overall, keep in mind that lack of hits on your help topics does not mean your help sucks or that the user interface is intuitive. Help systems in general, from your computer to your alarm clock to the swing set you're trying to put together, have a lot of bad baggage and history that you can't expect a reader to overcome in one night.