Jonathan Price
President, The Communication Circle, LLC
http://www.theprices.com

On the Web, people prefer a conversation to a lecture. And traditional Help, even when it is mounted on a Web site, energized with Dynamic HTML and JavaScript, linked to embedded customer assistance, and delivered as active server pages—well even then, Help seems like a lecture. But a set of Frequently Asked Questions, even when done poorly, seems like a conversation.

When I started writing for the Web, I hated FAQs because the authors ignored so much that technical writers had learned in many years of developing manuals, Help systems, and, most exciting, CD-ROMs. The FAQs did everything wrong, but they got attention. People demanded FAQs. How come?

Think of the origin. FAQs were invented by the moderators of those all-text discussion lists that sprang up back when the Internet had not even imagined a World Wide Web. The moderators got angry at having to answer the same question over and over. So to avoid having to keep sending out individual emails over and over, the moderators invented the list of Frequently Asked Questions with answers.

This laborsaving device, the FAQ, appealed to participants because here was the head of the whole list talking to them, answering their questions. In effect, an FAQ offers a freeze-dried conversation.

Now on the Web, people see that despite the coldness of the computer, the stupidity of the software, and the slowness of their connections, hey, some human contact is possible. New people, new points of view, new rants. People do not just want information on the Web; they want a sense that they are talking to another human being. The FAQ gives them that feeling.

Instead of fighting the convention of the FAQ, I think we ought to give in to the popular demand for this odd, democratic, and chatty genre and adopt the FAQ. Then, I suggest we also bring along some of the tactics we have developed in technical communication to improve the FAQ.

Write the questions in the persona of the guest

As we have seen when writing troubleshooting sections, people have a hard time recognizing their own problem in our prose. So we have switched from phrases like “Connection Failure” to “I Can’t Seem to Connect to the Internet.” Take that “I” one step farther and turn the problem statement into a question. “How Can I Connect to the Internet?”

Change the perspective to increase the illusion of a conversation. Too many questions are self-centered, reflecting the marketing department’s desire to communicate the latest features. “What is Splendorama?” Not a question that many of us would ask. We must rethink existing questions to reflect what users might really be asking in their own terms.

Include more sections of troubleshooting

Many FAQs shy away from problems, perhaps because the marketing department has written so much of the current content. But we know how many snafus people can get into even with well-designed software. So let’s take the top fifty calls to customer service and turn them into a set of FAQs. The question states the problem, and the answer comes in two parts: a diagnosis and, hopefully, some kind of solution.

For problems that are too complex to diagnose off the top of your head, put together a branching diagnostic, like the ones for a printer, where you lead people through a series of questions so that you can eventually pin down the diagnosis. In this way, you are imitating the technique of personalization, where a site asks a whole series of questions then unfolds the perfect product or the right content for that individual.

When visitors see a concrete payoff ahead, they continue to answer the questions even when they thought, at first, that they would get a simple answer.

Write procedures

In most FAQs, instructions have been blended, higgledy-piggledy, with marketing fluff, half-explained concepts, random explanations, and, oh, another spate of instructions—all in one answer. We know from usability research that this approach does not work very well for most people. So edit the heck out of existing FAQs to make them work better.

If you are telling people how to do a task, pull the procedure out of the paragraph. Give real numbered steps. Separate explanations from instructions. Do what the best technical communicators do in manuals and Help.

Show me the picture

Back when we created manuals, we used to include screenshots to show where to carry out the next instruction or to confirm progress. “Yes, you have configured your system correctly!” But when we developed online help, pictures got dropped on the cutting room floor. And, oddly, most FAQs follow that tendency. In a recent survey of FAQs, we found that less than 5% offered any graphics.

But outside of the FAQ, the site is probably jammed with photos, diagrams, and animations. You might, then, consider adding a diagram here and there, a partial screenshot showing the tools to use, a screenshot showing the result of a complicated operation. Of course if you include visuals, you extend the convention of the FAQ, which started out in an all-text, low-bandwidth, exchange of emails.

Find out if you have answered the question

At the end of every answer, include a real request for feedback. Whoever writes the FAQ should be willing to get the email.

Continue the conversation. Ask your visitor, “Has this answered your question? If not, please try the Search or email me.” Notice the me?

Conversations take place between people, so your persona ought to be that of a person, not a corporation. And just allowing other folks to send you email increases their trust and satisfaction.

We use cookies to monitor the traffic on this web site in order to provide the best experience possible. By continuing to use this site you are consenting to this practice. | Close