There’s an old expression that to assume makes an ass out of u and me. (The phrasing works even better in the text era). I admit that many of my mistakes come from not checking my own assumptions. Is that what they really want? Is he postponing this week’s meeting, or next week’s? So my experience teaches me to question assumptions.
But it occurs to me that the expression is useful the other way, too. Turn the expression around and you get “assume questions.” Does this mean anything? I think it does, at least for technical communicators and instructional designers. In particular, I can think of three areas where this is useful:
- Preparing formal arguments and counterarguments
- Preparing for debate or legal proceedings
- Anticipating questions and objections and preparing in advance to deal with them
Concentrating on technical communication activities, the most obvious place to assume questions is in the frequently asked questions document, or FAQ. Now, I’m not a big fan of the FAQ. It should be assembled organically from sources of questions, such as customer support or training, but too often it’s used instead as a vehicle for “questions we want to be asked and answered” rather than questions users actually frequently ask. Often the FAQ format is an excuse for not organizing material. But done well, a FAQ answers genuine questions and addresses known points of confusion
(By the way, it should be the goal of the development organization to design away FAQs, through either improved design and error correction, or improved documentation that addresses such questions in advance.)
Another place to assume questions is in procedures. It’s common enough to document a straightforward march through a procedure—select this, enter that, click here, click there, and you’re done—and frankly, a travelogue isn’t particularly valuable. But what happens if there’s an error? How does the user know where to start and what the end point is? When they click OK, what happens? Nothing? A spinning icon? Five minutes of chugging away? That sort of information is truly valuable.
The easiest way to get into a user’s mindset is to try the procedure for yourself. Follow your own procedures and you’ll immediately catch some of the pitfalls. I admit I don’t do this enough in my own writing, but when I buy a consumer-electronics product), I can feel myself dropping into user mode, and my own questions leap out at me. If you’re too close to the product to get into user mode, the next-best thing is to apply the journalist’s six golden questions: who? what? when? where? why? how? They work for us too. In the classical IBM methodology, procedures must say who, when, where, and how to perform a procedure, using starting points, steps, and end points. That leaves “what” (what do users need to know to do the procedure?) and “why” (why do they need, or want, to do the procedure?). Those are, of course, prerequisites and conceptual background. The questions you can anticipate and answer represent a source of tips.
Where and how might users fail? If you have access to a support group, this is something they can tell you. Troubleshooting information can greatly strengthen and improve the usefulness of procedures, not to mention potentially reducing support call volume (so unless they’re a profit center, the support group should be happy to work with you). What do I enter here (not just “50 alphanumeric characters” but a concrete example)? What are my choices (not just how do I make a choice)? Why would I pick one choice over another (choose A for the highest throughput, or B if there are many local Wi-Fi signals)?
Let me give you an example from my subject domain. Imagine you’re writing a procedure to use a management tool to select subscriber records from the subscriber database. Why would someone want to do this? Because the subscriber session might not have been removed, or the subscriber might be calling with a problem. Okay, how do you do it? There’s a browser-based GUI page, and on it there’s an option to display all subscribers or search for a subscriber by phone number, which is how the subscriber database is indexed. Why would you want to search instead of just listing every subscriber? Because in the real world there may be millions of subscribers, and just listing them would overwhelm the system. (So it might be a good idea to document the search path first.) What’s the next step? The user is retrieving the subscriber record for some purpose; what are the operations that can be performed on the record? Finally, what sort of example would be useful? Perhaps a display of a retrieved subscriber record showing a problem of the sort actually encountered in the field. That’s useful information, whereas showing the search page with a fake phone number entered in the search field isn’t (that’s how to use the interface, not the function).
So, as I said, I endorse the idea of questioning assumptions, and I also suggest that you try to assume questions. It might make an ass out of you and me, but maybe not!
Steven Jong 