The Five W’s of Online Help for Tech Writers


The problem also has its roots in a growing comfort and complacency among writers; we understand reference and task-based information well enough that when we produce online help files, we create such material by reflex, without spending much time thinking about what we’re doing. When we write by reflex, following a well-established pattern, we accept and internalize the notions that we must pick which type of information (e.g., reference material versus task descriptions) to provide, and that these two types of information are sufficient for most users of our online help systems. In fact, we need to think beyond this stereotype and consider a broader range of user needs.


Each of the five W’s is a simple question that starts with the letter W: Why, Who, What, Where, and When. Some authorities add a sixth question, “How,” to this list, but “how to” information generally fits under what, where, or when, depending on the nature of the information. Users of online help can benefit greatly from the proven journalistic approach if we can answer these same five questions for each help topic that we create. In the remainder of this article, I’ll provide an example of a failure to ask these questions, show how asking these five questions could have prevented this failure, and provide examples of typical questions we should be asking. Please note that, although I’ve presented these five questions in an order that seems logical to me, in practice the approach becomes iterative: It doesn’t much matter where you begin, since answering one question often reveals important aspects of the other questions that you’d not yet considered.

The Problem

Consider a fairly simple task that appears complicated if you haven’t done it before: Creating a reply form in a Microsoft Word 97 document that contains selectable checkboxes; with these checkboxes, people can fill in the form using Word and return it to you. If you open Word’s help file, navigate to the index, and select “checkboxes, inserting,” you’ll see the dialog box in Figure 1. (Assuming, of course, that you click on the “checkboxes” part of this index entry; if you click on the “inserting” part instead, you’ll find to your dismay that the online help system displays information on “form elements you can use on a Web page,” which has nothing to do with the desired task, and that provides no cross-references to that task.)

Figure 1: Help text for inserting checkboxes.

The help topic has several obvious and less obvious problems:

  • It provides information on other items on a form (dropdown lists and text fields) that have nothing to do with checkboxes, thereby forcing readers to scan through irrelevant information to find the relevant parts. No chunking of the text was done to help readers find the relevant information.
  • It does not define how these three items differ, forcing the reader to guess why the two irrelevant entries appear in this topic and how they might affect the choice to use checkboxes.
  • There is no procedural information to help readers actually insert a checkbox. For example, how do we display the Forms toolbar, decide which icon to click to insert a checkbox, and use the “Form field options” button (if one can identify its icon) so we can edit a field’s properties? Do we specify the text that describes the checkbox’s function by editing the field properties, or type this text directly in Word? How do we control the position of the checkbox? And so on.
  • Figure 2: The "Form field options" help topic accessed using the help system's "find" feature.

    There are no cross-references to take readers to important related topics, such as descriptions of the icons on the Forms toolbar. Moreover, the boldfaced terms misleadingly appear to be hyperlinks to such information; they are not, and boldfacing has been used only to facilitate skimming. Worst of all, searching the index under the words “form fields” only reveals the help topic in Figure 1. Using the search function takes you to the desired help topic, but doesn’t explain any of the options, and because all the search terms are highlighted, it makes the topic resemble a ransom note (Figure 2).

  • There is no explanation of why ActiveX controls are recommended, and under what circumstances Word’s own checkboxes would be inadequate.

The Five W’s Solution

Consider how asking a series of questions based on the Five W’s approach could have helped the authors of this help topic to focus on the needs of real users of the product:

  • Who will use this help topic? The vast majority of Word users have no knowledge of ActiveX controls, and will never need to use these software widgets. This tells us that information on ActiveX should appear purely as a footnote to the main information.
  • Why would someone want to insert a checkbox? Typically, the aforementioned user wants to circulate a Word document to their colleagues to obtain feedback on their preferences. By clicking in the checkbox beside an option, colleagues can express their preferences and return the updated document to its creator. That’s the main task we must describe in our documentation.
  • When would they insert the checkbox? Checkboxes differ from other types of “controls” in that you can check (select) every checkbox on a page; where the goal is to force users to select only one of a series of options, you should instead use radio buttons or dropdown lists. We should explain this so readers know that they’ve chosen the right option.
  • What does the reader need to do to insert a checkbox? (They must display the Forms toolbar, then work through the process of inserting and modifying a checkbox.) What other options are available? (ActiveX, for one.) This forms the core of the procedural information we must write.
  • Where do you find the Forms toolbar, not to mention the various icons on that toolbar that we require to insert and customize the checkbox? This tells us we should provide screenshots of the toolbar or its icons. Although one could argue that tooltips (those little popups that explain an icon if you hold the cursor above it) serve this role, readers will find icons more easily if they’re integrated with the explanations.

