Publishers of technology books, eBooks, and videos for creative people

Home > Articles > Web Design & Development > Usability

Web Design Reference Guide

Hosted by

Web Writing That Works: FAQs That Really Answer Your Customers' Questions

Last updated Oct 17, 2003.

By Jonathan and Lisa Price

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 we started writing for the Web, we hated FAQs because the authors ignored so much that we had learned in developing manuals, Help systems, and 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 occasional flakiness 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, we should give in to the popular demand for this odd, democratic, and chatty genre. Adopting the FAQ, then, we suggest developing some tactics to improve the FAQ.

How Is An FAQ Different From Help?

In an FAQ, every topic begins with a question, usually in boldface, acting as a kind of heading, followed by an answer, which may be a phrase, a sentence or two, or several paragraphs.

But the questions also appear as items in a linklist at the top of the page, pointing to anchors farther down the page. These mini-menus often seem hit or miss, a random assortment, so users have to depend heavily on the actual text to figure out which one deals with their problem.

Because these links usually jump down the page, rather than going to separate pages, users sometimes get confused (where am I?), so many sites offer Back to Top buttons after each Q&A.

By contrast, Help systems tend to use noun phrases or individual words—not questions—as headings, organizing the articles into a deeper hierarchy, with three, four, or more levels. Links usually take you to new pages. More thorough, and better organized than FAQs, but less inviting, help systems often intimidate users by the sheer number of topics.

But today the two genres are blending into each other. A section called Help may have a sprinkling of questions among the lists of topics; and an FAQ may have longish answers that sound as if they came out of a manual. eBay, for instance, begins its Help page with the top five questions being asked today...and many of the help topics grouped below turn out, on their pages, to be framed in a question-and-answer format.

Where Should I Put My FAQ?

If your site is small, make the FAQ a separate section, and put an FAQ link on every page. That way, people can get their questions answered from anywhere.

If you are supporting a big site, you may be facing so many questions about so many topics that you may have to create an FAQ for each department, or each subject, or each product category, rather than a single FAQ for the whole site.

Example #1: At Macy’s site, there’s no link for help. You have to intuit that the link for Customer Service will lead to a set of FAQs, on seven different subjects (My account, Returns, Shipping, My order, Pricing, Our products, Gift cards). Each subject page offers a dozen or so questions at the top, linked to Q&A sections below.

Pro: They have grouped the questions logically, so you can browse more quickly to the relevant ones.

Con: You may never know that Macy’s wants to answer your questions.

Example #2: CNN seems to assume that you don’t need help understanding the news, but you may need technical help on using what they call services, such as their Pipeline videos, RSS feeds, or their ubiquitous pop-over-then-under ads. At the top of the video window, for instance, CNN has placed a small Help button, which takes you to an FAQ page, topped with a discreet Help menu offering links to the other FAQs. But the Help section is not advertised on the regular news pages. In effect, these narrowly focused FAQs are revealed only when you are trying to carry out some action, such as resolving installation problems.

How Should I Write The Questions?

Write questions as if you were the guest.

Good questions:

"How do I order?"

"How do I find what I’m hoping to buy?"

"How do I redeem a gift certificate?"

Notice the "I" in the good questions.

The writers are standing in for the customers, speaking for them, phrasing the questions as if they were really coming from the customers. Even when the writers do not use the word "I," that point of view is implied.

Sure, these questions have been sanded, planed, and simplified way beyond what the average visitor might ask. But consider the position from which they are asked: they come from the guest, not the site.

Some not-so-hot questions:

"What is the order process?"

"What is Findoramatic Search?"

"Gift certificate policy"

Bad questions are self-centered. They reflect the site’s concern with its own policies, concepts, and values. These questions do not sound like what a guest might ask.

In fact, the last "question" is not even a question. Avoid "questions" that are really just labels for content.

The point is to evoke a real conversation, even though it is virtual.

How Should I Format The Q&A?

Distinguish the question from the answer.

Don’t run the question right into the answer. Why? Because they serve different purposes.

The question articulates the problem, helps the user locate the right answer. But the answer tells the user what is going on, and what to do. A different function: so use a different format. At least throw the answer into a different paragraph, probably in plain text.

Treat the question as a heading, or at least a very bold statement, with some kind of dramatic color, large size, or boldfacing. Press return after the question, separating it from the answer. Then treat the answer as regular text, indented a bit, so the questions really stand out.

Giving the Q and the A different formatting suggests you are taking turns in the conversation, with the user’s questions bigger and bolder, as befits their importance, and your answers plainer, and perhaps even indented, to indicate your humble responses.

Question: Should I start every question with the word Question?

Answer: Sure, if you start every answer with Answer. But generally people understand the convention of Q&A, and grasp a boldfaced question without the label.

