Skip to content

Why Must Users RTFM?

by aaron on September 9th, 2006

Kathy Sierra, co-creator of the O’Reilly Head First book series (including the super-cool Head First Design Patterns book), has a very long, very passionate post on some of the fundamental disconnects product creators have with their documentation.

Kathy nails the fundamental issue right on its head:

[Your average manual] suffers from one huge mother-of-an-assumption: that the user knows exactly what to look up!

…and goes on from there. Kathy’s absolutely right: 99% of the time, I have no idea what the capabilities of a new product are, but I have a pretty good idea of what I want to accomplish. I might not have the slightest clue that Javascript has first-class functions. Even if I did know this, would I understand how this benefits me in a practical way? The best way to teach a lot of this stuff to a user is by presenting them with tasks, or a cookbook of sorts. “I want to…” tends to be a much better way of structuring content for a user than throwing them into the thick of 

public class Foo : Object

Of course, the inductive model does have its limits, and a manual structured in this fashion can never take the place of something like K&R or the Wizard Book, but it certainly has its place.

Possibly Related Posts:


From → Usability

  • Will Pearson

    Should users really have to RTFM? If a user has to RTFM then isn’t that indicative of poor UI design, or at least user centered design where the user profiling is poor?

  • http://tombarta.wordpress.com/ Tom Barta

    If a user has to RTFM it may also simply be an example of a UI with lots of choices in any given space. While this is fundamentally a bad thing for general usability, there are certain interfaces that must be tailored for experts. 3D modeling software, for example, typically has gobs upon gobs of menus, simply because there are gobs upon gobs of techniques available.

    Also, there’s more than one reason to RTFM. In the 3D modeling example, the manual could contain more technical explanations of the operations, so someone can more easily learn the strengths and weaknesses of the various techniques available (e.g. should I use a NURBS patch here, or a Bezier patch, or any number of generalized subdivision surfaces?).

    In most cases, large tools (be they completed software applications or SDKs for developers) tend to work best when they contain both a teaching manual and a reference manual. The teaching manual guides people through more of the philosophy and discovery process, whereas the reference manual is the easiest way for experts to refresh their memory on the gritty details.

    That being said, most developers are terrible at writing teaching manuals because they are already experts, and an author’s discovery process are different from a user’s discovery process (even if that user is another developer). I know the only way I’m capable of writing a useful instruction manual is by (awkwardly) teaching someone in person and then later transcribing that session.

blog comments powered by Disqus