Some technical writers hate FAQs. I rather enjoy them, because they’re the only bit of technical writing most people will ever bother reading. But they’re not always an easy thing to write; since FAQs are never full explanations of the application or website, deciding what to put in them can be difficult.

What Goes in an FAQ?

The truth of FAQs is that you don’t sit around waiting for people to start asking questions – you predict their questions. How?

One method, showing a considerable level of dedication, is to give your friends and family a first stab at the application. Whatever they all fail to understand is an FAQ (also, possibly, a bug report; but that’s a topic for another post).

You can also ask people around the company what confused them when they first worked with the finished product. QA, support, project managers, other writers and programmers. This may seem easier than the first method, but there’s a good chance that they’ll refuse to admit to many of their difficulties, so lay-people will provide a more accurate list.

The easiest, fastest method – and one which I suspect is most widely employed – is to just make the questions up as you go along. Play a little with the application and see what comes to mind. After all, as a technical writer, you know what needs explaining; it’s just a matter of deciding what needs it enough to fit an FAQ.

And of course, you could search for companies in the same general field and read their FAQs. You might find that they all copied off of each other. You can embrace it as a proud tradition, if you like.

What Are Some Dos and Don’ts for FAQs?

1. In my experience, two types of people read an FAQ: people who want to get to know you and your product (including future employees and funders), and people who have actually encountered a problem and are searching for an answer. Avoid the temptation to write your FAQ for the first type; your FAQ should aim to provide answers to actual user questions, not serve as another set of marketing blurbs.

2. On a similar note, I don’t advise putting your disclaimers in the FAQ. People don’t care about your disclaimer, and the goal of an FAQ is to provide the information people care about the most. While I don’t find this as objectionable as putting your PR in the FAQ, I still avoid it when I write.

3. Each question must be understandable as a standalone. Don’t use the previous question as the context, because readers might not have read the previous question.

4. Group questions about each topic under a header. If your FAQ is long enough, provide a table of contents, at least at the topic-header level.

5. Admit your faults. If the answer to a question is “because this product isn’t good enough yet”, say so (you might want to soften the language). Don’t avoid the question, and don’t give a round-about answer.

6. If you make a serious change to your application, business module or anything else that highly affects your users, create an FAQ for it. It can be a topic in the general FAQ page, or get its own page; just don’t hide it among the rest of the FAQ.

7. If your FAQ is starting to resemble your user manual in size and complexity, consider splitting it into several FAQs, each associated with a specific portion of your application or website. Or, consider trimming back and sending people to read the manual for the more complex questions.