How to Create an FAQ that Works
I have come to suspect that most “Frequently Asked Questions” were never asked by anyone. I’ve witnessed the creation of many FAQs, and I can recognize the results of the typical process:
People are sitting around a big table in a conference room, trying to look interested, 40 minutes into a meeting. Someone says:
“We need to have a page to point them to, if they have questions.”
A second person says
“What questions do they have?”
Just kidding. Nobody says that. The second person says something that amounts to
“What do we want to tell them? We can work backward from there, and contrive some questions that feature our favorite jargon—without ever actually having to speak to a potential user.”
Real questions come in, but nobody puts those in the FAQ, and maybe nobody updates the FAQ at all.
Or, worse: They update the FAQ with by copy-pasting everything that comes in, creating a dump of un-edited, un-indexed information. People have to read it top-to-bottom to see if anything looks similar to their own question. If they try to search, the oddities of phrasing and word choice mean that nothing matches, until they pick words that make everything match.
This “Find A Question” FAQ approach happens when the team (usually without a writer) says
“Punt! I don’t want to sort through all this information, creating structure, navigation, or indexing. I don’t want to categorize this, or consider where the answer might apply to a broader audience, or what audiences we have, or basically do anything more than set out a garbage can for people to dig through and try to cobble together an answer that nearly works from a pile of misfit pieces. We’re required to have support, so there! We’re done.”
That’s why many FAQs don’t work.
Here are some guidelines for making an FAQ that does work.
Your FAQ needs to reflect the perspective and terms that are most familiar to your audience—not you or your experts. Say it out loud: “What’s it like for them?” Re-phrase questions and answers so that they are clearer, and include context if necessary. And, of course, address the questions that are really most common for your audience. If you’re starting with a new product, survey your likely audience for starter questions.
Imagine you’re a typical person looking for an answer. You see an FAQ. Is your question there? How do you know? You have to read it. Every question. As I’ve said, trying to search an FAQ for a term is always a fuzzy mess. What if there are 40 questions, and yours isn’t there? Anger. So I say an FAQ should only be the “10 most frequently asked questions.” It should be short and scan-able, like the “first line of defense” that catches the most common questions and lets other questions quickly move on to your support navigation menu. If you have more questions, at least break them into categories to guide users. But better yet:
An FAQ needs to be backed up by more complete structured support information, with effective navigation. Offering an FAQ as your only support is like giving people a map that onnly shows interstates. In fact, the “answers” in your FAQ should link to the appropriate topic in the support info, so that people can follow the breadcrumbs or other context links there to find related info. That also makes it easier to update the answer in one place later…
… because your answers will change. Or, they probably should. You should refine them as you learn more about your audience. You should also revise the questions in your FAQ if/as other questions come in more often. You should definitely check for and remove information that’s outdated. Outdated information is worse than no information.
To sum it up:
An FAQ is a communication tool, with a real live audience that may be halfway to frustrated when they get to the communication party. An FAQ can be an effective tool if it’s used effectively. It can also be a weak excuse for “support” that really wastes a lot of people’s tie and leaves you wondering “Why did everybody leave my communication party?”