The frequently asked questions (FAQ) format seems like a fantastic idea on the surface. A single webpage that answers the questions most asked by the people using your service? No need to keep sending emails with the same answers?

There are plenty of warnings about FAQ pages from top content strategists and strong arguments against the FAQ format. This blog explores 4 big problems with the FAQ format in government. For those unconvinced, or with no choice, there are some pointers at the end on how to risk-manage FAQ pages.

Catch-all answers don’t meet diverse needs

The most obvious difficulty with an FAQ page is being able to identify the right questions. Government can struggle to identify the real problems people encounter when using its services.

Your team could do solid user research to build a service that meets people’s needs. But if this research doesn’t continue after the service is live, you may never discover the real problems. The only feedback you might see are complaints on social media or those raised by call centre staff.

A larger issue is that people who interact with government often have very complex needs. We cannot respond to all these needs with a single sentence or paragraph. People are frustrated by content that implies there is a single simple answer when there isn’t one.

Solve problems rather than explaining workarounds

People shouldn’t have to ask the question in the first place. Work to fix problems and provide the right information in the right place. This is better than forcing people to go to an FAQ page elsewhere on the site to find out what to do.

For the problems you can’t fix, always provide help in context. This means explaining the solution to the problem in the place the person experiences it.

Sometimes people get blocked by hard limitations about who can use the service. This might be due to policy and legislation. You can make these limitations clearer before people use the service. For example, there is guidance in the Style Manual on explaining who a form is for and what those people need.

FAQ pages are slower to read than regular pages

The FAQ format has structural problems that make information hard to read.

The usual format of using a question as a heading slows people down by pushing keywords to the end. People need to read whole headings to find the right question.

This format also slows people down by forcing them to search the text below the heading for the answer. It’s more helpful to use a heading to give an answer, or at least a clear statement. You can then use the paragraph below to provide more explanation if people actually need it.

You might think the FAQ format would suit voice search and zero-click searches more than plain pages. But there’s no direct connection. Even if you mark up your content with FAQPage schema, it won’t necessarily display in search like this. Search engines learn based on how people interact with everyone’s content. The way you tell them to use your content has a less direct effect.

Maintaining FAQ pages is hard

Even teams with good workflow can struggle to keep FAQ pages current. When we create a second (or even a third) source to ‘fix’ a problem with content, it creates content debt. That increases the risk we’ll tell people the wrong thing.

The risk of content debt and mistakes grows if different teams own the FAQ page and the content. Or if the subject of the content is a time-critical issue, such as coronavirus.

Then there is the risk of outside pressure to publish what an agency wants, not what people need. The worst type of FAQ page is the list of Dorothy Dixers. These are ‘questions’ intended only to promote something, not explain it.

The safest way to avoid out-of-date and irrelevant content is not to publish an FAQ page in the first place. Address the problem in the place where it occurs instead.

Risk-managing FAQ pages

So, you have no choice: you must publish an FAQ page. Here are some basic pointers to help you risk-manage FAQ pages:

• Review governance so all content has clear owners and the team can respond to feedback quickly.
• Learn about people’s needs, and group questions by activities so it’s easier for them to find what they need.
• Think about barriers. If you are in any doubt, verify that the answer will work for the range of people who will use it.
• Include meaningful link text that takes people straight to where they can use the answer.
• Answer the question in headings and frontload keywords.
• Mark up the content with FAQPage schema.
• Write ‘FAQ page’, never FAQs or FAQ’s (FAQ is a plural initialism).
• Set goals to help measure how the FAQ page performs.