FAQs are Still Useful

One of the most enduring and most maligned topic patterns in tech comm and on the Web is the FAQ. Writers and Information Architects frequently regard the FAQ as a sign of poor organization. For best and most consistent access, they argue, information should be in its proper place in the overall site or help system.

If the logic of top-down content organization worked, they would have a point. But the logic of top-down content organization generally only works for those who do the organizing, and then not always, as we can tell from the many sites, manuals, and help systems where any sense of organization peters out as soon as you get any depth into the content.

The logic of top-down organization fails

There are two fundamental problems with top down organization: First, hierarchies flatten relationships, and the more complex the real relationships, the more arbitrary the result of flattening them becomes. Second, most classification schemes make little sense to readers who encounter them, leading readers to search rather than pause to learn the taxonomy.

But most readers are not particularly adept as searching either. They often don’t know how to reformulate a query to get a more precise result, for instance. So if they won’t learn your taxonomy, and they can’t search effectively, how do we make sure that their basic information needs get served?

FAQs serve basic information needs

The FAQ can be an effective tool to meet basic information needs. If effectively linked into your broader information set, it can also be an effective doorway into your content.

Susan Farrell of the Nielsen Norman Group recently published an article, FAQs Still Deliver Great Value, that explores the main arguments for and against FAQs. I won’t repeat them here. Instead, I want to focus on the FAQ as a topic pattern and why it is a useful pattern in a bottom-up information architecture.

FAQs in a bottom-up information architecture

One of the most common misconceptions about a bottom-up architecture is that it simply means throwing away the table of contents. But to simply throw away the TOC would leave top-down content set with no effective entry point. A bottom up architecture, by contrast, is one in which every single page is an effective entry point.

Any type of page that works as an effective entry point to the content set, therefore, belongs in a bottom-up information architecture, including TOCs, if they are small enough and coherent enough to be effective. (Which most Frankenbook TOCs are not.)

Every page is an entry point

The Every Page is Page One design pattern is all about making every page an effective entry point to a content set. This may mean that the reader enters at a single page, finds what they need, and leaves, or it may mean that page is a effective starting point for a journey through several pages. The FAQ can be a very successful entry point by both these measures.

An FAQ is a type of list, and lists in general are an important topic pattern in a bottom-up information architecture. List are junctions in the reader’s journey through the content. Readers arrive at these junctions because an information scent has led them there, and then choose the item from the list that has the strongest scent of the information they are looking for.

The information scent of a FAQ

The FAQ gives off a particular kind of information scent: it promises quick access to information of common concern in brief form. As with food, so with information: sometimes “fast” is the first thing we look for. To the reader who arrives at a complex site, a FAQ promises a small and simple information patch where it will be easy to find a quick information snack. In other words, it gives off the sweet smell of speed and simplicity.

There are two times when this is likely to be valuable. The first is when the reader visits the site directly. Faced with a complex navigation scheme and a less-than-useful search engine, the FAQ offers quick and simple answers.

The second is when they arrive at a page of the site via search, don’t find what they are looking for immediately, and try to navigate the site to find it. If the site consisted entirely of Every Page is Page One topics that are richly linked along lines of subject affinity, chances are that they would find what they wanted soon enough. But if not, and if they keep trying to navigate the site rather than going back to search results, a prominent FAQ may blunt their rising frustration, perhaps answer their question, and at least help them establish the beginning of an information scent.

One of the key reasons that top-down architectures fail is that the reader’s sense of how the world is ordered (at least for purposes of their immediate task) is usually at odds with how the content is organized.

Bottom-up architectures provide multiple facets of organization

 

Top-down architectures insist on a single thread of organization and associations. A bottom up architecture, on the other hand, makes room for as many different threads of organization and association as can be found in the material. This can take the form of linking along all subject affinity lines in individual topics, and also in lists organized on different principles:

• Lists of topics of all types on a single subject
• List of all topics of a particular type on any subject
• Lists of all configuration topics that affect this feature
• Lists of all code samples that use this API routine
• Lists of all features that implement this concept
• Lists of all concepts that relate to this feature
• Lists of questions that users ask most frequently

Any of these lists may provide the key junction point the puts the reader on the right track.

FAQs provide a fast way in

One of the reasons that FAQs are so effective at the top level of a website is that they cut across the lines of the overall site organization. If it is a city government site, for instance, chances are that the average citizen does not know what department to report a pothole to. But most people will guess that reporting potholes is a frequent activity. The FAQ gives them information organized by a principle they can readily grasp.

More basically, a FAQ works simply by offering less. Daunted by the complexity of full site navigation, or simply unwilling to devote to time to learning and navigating it, a user may be attracted to the simplicity and brevity of the FAQ. FAQs make simple queries simple.

Like any list, though, an effective FAQ has to be a list of what it says it is a list of: frequently asked questions. It is not a place to put questions you wish people would ask or a list of things you really want them to know.

Anticipating frequently asked questions

This does not necessarily mean that you have to wait for questions to be asked before adding them to a FAQ. In many cases it is easy enough to anticipate many of the most frequently asked questions about any product or service.

In most cases, the frequently asked questions for your product or service will be very similar to those for similar products and services. In fact, if the pattern of frequent questions differs significantly from those of similar products and services, that probably indicates a deeper problem with the product or service itself. (If people are asking questions about your product that they are not asking about your competitor’s product, what is making your product so hard to figure out?)

A pattern in the questions themselves

Not only is the FAQ generally a common topic pattern, therefore. The particular set of questions frequently asked about any class of product or service is a topic pattern as well. While stopping short of outright plagiarism, let the market guide you to the kinds of frequent questions you should be answering. (But don’t base your FAQ on your competitor’s obviously false and self serving FAQ.)

And then, of course, keep track of what questions your users are actually asking frequently, and add them to the list. And keep track of the items in your FAQ that are not being selected frequently and remove them. Lists that get too long to scan stop working, so you need to keep your FAQ short.

By all means group questions in your FAQ, if you can do so using categories that clearly make immediate sense to your readers, but never more than one level deep. Don’t turn your FAQ into a TOC; that is not its function.

Keep the answers to your FAQ questions short, but link them as richly as possible to your overall content set so that people can get more information if they need it. A FAQ that acts as an entrypoint to the overall content set, as well as providing quick answers to frequent questions, is much more valuable than one that stands in isolation.

A good bottom up architecture offers multifaceted navigation that is integrated with the content (rather than standing apart from it). A FAQ provides a valuable facet along the lines of frequency. It is not, as some would have it, a stopgap for poor content organization, but a valuable element of an overall bottom-up information architecture.

Which makes me think that I should probably be adding an Every Page is Page One FAQ to this site. Hmmmmm. Stay tuned.

Series Navigation

<< Successful Patterns are the Best Guide to Information DesignYou can’t size topics for specific information needs >>