On the Web, most people prefer a conversation to a lecture.

But 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.

On the other hand, 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 labor-saving device, the FAQ, appealed to participants, because here was the head of the whole list talking to them, answering their questions. In effect, a 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 have given in to the popular demand for this odd, democratic, and chatty genre. Adopting the FAQ, then, I suggest we also bring along some of the tactics developed by technical communicators, to improve the FAQ.

Write the questions in the persona of the guest.

People have a hard time recognizing their own problem in our prose. So we must switch  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 go on answering the questions, even when they thought, at first, that they would get a simple answer.

Write procedures.

In most FAQs, the 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 I was busy writing  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. By including visuals, you can 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.

Of course, it would be good to answer the email.

For details on how to write FAQs, see:

Write questions in the persona of the guest

Put instructions in numbered steps

Handle branching with bullets

Go ahead, repeat yourself

Show pictures

Find out if you have answered the question

Keep growing the FAQ

Create troubleshooting sections