Fig. 3

Asking these questions tells us clearly who will use Word’s built-in checkboxes, why they’d want to do so, what the alternatives are, and how to actually do the job. The revised online help topic based on these questions might resemble the one in Figure 3.



Inserting Selectable Checkboxes Checkboxes let readers of a Word document select one or more items from a list of possible options.To insert a checkbox:

  2. To display the Forms toolbar, select “Forms.”
  3. To insert a checkbox, place the cursor at the desired position in the Word document, then click the Checkbox icon on the Forms toolbar.


Related topics:


  • Choosing only a single alternative using:
    • Radio buttons when you have room to present all alternatives on the same screen
    • Dropdown lists when there’s insufficient space to present multiple radio buttons

Creating checkboxes for forms that will be used on the Web

  • Using ActiveX controls to link checkboxes with databases

This solution to the problem represents a first draft that can still be improved, but one that at least solves the problems mentioned earlier in this section. Recognizing that most people who access this topic want to insert a checkbox to let their colleagues select one or more options, we’ve created a topic that focuses primarily on that task, and moved information unrelated to that task (e.g., ActiveX) to the end of the topic, as a cross-reference. Recognizing that there are several selection options available to the user (checkboxes, radio buttons, and dropdown lists), we’ve begun the topic with an explanation that tells readers whether they have selected the correct option; if not, we’ve provided cross-references to related topics that may more closely meet their needs. Finally, we’ve concluded the topic by providing all the procedural information required to insert and customize a checkbox. In short, asking only five questions lets us identify the readers’ needs well enough to produce a considerably more complete online help topic than the one in Figure 2.

Get the Most from the Five W’s for Online Help

As I demonstrated in the previous section, asking questions based on the five W’s can help you focus a help topic on the reader’s needs far better than if you just describe what readers will see on the screen. Of course, to do so you’ll need to know what types of questions to ask. In this section, I’ve provided examples of how you could think about the user’s task and a list of typical questions you could ask. The list of questions is by no means comprehensive, so use it primarily to start you thinking about how to use this approach, and extend the list of questions based on the unique needs of your audience.



Consider, for example, the task of documenting an “Undo” feature. Although some readers will use this feature to let them test the results of an action without worrying about permanent damage to their work (because they can undo any unfortunate consequences immediately), others will use the feature to recover from accidents. Both types of user must understand the limitations of the Undo feature and what to do when they encounter these limitations; thus, it’s our job to understand why they might want to use the feature and what this reason says about their mental state. The need to undo an action often leaves users fearful, confused, and perhaps even angry, and that’s how they’ll be feeling when they consult our help file. In response, we must try to reassure them and to provide alternatives if undo doesn’t work. For example, “Undo” won’t work for file deletions in most software or operating systems, forcing users to rely on alternatives such as an Undelete utility or a trip to the Windows recycle bin or Macintosh trashcan. If an action can’t be easily undone, we must ask the product’s developers to at least provide a warning: “This action cannot be undone. Are you sure you want to proceed?”


Consider asking the following “why” questions for your online help topics:

  • Why would someone use this feature?
  • Why would they use a different feature?
  • Why might this feature fail to work?


“Why” often tells us something about who. When you understand why someone might want to do something, you can often figure out who would and would not want to do that something. In effect, the answers to each “why” may identify one or more groups within your audience based on whether they have the desire, knowledge, or skill to perform a specific action. Knowing this information, you can design your information to

  • let different classes of users find detailed or summary information quickly;
  • supply the knowledge readers require to prepare themselves for performing the action; and
  • provide a means of obtaining the skill required to perform the action.


