Michael Eriksson
A Swede in Germany
Home » Language and writing | About me Impressum Contact Sitemap

Common errors when writing FAQs


Over the years, I have seen many, many FAQs of various qualities and implementations. Unfortunately, many have been of poor quality through amateurish errors—many relating to the presentation. This page attempts to deal with some of these, in the hope that others will avoid them.

Most FAQs that I have encountered (and most of the early FAQs that existed) have dealt with topics directly or indirectly related to technology. This is reflected in many formulations below; however, the statements typically apply, m.m., to non-technological FAQs.

Breaking the corresponding document(s) up into too many pieces

Too small documents can be a major PITA; in particular, the inexcusable versions where each answer is put into a separate page, possibly only accessible over JavaScript. This has at least two major disadvantages:

Firstly, it is impossible to read/skim through the entire document in one sitting (which is a very good way of getting a quick overview of the relevant issues).

Secondly, it is impossible to navigate by a full-text search—again unnecessarily crippling the users. Consider e.g. trying to find all questions relating to, hypothetically, “keyboard”, without a search. Unless all relevant questions happen to contain the word “keyboard”, this is a lost cause (respectively, unavoidable leg-work)—and even if they do, the user may need to engage in unnecessary manual inspections.

If the over-all size is very large, then a division (typically by sub-topic) into smaller sub-FAQs is in order; however, it is better to err on the side of too large than too small. Notably, if the intent behind a division into sub-topics is to make navigation easier for the user (not to reduce size), then the sub-topics should still be kept on the same page.

Splitting questions and answers

Keeping the list of questions on one page and the answers on another (typically with the questions repeated) is a very common error. This is wasteful and reduces usability (as above). It is much better to adhere to the standard format: One page with a listing of all questions, followed by question 1/answer 1, question 2/answer 2, etc. (If the typical answer is short it may even pay to skip the initial listing, and go directly to question 1/answer 1, ...)

Making up questions

Frequently asked questions, by their very, nature, have to be questions actually asked. Some lee-way can be given to include rarely asked questions and/or questions that are implied by the behaviour of users. However, the common practice many companies and amateurish writers have of trying to predict what questions the users are likely to ask, is not acceptable. Further, abuse of a FAQ to sneak in self-advertising is inexcusable (e.g. “Does [the product in question] support feature A? Yes! As the first product ever we support feature A since release 4.2.”).

Note that a question/answer format (as opposed to a FAQ format in the stricter sense) can, in and by itself, be tempting, as an easy way of bringing over information. I strongly advice against this—it is mostly a way for the author to make life easy for himself, rather than the reader. Under no circumstance must the result be referred to as a FAQ.

Leaving out legitimate questions that may look bad

Some organisations, in particular of a commercial nature, like to leave out questions that make them look bad, or (conversely to the above) an actual question about a feature, which is not present. Answering this question truthfully can safe users hours of unnecessary searching and experimenting; and repressing the answer in the hope of more sales is not only unprofessional, but even unethical.

Abuse of the word “FAQ”

Lately, I have seen several instances of the word “FAQ” being used to denote something that is manifestly not a FAQ: Consider e.g. this (http://staufenbiel.de/it/faqs.aspx) alleged FAQ, which is in fact a series of articles (in German, retrieved 2009-04-13).


This document appears to have been subsequently removed. I have de-linkified the URL to avoid unnecessary noise when doing automatic link checks. I will update the page if and when I see a good replacement example.

This error is so unbelievably idiotic, that it cannot under any circumstance be excused. I can but hope that its inclusion in this list turns out to be incorrect, due to the common-error criterion.

Writing trivial FAQs (with advice on when to write a FAQ)

There are many small players who add FAQs with a handful of very superficial questions that are already covered in other far more substantial FAQs. For popular topics like HTML there are likely hundreds of FAQs flying around—most of them useless, all but a handful redundant.

The hitch is that if these FAQs turn up elsewhere, notably in search-engine results, they can make life harder for people searching for the “real” FAQ. In particular, a Google search for “X FAQ” is one of the first stops for those who are used to quality FAQs and looking for info on X, or who are trying to trouble shot an obscure problem. It is not uncommon to get pages with results back—and having no good way to say in advance what links are worth visiting.

A related problem is the “local FAQ”: An organisation (typically a company or a university) puts out its own FAQ on a big topic dealing with local characteristcs (e.g. an email FAQ with questions like “How do I read my email at the University of X in Firefox?”). While semi-legitimate, it would be highly preferable if these organisations where to either avoid the word “FAQ” (say, instead using “Guide on email at the University of X”), or to keep the FAQ out of search-engines (e.g. by robots.txt rules). Another alternative is to have a “University of X FAQ” that deals with sufficently many sub-topics (e.g. all relating to computers) that no no confusion with specialist FAQs occurs—the length of the original FAQs are rarely large enough that the combined document would be preventatively long.

I suggest the following rules for deciding whether to write a FAQ (“you” below will more typically be an organisation than an individual):

  1. Unless you actually are regularly asked questions on the topic—forget it: Chances are that what you would write would not contain legitimate entries; and it is quite possible that you are not qualified to write the FAQ, even if the entries were legitimate.

    Legitimate writers can include regular participants in user forums or others who are exposed to many questions by other means. These, however, should try to associate the FAQ with the forum and to publish it this way.

  2. If you are asked questions and wish to write a FAQ, first have a look around at what is already present. If there are one or several high quality FAQs around, it is rarely a good idea to start another.

    An exception is when you are the maker of a software, the institution providing a specification, someone with a legitimate claim to being the expert, or similar.

    If the existing FAQs are good, but miss some issues that you wish to have included, it may be better to contact the FAQ maintainers instead—if the issues actually qualify to be in the FAQ (which need not be the case), a good maintainer will be happy to include quality answers.

  3. If you have not bowed out yet, go ahead. If you can, make the FAQ a part of a collaborative effort (e.g. a community around a forum): This will likely give the best long-term results, and even a very rudimentary FAQ from you may be acceptable as a starting point. If not, make sure that what you have written is actually worth the readers time, before publishing.

Notably, a real FAQ, the kind that has made FAQs known and loved, the kind that really brings benefits, is rarely short than half-a-dozen screenfuls of text—and can be much longer.