Almost every website has one and yet whenever I see an FAQ, my first reaction isn’t reassurance. It’s suspicion..
Sometimes it’s tucked quietly into the footer. Sometimes it appears halfway down a page in a set of expandable panels. Occasionally it’s given its own proud page, titled FAQ — Frequently Asked Questions.
An FAQ isn’t just a helpful collection of answers. Very often, it’s evidence that something else on the site isn’t working as well as it should.
An FAQ Is a Symptom, Not a Solution
In theory, an FAQ exists to support users. In practice, it often exists to patch over gaps.
When people repeatedly ask the same questions, it’s rarely because they enjoy asking them. More often, it’s because the information they need is missing, hard to find, or written in a way that reflects the organisation’s internal language rather than the user’s perspective.
If one person asks a question, it’s probably an edge case. If lots of people ask the same question, it isn’t. At that point, you are no longer dealing with curiosity or exceptional circumstances, you are looking at a structural failure in your content.
An FAQ doesn’t fix any of that. It simply relocates the problem. The confusion still exists; it’s just been gathered up and given a label.
Designing for Confusion Instead of Preventing It
FAQs assume that confusion is inevitable. They build an experience around the idea that users will get stuck, go searching for help, discover the FAQ, scan down a list of questions, try to identify the one that sounds closest to their problem, and then return to what they were originally trying to do.
That is a surprisingly long and fragile journey.
Well designed websites aim to remove uncertainty before it appears. They anticipate where people might hesitate, where they might wonder “what happens next?” or “is this for me?”, and they answer those questions in context.
If your pricing page needs an FAQ to explain the pricing, the page itself isn’t doing its job. If onboarding requires an FAQ to clarify the basics, then the onboarding flow is incomplete. And if your product constantly needs explaining, that explanation probably belongs exactly where the confusion arises, not hidden behind a separate help mechanism.
Who Are FAQs Really Written For?
Another uncomfortable truth about many FAQs is that they are not written for users at all.
They are often defensive in tone, framed around limitations, exclusions, and edge cases. They read like pre-emptive responses to support tickets or legal concerns rather than genuine attempts to guide someone forward.
The unspoken message becomes: the answer was there, you just didn’t read it.
But users don’t arrive on a website hoping to study a Q&A document. They arrive with intent. They want to understand, decide, or act and anything that slows that down is friction, no matter how well intentioned it appears.
When an FAQ Can Be Useful
This doesn’t mean FAQs are always wrong. There are situations where they make sense.
Some products genuinely serve multiple audiences with very different expectations. Some services involve edge cases that would overwhelm the main narrative if handled inline. Sometimes you are responding to real, observed questions that only emerge after a site has been in use for a while.
Even then, the best FAQs are not static. They change, shrink, and often disappear as their answers are folded back into the main content, improving it for everyone.
Seen this way, an FAQ is scaffolding. It supports the structure while it’s still being refined. It is not meant to be part of the finished building.
A Better Question to Ask
Instead of asking whether your site needs an FAQ, it’s more useful to ask why people are confused at all.
Every question in an FAQ is a signal. It points to unclear language, missing context, or a break in the flow of information. Treating those questions as design feedback rather than as content to be isolated leads to better outcomes.
Fewer Questions, Better Experiences
The most flattering feedback a website can receive is not that its FAQ was helpful.
It’s that everything felt obvious.
Clarity beats completeness. Thoughtful structure beats defensive explanation. And sometimes, the most user-friendly FAQ is the one you never publish — because you never needed it in the first place.
