Comment in 2025: I wrote this in 2007. Since then, content designers have often pointed out for at least a decade that Frequently Asked Questions (FAQs) are a bad way to meet user needs. Nevertheless, I still find plenty of FAQs on the web and in apps, so these tips are still relevant.
FAQs don’t have that great a reputation, but recently, I’ve been working on FAQs for a client. Their computer help desk was annoyed about answering the same things again and again. Why not divert potential callers to a FAQ instead?
Sounded reasonable, so we did the usual: created a prototype, ran some usability tests, did the necessary pile of changes and launched the revised version, rather quietly. And bingo: a modest success. Calls to the help desk are down 10% and users are rating the FAQ answers highly, on the whole.
So what distinguishes a good set of FAQs from a dreadful set?
Ensure the questions are “frequently asked”, not “easily answered”
I’ve seen many sites that fall into the trap of providing a set of easily answered questions (EAQ) rather than frequently asked questions (FAQ). Here’s an example:
- “How long does reconfirmation usually take?”
No-one asks that type of question, because how does the person arriving at the website even know what “reconfirmation” might be?
You have to do the hard work: find out what questions really are frequently asked. And by your customers – not by insiders.
Try all of these:
- listening to calls to your help desk
- reviewing search logs to see what people are searching for
- reading emails.
You don’t have to look back very far. If the question is genuinely frequent, it will come up at least once a day. But I think it’s worth reviewing a month’s worth of data just to be sure you’ve covered things that only happen at specific times e.g. at month end.
Choose “frequently asked”, not frequently visited
Another trap is to confuse frequently visited answers with frequently asked questions.
It’s worth having a look at your site logs to find out the level of use for each of your FAQs, but getting lots of visitors to an answer doesn’t necessarily mean that it’s the question your visitors want to ask.
As well as using an answer to figure out how the service works, I’ve seen people choosing an answer because it was the least worst answer and they were desperate. I’ve also seen people choosing an answer because they already know it, and they’re checking it out to find out whether your answer is correct to establish whether they can trust you.
If an FAQ is barely or never visited, that’s an indication that it’s not frequently asked but is an EAQ that’s sneaked into your list. Consider deleting it.
So check your logs to prune out answers that are getting a low level of visitors – but don’t rely on them as your source of questions.
Use questions, not statements
Back in 2007, FirstGov.gov relaunched as www.usa.gov with a “frequently asked questions” section. I clicked on it and got this as the top item in the list: “FirstGov.gov is Now USA.gov – New Name; Same Great Services!” Yes indeedy; that’s supposed to be a question. Well, sorry : it’s a blatant piece of marketing fluff which diminishes the credibility of the whole FAQ. But it would be so easy to rewrite: “Why have you changed your name from FirstGov.gov to USA.gov?” Or even: “Is USA.gov the same as FirstGov.gov?” Which is shorter, easier to read, and doesn’t have any claims about the quality of service.
Make sure you write your questions as questions, briefly, and in plain language.
Format the FAQ’s into sections
Break your FAQs into groups – maybe by doing a bit of card-sorting on them. Think about some sort of organising principle: by topic, by time of the month, even by alphabetical order. Anything to help people find their way to the one that’s relevant to them.
Offer a way to get specific answers
Provide easy ways for your users to get their precise question dealt with, preferably through a choice of email, phone and snail mail.
If you put a feedback box about the quality of the answer right there on the FAQ answer page, then rest assured that at least half the people who use it will treat it as a way of asking their specific question. So make sure that those feedback emails go first of all to your regular help staff, and only later to your FAQ development people.
Get ratings from your users
It’s polite to allow users to rate your answers. Give them a way to say whether the question was helpful, partly helpful, or unhelpful. Ideally, offer a follow-up box for comments on a separate page after the rating. I was quite impressed with the way www.usa.gov does this. Then make sure that you frequently check the ratings (and any follow-up comments). Work rapidly to fix unhelpful answers – or delete the question altogether if you can’t improve it.
Review your content
And finally, check back to see whether your main content areas could embed the answers – rather than forcing people into the FAQs.
This article first appeared in Usability News, 28 February 2007
Picture of Questions by Roland O’Daniel on Flickr , creative commons license.
Featured image of FAQ by airpix on Flickr, creative commons licence.