Over the years, I have seen a great number of FAQs of various qualities and implementations. Unfortunately, many have been of poor quality through amateurish errors—often relating to the presentation. This page attempts to deal with some of them, in the hope that others will avoid the same errors.
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 might be reflected in some formulations below; however, the statements typically apply, m.m., to non-technological FAQs.
Revisiting this page in 2012, I am struck by the fact that I search for FAQs much more rarely today than in the past. The main explanation is that the average value has diminished severely over the years—mostly due to the problems below.
Doing so again in 2023, the same rarity remains or has increased, as even finding a FAQ is not always possible, be it because they have simply not been written or because the low-quality hits from search services are unlikely to include them.
To the former, I suspect two issues: Firstly, that younger and less tech-savvy generations are less likely to have an awareness of FAQs and their benefits (and/or have a too negative opinion of them based on problems like those discussed here). Secondly, that the move away from discussions on mailing lists and in news groups have made it harder to get the overview needed to write a FAQ. Indeed, on the StackExchange network, there might be an outright incentive against writing FAQs, as an umpteenth copy-and-paste answer to the umpteenth version of the same question is more likely to bring points on the platform.
To the latter, I again suspect two issues: Firstly, many traditional FAQs are/were hosted on low-traffic sites, while modern search services seem to more-or-less ignore quality in favor of mere popularity. Secondly, the presence of “FAQ” (or a variation thereof) in a search query could limit the number of hits “too much”—and modern search services certainly prioritize many hits over relevant hits, which could make them ignore the “FAQ” entirely.
(In addition, there might or might not be some negative influence through the common presence of endlessly duplicated message-board (wiki, bug tracker, whatnot) FAQs, which are provided by the message-board developers and discuss how to use the message board, as opposed to the topic of the message board.)
At least for the purposes of this page, I use “FAQ” to refer to the list of questions plural (and the respective answers), with “FAQs” as the plural of “FAQ” in that use (i.e. two or more lists of questions).
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 three major disadvantages:
Firstly, it is impossible to read/skim through the entire document by just paging down the list (which is otherwise 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 might need to engage in unnecessary manual inspections.
Thirdly, it is impossible to treat the FAQ as a single whole, e.g. to download it for offline access or to keep it open in a single browser tab.
If the over-all FAQ is very large, then a division (typically by sub-topic) into smaller sub-FAQs is acceptable; 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.
The importance of size has decreased steadily over the years. Now, in 2023, I see little relevance of size for FAQs at all. Not only is the actual text of even a very large FAQ downloadable in the blink of an eye, but chances are that the overall download-size is determined less by that actual text and more by various types of HTML/CSS/JavaScript overhead, pointless images, advertising, whatnot. If the “blink of an eye” does not hold, or size is still otherwise an issue, then the correct action is to cut down on the overhead (etc.)—not to divide the text onto several pages.
By 2023, a separation into pages has increasingly been replaced by a stubborn insistence to only ever show one answer at a time: the list as a whole is displayed, but to view the answer to any question requires a click/hover/whatnot in order to “activate” the answer—and doing so automatically “deactivates” any previously displayed answer. Similar issues apply, with the added complication that unnecessary technical limitations are imposed and might exclude some users, force others to activate JavaScript, require manual workarounds, or similar.
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 single 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 might even pay to skip the initial listing, and go directly to question 1/answer 1, ...)
Frequently asked questions, by their very nature, have to be questions actually asked. Some leeway can be given to include rarely asked questions and/or questions that are implied by the behavior of users. However, the common practice of many companies and amateurish writers to merely guess at what questions the users will ask, is normally (see below) not acceptable. Ditto e.g. questions that they hope that users will ask and questions that are not, or only rarely, asked but do allow for self-promotion (e.g. “Does [the product in question] support feature A? Yes! As the first product ever we support feature A since release 4.2.”).
A limited room for exceptions exists when the questions are highly predictable and/or almost certainly will be asked in the future, or would be asked if a sufficient user/customer/whatnot base were present. For instance, the maker of a software might be justified in including some few (adaptions of) questions of a very general character (e.g. “Where can I find the latest version of [software at hand]?”) from FAQs for other softwares. Even here, however, it might be better to wait for actual questions—while making sure that the non-FAQ documentation is sufficiently complete, up-to-date, and easy to use.
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 may the result be referred to as a FAQ.
The point of a FAQ is not that the question/answer format would be a good way to inform—it usually is not. The point is that some questions are frequently asked and that the question/answer format makes it easier for someone about to ask one of these questions to find the relevant answer without actually asking.
(Especially in the early days, a secondary advantage might have been the ability to just lift a question and its answer directly from a mailing list, or whatnot, where the question had previously been asked.)
I suspect that these issues often contribute to other problems, e.g. in that some of the trivial FAQs mentioned below arise from someone wanting to say something and misguidedly choosing the fake-FAQ format (while others might genuinely deal with frequently asked questions, only limited to a small subset). Chances are that the restriction to actually asked questions, on its own, would bring a very major improvement.
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 that is not present. Answering this question truthfully can save users hours of unnecessary searching and experimenting; and repressing the answer in the hope of more sales is not just unprofessional—it is outright unethical.
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.
There are many small players who add FAQs with a handful of very superficial questions that are already covered in more substantial FAQs elsewhere. For popular topics like HTML there are likely hundreds of FAQs flying around—most of them useless, all but a handful redundant. (The same applies to e.g. tutorials. While these are off-topic, the same implied recommendation holds: do not write an umpteenth tutorial that covers the same ground as the others.)
The hitch is that if these FAQs turn up elsewhere, notably in search-engine results, they can make life harder for those searching for the “real” FAQ. In particular, an Internet 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 specific local issues (e.g. an email FAQ with questions like “How do I connect to my email account at the University of X with client Y?”). 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). An alternative is to have a “University of X FAQ” that deals with sufficiently many sub-topics (e.g. all relating to computers) that no confusion with specialist FAQs occurs. (A partial other remedy is to use a good title, e.g. “University of X email FAQ” instead of “Email FAQ” or something similarly generic. This would, at least, make it easier for searchers to filter results without visiting.)
I suggest the following rules for deciding whether to write a FAQ (the “you” below will often be an organisation, not an individual):
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 and others who are exposed to many questions by other means. These, however, should try to associate the FAQ with the forum (or whatnot) and to publish it this way.
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 more high quality FAQs around, it is rarely a good idea to start another.
An exception is when you are the maker of a software [that is the topic of the FAQ], 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 might 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.
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 might 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 shorter than half-a-dozen screenfuls of text—and can be much longer.
The following is an automatically generated list of other pages linking to this one. These may or may not contain further content relevant to this topic.
Annoying writing mistakes
Assorted examples of how not to implement a website
Sitemap