How Should I Write The Answers?

Simplify your prose.

Sometimes, perhaps because of this conversational setting, FAQ sentences tend to ramble.

Worse, some writers add clause after clause, and insert subordinate clauses within relative clauses, tossing in some when’s and if’s.

A guest who wants to understand will have to pull these multiple clauses apart, parsing meaning out of each piece, and then putting the pieces together to make sense.

Get active, too!

Alas, the passive voice also attracts a lot of FAQ writers. Turn the passive verb into an active one, transforming "Your order is now confirmed" into "We confirm your order." The passive is lazy: it lets writers avoid saying who or what is doing the action, even though that kind of trick makes the sentence ambiguous. "Your entry is refused." By whom? By what? If no one is responsible, how can a visitor get mad? Easy.

Try 'fessing up by using the active voice.

"If you get this message, we apologize: our database can’t understand what you’ve typed. Please try again, using the tip next to the slot on the form."

Break your paragraphs up, too.

Too many FAQs try to compress the entire answer into a single large paragraph, as if that made it a unit.

But you’re on the Web, and people come to the FAQ upset, anxious, angry, ashamed—not in a great mood for reading, and certainly not thoughtful enough to read ten 10 or 15 lines of prose extending from one side of the window to the other.

Got a list? Reach for the bullets.

Open that answer up, even if you end up using half a dozen paragraphs for the bulleted items.

How Should I Handle Instructions?

Put instructions into numbered steps.

Breaking your instructions out into numbered steps makes them more effective. Why? With numbers...

People understand the sequence better.

They skip fewer steps.

They succeed more often.

One meaningful action per step, please.

Don’t try to cram two or three actions into a single instruction, because people do the first, then the third, or get confused.

Yes, piggybacking makes your procedure look simple, because there are fewer steps. But the individual steps, clotted with more actions than a user can absorb at once, end up failing.

What’s meaningful?

That depends on the guest. For instance, beginners find command lines a tough way to interact with a program, and consider typing DIR a major action, and pressing Enter another big step.

But experienced DOS aficionados understand "Enter DIR" to mean, "Type these letters and hit the Enter key."

Here’s a case where personalization can help you differentiate your FAQs by skill level. The instructions for experts generally compress more actions into a single step, and skip most explanations.

Begin each instruction with a verb in the imperative, if possible.

Don’t say what the users can do, or may do, or might do. Tell them what to do.

You may feel you are being rude, but bossing the user around is actually a courtesy, because you save time, and make clear that, at this point, the user really must do x, y, or z. No maybes, then.

Q: What can you put before the verb?

A: A motive or a goal.

If you have to say why people should do the step, or what their goal might be, start with the purpose, and then move to the action.

Example: "To confirm your changes, click Change."

If you need to say exactly where to act, put that first, too.

Example: "At the bottom of the license, click Submit."

In these ways, users know up front what the point is, and where to look. Knowing the goal and the locus of operations will help them grasp the instruction better.

Also, putting the goal, motive, purpose, or location first tends to follow psychology more closely: first you have a goal, then you look around for an affordance to operate on, then you act. (Evaluating whether you have succeeded comes later--in a following paragraph, if ever).

Skip the pitch

Don’t pretend you're writing instructions, and then decline into marketing talk.

Example 3: "Using Find Topics is a quick, easy, and powerful way to describe the particular product you may be looking for."

Oh gee, that’s wonderful.

But that text does not answer the basic question, "What do I do next?" Giving me an ad instead of a step just makes me mad.

Separate the instructions from any explanatory material

Put the explanations into separate paragraphs—after the individual instruction.

Each step answers one question: "What should I do next?"

The explanations tend to answer ancillary questions, such as "What does that term mean? What’s the result?"

So the explanations are different elements, with different responsibilities, and they deserve their own separate identities, as separate paragraphs.

Breaking explanations away from the steps means the impatient user can just read the steps, and do those, and never read your explanations.

Nervous folks, though, want their sweaty palms held tightly, and seem grateful for the separation, which makes clear, "You do this," and "Here’s more information if you want it."

Gradually unfolding works better than jamming all the information into a single paragraph.

Also, if you're working in an object-oriented environment, you're going to want to be able to identify, and omit, explanations when you send this stuff out to a mobile phone, or turn it into a quick reference. Explanations, then, are different objects.

Can steps be links?

Yes. If each step is actually described in a separate answer, and the step really involves several actions, you can tell people, "Enter your credit card information," making that instruction a link to the full details on entering the credit card info.

What if I'm repeating myself?

Few guests actually read through the whole FAQ.

If you think the same tip applies in half a dozen answers, include it in each one. You won’t bore anyone but yourself, because only you actually read all of those answers.

