Alligator Design
Notes
Propose a project

An FAQ is a list of problems you did not fix

Every question on a page of frequently asked questions is a problem somewhere else on the site. The page explains it. It rarely fixes it.

Geert Valère AllegaertOctober 2026

FAQs are a way to show you’ve thought about what your users should [know] but haven’t thought about your users.

James Hupp, quoted by the Government Digital Service, 2013

Most websites I have reviewed in my career had one: a page headed Frequently asked questions, somewhere near the bottom of the menu, with twenty or forty questions on it. Some were questions nobody had ever asked. Many were questions a better page would never have raised.

Organisations like FAQs. They are quick to write, easy to add to, and they feel helpful. Visitors are less keen. They came to do something, and the FAQ asks them to read a list of other people’s problems first, in the hope that theirs is on it.

Invented for the people answering

The FAQ is older than the web, and its origin explains a lot. Between 1982 and 1985 Eugene Miya of NASA coined the abbreviation on the SPACE mailing list. Newcomers were supposed to read the archive before they posted. Most did not, and asked questions that had already been answered. Giving the same answers again and again became tedious, so the regulars wrote them down once and posted the list at intervals. Usenet newsgroups took up the habit, and from there it came to the web.

So the FAQ was never designed for the person asking. It was designed to spare the people who were tired of answering. That purpose survived the move to the web intact. A company FAQ still protects the company: from the same email arriving fifty times, from the phone ringing, and, in my experience, from the legal department, which likes a place where every condition has been written down somewhere.

Why it reads badly

In 2013 the team building GOV.UK published why it does not use them. Sarah Richards gave three reasons. They are slow: a question as a heading puts the important words at the end, so a reader scanning the page gets nothing from it at a glance. They duplicate: the answer usually exists elsewhere on the site as well, and in search “you will end up with duplicate results competing for attention”. And they are the wrong tone for a service that has to speak plainly to everyone.

There is a fourth reason, and it is the one that matters to a designer. A question gets into the FAQ because somebody could not find the answer where they were. The form did not say which documents to attach. The price page did not mention delivery. The login screen did not say what to do with a forgotten username. Each of those is a fault on a specific page, and the FAQ is where the fault is written down and left.

Putting the answers back

The cure is not to delete the FAQ in an afternoon. It is to take each question back to the place it came from.

What to do with the questions you have

  • Find where each question starts. Most come from one page or one step. Offer the answer there, next to the thing it explains.
  • Change the page if the question is about the page. If people ask how to find their order number, the order confirmation should show it larger, not the FAQ explain where it is.
  • Write headings as statements. “Delivery takes three working days” is read in a second. “How long does delivery take?” has to be read to the end.
  • Keep conditions with the action they apply to. The cancellation terms belong next to the booking button, not on a page nobody opens until it is too late.
  • Keep only questions people really asked. If a list survives, every entry on it should be one you have received, and it should get shorter every year.

A shrinking FAQ is a good sign. It means the answers have gone where the questions start.

Read the originals