One of the reasons why I think a lot of application users don’t read the documentation is … well let’s be honest … it’s boring. Typical documentation takes you through menu option after menu option explaining in excruciating detail what each parameter means and when you should use it. We kid about using the documentation being a great way to break through insomnia and get some sleep, but who are we really kidding. Most documentation is drier than the Sahara desert in the mid afternoon sun.
So how do you get people to read documentation about a new application rather than just trying to dive into it and ‘experiment’ with the features? One thing I am trying is a different style of documentation, one that I call FAT documentation. First, this has nothing to do with your weight or what you ate last night while you were watching the game on TV from the sofa. Rather FAT stands for Frequently Asked Tasks.
As you might guess, FAT is a variation on FAQ (Frequently Asked Questions) but applied to application documentation. After all, what is the point of documentation other than to help new users learn how to do different tasks using the tool? So rather than letting it up to the user to take the initiative to pick up the documentation manual, wade through all of the menu option descriptions and then try to figure out which options apply to the task they are really trying to do, why not make it simple? Why not help them find just the information they need for just the task they are trying to do?
To create FAT documentation, I begin with application specifications. In other words, what is the application really supposed to do. This helps me determine the broad categories of questions that I may want to include in the FAT documentation. I might begin with questions such as:
- What is the main purpose of the application?
- Are their different levels of users in the system and what makes those levels different?
- How do users enter data? Are there certain things that must be entered first?
- If there are look-up tables, how do users maintain them?
- Can users configure any of the screens to sort or filter what they see?
- Can users generate reports or download subsets of the data?
- If a user makes a mistake while entering data, can they go back and fix it?
Based on these types of questions, I define overall categories of questions. Then I begin going through the application. During testing I usually ‘discover’ the detailed questions that I want to include. Why during testing? Well, good testing includes two styles, white box and black box testing. It also includes testing with known good data that should produce known good results and testing with known bad data that should produce user-friendly errors or should be caught through validation routines. In any case, testing is all about asking what the user might do at any point in the application. This type of questioning is obviously closely related to questioning what should the user be doing at any point in the application, how should they do it, and perhaps even why they should do it. As a result, these questions can often be rephrased as user tasks, and thus: Frequently Asked Tasks.
Publishing these task related questions now reads more like an action plan rather than dull documentation. If a user is unsure on how to perform a specific task, they can skim through a table of contents at the start of the documentation divided into groups and identify which questions pertain to the task they are trying to do. Once they identify one or more tasks that seem to relate to their need, they can just read the corresponding frequently asked tasks to hopefully learn how to perform that task.
Perhaps the next time you need to create documentation for a new application at your organization, you might consider trying FAT documentation to see if that more easily meets the needs of your staff. Let me know how it goes.