For instance, if you have 10 answers describing various settings the user can change, but none of these changes takes effect until they complete the current login session, then you better warn them of that little constraint after each answer. In this way, no matter which answer they read, they will realize that even if they have made the change as you suggested, nothing will happen until they log out and log back in.

Little stupidities like this often get described only once, somewhere in a note, where nobody may stumble on the information. Result: lots of confusion, even rage.


If the user has to do the same action, write the same step, no matter how many answers you have to insert that step into.

Even if the user has to do two or three steps that are just like the ones in other answers, go ahead and put them in. Do not make the user jump to some other location to find out how to do these things, and do not be original, and write up a different way of doing the same thing, just to be creative. Say the same thing the same way each time.

If an action involves more than three steps, OK, link to the answer that provides that procedure.


Cautions, too, should be repeated--wherever the user could get in trouble.

By the way, don’t call a cautionary passage a note, or a tip--people often skip sections with those names, as unimportant extras.

You don’t have to put an image of a skull and crossbones next to your cautions or warnings, but you should make clear what they are, with labels and special formatting.

And don’t wait until the end of the answer to mention, "Oh, by the way, back in step 3, if you happened to type the wrong name, the software probably froze up."

Better to put a caution in step 3, saying something like, "Please be careful to type your name right, so you don’t confuse our rather simpleminded software."

Obviously, your engineers ought to stop ambushing users like this, but until they do, your job is to alert people before they get in bad trouble.

If a misstep could result in lost or garbled data, put your caution ahead of the step.

If the problems are easier to fix, put the caution right after the step.

Should I show pictures?

Yes, yes, yes!

As our audiences grow to approximate the general population, people who have trouble reading join the ranks of people who just resent being forced to read on-screen. So even if your work revolves around text, think visually. If possible, make up a storyboard for each important answer, showing the key concept, or diagramming the process.

Where you have a series of forms you want people to fill out, put a series of numbered instructions at the top of each page, with an illustration, and highlight the form the user is on. In that way, as the user moves forward through the sequence, the visuals show progress, while explaining each major step.

Bring that kind of thinking back to the FAQ. Look at Macintosh manuals, where each step starts with an image on the left, shows a giant number in the middle, and, finally, over on the right, explains the picture with, uh, text. Pictures first, text second--that ought to be your mantra in FAQs.

Show pictures of icons.

Show tools.

Show screenshots.

Show diagrams of complex concepts, process flows, and relationships.

When the text inside the diagram acts as notes, you're getting through.

When the art is so expressive that you don't need to add any text, well, you’ve achieved the high level of Lego manuals.

How do I know if I've answered the question?

At the end of each answer, ask whether you have provided the information the visitor needed.

"Did we answer your question?"

"Did you find out what you wanted to know?"

If yes, thank them, and offer to return them to the page they came from, when they entered your FAQ.

If no, provide a form to email back.

If your engineers can manage it, grab the URL of the page they are looking at, and put that in the subject line, so you know exactly what text they are talking about. In a dropdown list, allow them to specify the kind of topic they were exploring.

Ask in detail what they want to know.

Ask them to grade the quality of the FAQ, if you dare.

And give them plenty of open space to write, and write, and write their complaints, laments, life stories, whatever. Do not limit them to answering your questions; let them express themselves.

Make sure that the email form is addressed directly to you, personally. You need to find out if your answers are working. And you owe it to the visitor to clear up the confusion.

Only really bold sites do this. But think of the impression they make. A guest reads an answer, and it may make sense, but the guest sees the offer. Wow!

Of course, as the writer, you have to answer a lot of e-mail if your prose is murky.

When Do I Know My FAQ Is Done?

You don’t.

Every time a guest asks a question--by e-mail, phone, chat, discussion board, or mail--you should consider adding the answer to the FAQ.

If you believe the answer is already up on the FAQ, ask yourself: How come this particular guest couldn’t find that?

Or, if they read it, how come they couldn’t understand it?

More important, recognize that you may not really have answered the question.

But don’t just wait for customers to complain.

Too often, FAQ writers act as if the system is always working the way it is supposed to, or the way the engineers say it will.

Try the task yourself, and keep looking for areas where an ordinary person--like you--might get confused.

Invent several scenarios, and try each one out, using your instructions.

You’ll often find problems, variations, unsuspected gotchas.

And when you feel your answers are really accurate, run a little usability test, the quick-and-dirty way, using half a dozen people to see if they can actually locate the answer and, then succeed at acting on it.

You don’t need scientific proof or statistically meaningful measurements. You just need to watch people struggle with your prose. The experience of watching people not find your answer, not follow it, not understand it, and not succeed can be pretty sobering. Your fingers will begin to itch to rewrite.

A good FAQ is a conversation that never ends.