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?
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).
No-one asks that type of question. 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.
Frequently asked, not frequently visited
Another trap is to confuse frequently visited answers with frequently asked questions. It works in one direction: if you have found a genuinely frequently asked question, then you’d expect it to be frequently visited. If no-one is visiting it, then maybe no-one is asking that question.
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.
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.
Questions, not statements
The new www.usa.gov had 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 guys: 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. And 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, creative commons
featured image faq by airpix, creative commons licence