Why FAQs provide a poor user experience
If your client thinks they need a Frequently Asked Questions page on their website, there’s most likely a problem with their website structure or their content.
FAQs are like the bandaid on a slashed carotid artery. They’re trying to patch a deeper issue but offer no help at all to the gushing wound.
Users should be able to achieve their goal on a website without having to resort to an FAQ page to get the information they need.
It’s unlikely a user is on your client’s website for fun. They’re there because they have to do something (a task-based visit) or find something out (an information-based visit).
By better understanding what your client’s user needs are, you’ll have a clearer idea of how to best serve them and eliminate the need for an FAQ page.
The UK’s Government Digital Service agrees. They don’t recommend FAQs, no longer use them. They advocate for others to ditch them as well.
Why companies love FAQs
Organisations love creating FAQs because they are easy to write in their simple question-answer formula.
FAQs become a lazy catch-all for odd bits of information.
Not sure where this bit of info goes? Let’s put in an FAQ.
Thought of a question one user out of 10,000 might ask one day? Put it in the FAQs.
Had one enquiry about a topic via email that’s specific only to that one person? We took the time to answer them, so let’s add our answer to the FAQ page. Just in case.
Some organisations have trained their users to find their content via the FAQ section. It will be more challenging to convince these organisations to let go of their FAQ pages.
Examples of why FAQs provide a poor user experience
A quick poke around the web and it’s not hard to find examples of FAQs providing a poor user experience.
FAQs that are not even questions
Some organisations write sentences instead of questions, expecting the user to infer what the question is.
Immigration South Australia has a large FAQ section. This is just one part of it. They mix questions and sentences in their FAQ lists.
The not-so-FAQ FAQ
My most-hated FAQ is the FAQ that poses as a thinly veiled vehicle for self-promotion. You know the ones that read something like ‘How can I tell all my friends about your exceptional product?’
I’ll tell you exactly how many people asked that question. Zero.
If your client has these kinds of FAQs, get rid of them.
Here’s an example of a not-so-FAQ FAQ from Urban Home.
The problem with FAQs
One of the reasons why FAQs provide a poor user experience is that they quickly grow from a manageable handful to 15 to 30 to 63.
Before you know it, the dumping ground is a disorganised mess where a user must sift through dozens of FAQs that are of no relevance to their question.
Or the questions are so specific that your user can’t identify their problem among the FAQs.
This, apparently, is a frequently asked question. It’s on the ATO website.
This is an example of when FAQs become so trivial and specific to a single person they don’t cover important information relevant to most site visitors.
Heading length and FAQs
Another problem with FAQs is that FAQ headings are often longer than standard headings.
For example:
How do I get the stun feature on my Zombie Zapper 2.0 to work?
When users scan your page, they look at the first few words of headings.
So, if you have ‘How do I get the …’ as your first few words, your users are missing the key words about the stun feature on their Zombie Zapper 2.0 when they scan your content.
Instead, a heading like this works better:
Using the stun feature on your Zombie Zapper 2.0
Here’s another example of a dog’s breakfast of FAQs, courtesy of our federal government’s FAQs on the Australian Parliament House website.
FAQs on mobile phone screens
These headings are not optimised for scanning. Some of their FAQs are far too long and wrap across 2 or more lines on a mobile phone.
This is what the same FAQ list looks like a mobile phone screen.
It’s not a pleasant user experience.
Action-oriented headings
Starting headings with a verb makes them action-oriented and more engaging. Users are more likely to see their key words as they scan your page.
Short headings also work better on mobiles.
If this wasn’t an FAQ page, the headings would be more like:
- Contact your local member
- Learn what work the House does
- Get your petition before the House
- House sitting times
- Standing and sessional orders
FAQ alternatives
If FAQs are so bad, what can we do instead of creating an FAQ page?
We can make sure the website’s information architecture (IA), is giving users the right cues to help them find the information they need. (A website’s IA is the labels we assign to menu topics.)
You can move FAQs onto the relevant web pages.
To make sure you’re only moving relevant and appropriate content, start this process with an FAQ audit.
Audit the FAQs
Gather a list of all the FAQs. My preference is to do this in a spreadsheet and identify:
- the user need
- the topic it most relates to
- location of where the info belongs on the website
- if it’s duplicated or already answered in the content
- if it’s a true frequently asked question or if you can cull it
Move FAQ content into the relevant web pages
Map the FAQ content you’ll keep to the relevant page on the website.
Check if the page already addresses that question. If it does, there’s no need to add the FAQ content.
The only reason to include an FAQ format on this page is to address the SEO benefits through keyword targeting. We’ll cover this in more detail further on.
Test the IA
When a client’s site is undergoing a redevelopment, it’s the perfect time to assess the need for their existing FAQ page.
The new IA should capture the most likely place for the FAQs.
I use Treejack by Optimal Workshop to test IAs. Upload your menu headings, set user tasks, recruit users to complete those tasks. You’ll soon figure what’s working and what’s not working well with your menu design.
I’ve over-simplified IA testing, but that’s a whole new topic in itself.
*Adds IA testing to list of blog posts to write*
Set strict rules around the creation of new FAQs
Just because someone asked a question once back in 2017, it doesn’t build a business case for the website to include it.
So, what does?
Call centre staff, especially if they log call data, are a brilliant source of data. Sales staff also know the main objections and questions potential customers have about a product or service.
There are no definitive criteria for FAQ governance, you can set the criteria with your client. Consider if frequently asked questions:
- are true FAQs
- have evidence to back up that they are an FAQ
- are not self-promotion
- have already been answered in the page content
- highlight a flaw in the site’s IA
- need further user testing
- are keywords that need to be included for SEO purposes
When FAQs work well
In most situations, if you or your client thinks you need an FAQ page, the content or menu structure isn’t doing its job well.
I hate blanket rules — that’s why I say ‘most’ situations.
There are a few situations where FAQs can work well. For example, they can work well:
- When you have a transaction-based eCommerce site and need to cover shipping and returns information.
- For an event or conference that has a lot of details about the logistics of the event.
- For a sales page where you can use the FAQ format to counter objections. You also want to keep the user on the sales page, rather than sending them elsewhere to find the information. You might lose their attention during the sales process if you send them elsewhere to find the information they need.
But for everything else, let’s ditch the FAQ page and incorporate the information into the relevant place on the website.
FAQs and their impact on SEO
With the rise of voice search and the valuable real estate of search engine results pages up for grabs with rich snippets, questions and their answers have become an important component to include in your web content.
I’m not saying no to FAQs full stop. I’m saying no to FAQ pages and FAQs as a main menu heading (unless you’re ultra-specific – like the ‘Shipping FAQs’ for an eCommerce store).
But ditch the standalone FAQ page.
One of the last major Google algorithm updates was about relevance.
An FAQ page with loads of questions and answers across a broad range of topics will most likely not satisfy Google’s thirst for relevance.
You’re better off building the credibility, authority and relevance of a single page. Add the FAQ keyword to the core, pillar page. Don’t add the keyword to an FAQ page where you’ll be sending mixed signals and cues to search engines and diluting the value of the keyword for your site.
And when was the last time you remember stumbling across an FAQ page via a search engine?
The FAQ challenge
Is there an FAQ page or *gulp* an entire FAQ section on your client’s website you could disassemble and disseminate the information to specific pages in the right context?
