Just ran across a conversation about FAQs in the Google Group for content strategy. [If you’re interested in CS, you need to join this group! Lots of great ideas.] This conversation popped up at a great time for me — I’ve been pondering FAQs for a few weeks now, and here’s what I know:
FAQs started — decades ago — as a vehicle to help discussion forums clean out the clutter. New forum users often showed up with the same questions that long-time users had asked before, and it got repetitive to answer the same questions over and over again, so many forums set up a list of questions that were frequently asked, along with the definitive answers.
I remember very clearly when I first used an FAQ page on a regular website. It was the mid-to-late 1990s, and we were so cutting edge. It was a real inside baseball joke — we had to explain to our client what an FAQ even was, and they still couldn’t figure out why we needed one.
It turns out, we were both right. We were right — FAQs slowly started popping up everywhere over the next few years, until you wouldn’t even think of building a website without one — and our client was right, because FAQs just don’t make sense on a text-based website with a content management system, Learn C++ and programming scheme that have any level of sophistication.
Why FAQs are a bad idea for your website:
- FAQs are rarely well written. It takes a lot of talent and time to write well from the contorted perspective of an FAQ. Are you asking the questions in your customer’s voice? Are you answering them in yours? Or both in your voice? At what point do you give up and just start throwing pronouns around willy-nilly? If you’re like most FAQ writers we’ve seen, that happens pretty early in the process and the results show it.
- FAQs don’t actually help customers. The construct of an FAQ — couch your help copy in the kinds of questions a customer might ask, if you let them call you — actually makes it more difficult for your customer to get an answer. When people are seeking information online, they’re skimming for keywords that describe their issue. You’ve surrounded their keywords [change password] with a bunch of extraneous copy [How do I change my password?]. Stack that simple question up with 2-3 dozen more “helpful” questions, and people can’t find a thing.
- FAQs don’t live at the point of sale. Your customer needs help figuring out how to add a photo over on the profile page, not from an FAQ page that’s a link in the footer. FAQs aren’t in context, and your customers are more likely to give up and leave your site than they are to search around…and around…and around to find the answer.
- FAQs don’t fix your sucky website. When you use FAQs on a website, they become an ineffective panacea for every problem with the interface and the content. People abandoning their shopping carts? Slap a couple more FAQs up there. Landing page not working well? Must need more FAQs.
What to do instead of using FAQs:
- Fix your website. This is the hardest answer, but the best one. If something’s not working on your website, make it work.
- Use in-context help. This often will require development, but putting help in-context makes a big difference. Add a little question mark or the word “Help” linking to a pop-up window with the tip right on the page where the problem happens. [Bonus: A good use of a pop-up window!]
- If all else fails, create a topical help directory. If you can’t do the development or don’t have a system that supports in-context help, at the very least, throw out your FAQ and rewrite the information as a topical help directory that customers can easily scan and navigate. You eliminate perspective issues and your information is much clearer to your customer. Similarly, if your customers come to you with a wide variety of expertise, you may have to hit the largest group in terms of usability — and some people will need more help. Make it easy for them to get it.
Finally, if you’re running a discussion forum — by all means, use an FAQ. Everyone hates seeing that same question asked by new users every week.