Consider asking the following “who” questions:

  • Who will use the product or function?
  • Who can help them perform tasks they can’t perform themselves?
  • Who else will be affected when they use a function or perform a task?


“Who” tells us about the possible things each group within our audience will try to do with the software and the information we should provide about those things. “What” questions are familiar to us because they often relate directly to procedural and reference information: “What must I do, in what order, and what are my options?” The most common failing in creating these types of information is that they don’t answer questions based on the other four W’s, and in particular, don’t answer less common questions that may be unique to each audience or product. For example, if we’re documenting software for maintaining patient medical records, we might need to ask questions such as “what are the ethical consequences of providing access to this information?” and “what steps should we take to safeguard the patient’s privacy?”

Consider asking the following “what” questions:

  • What features are available?
  • What can we do with a given feature?
  • What can we not do with a given feature?
  • What are the prerequisites for a feature, both in terms of knowledge and in terms of the steps that must be taken before using the feature?
  • What are the consequences of using a given feature?




“Where” also addresses non-physical context, such as defining situations where (“contexts in which”) a tool is applicable and conversely, given a specific context, what factors limit the use of that tool. Jef Raskin’s book The Humane Interface provides substantial information about interface problems, and challenges us to think in several very unconventional ways. Raskin points out that most modern software is strongly modal, which means that how a tool reacts and whether it’s available in the first place depend on which mode the user is currently in. For example, PageMaker’s extensive text-editing tools are unavailable in layout mode until the user selects the text tool. Understanding how the software’s use of modes supports or conflicts with the user’s approach to doing real work tells you much about how to present the information.

Consider asking the following “where” questions:

  • Where will the product be used, and what are the consequences of that location?
  • Where do users find the menus, keystrokes, or toolbars to activate a feature?
  • Where is the product not applicable, and what can users do in that situation?
  • Where does the context limit the use of a feature?




Performing some necessary actions may leave the software or system in a state that requires intervention by the user. For example, setting up “always on” cable or DSL connections, in which the Internet connection generally remain active rather than disconnecting, leaves the connection to the Internet open and thus vulnerable to crackers seeking to gain entry into an unguarded computer. The online help that explains how to keep the connection active should also explain the consequences of this choice. Recommending the installation of firewall software might address this need adequately for those who wish to remain connected.

Consider asking the following “when” questions:

  • When does this step take place? (Where does the step fall in a larger sequence of steps?)
  • When will the user be ready to do the step? (What are the prerequisites?)
  • When will users have the necessary knowledge to complete a step? (What must we teach them before they can proceed?)
  • When users have completed a task, is there any cleanup or followup required?




Last, but not least, learning to apply any approach by habit carries its own risks. There’s an old maxim that if all you own is a hammer, all problems begin to resemble nails. As is true for any tool, the Five W’s approach should not be used blindly. The approach can certainly guide and inform how you identify and solve a communications problem, but it must support rather than replace the process of understanding the needs of your readers and figuring out how to meet those needs.


Hart, G.J. 1996. “The five W’s: An old tool for the new task of audience analysis.” Technical Communication, 43(2):139-145.

  • Hart, G.J. 2000. “The style guide is dead: Long live the dynamic style guide!” Intercom, March:12-17.
  • Hart, G.J. 2001. “‘Backing up’ doesn’t mean retreating,” The Official TECHWR-L.
  • Raskin, J. 2000. The Humane Interface: New Directions for Designing Interactive Systems. Addison-Wesley, New York, N.Y. 233 p.
  • Ray, D.S.; Ray, E.J. 2001. “Embedded Help: Background and Applications for Technical Communicators.” Technical Communication, 48(1):105-115.




Steven Seiller

9 years ago

Nice work! I agree, most help content does not explain the background of why the issue is a problem or why the subsequent procedure is recommended. Let’s hope help writers read this and get “why!”

Subscribe to TechWhirl via Email