The evolution of the web and the way in which we design for it has brought around all kinds of patterns, standards and best practices. Sites have a relatively uniform information structure: We always start with a home page (also known as the front page or index page) as the default page, and we’ll have common pages such as a contact page, an about page, and so forth.

A lot of sites will have a web page dedicated to problem-solving, giving answers to frequently asked questions (FAQ). In a time where interactivity between the site operator and site visitors is at the forefront, and a time where site analytics allow us to know more about user behavior than ever before — has the FAQ page, been left behind?

Listing out questions you think someone is likely to have, and then providing the listed questions with canned answers sure seems like an old and inefficient way of going about problem-solving and helping users.

Ideally, we would like to address every user problem with a personalized, human response. However, for sites that deal with high volumes of traffic, this can be a pretty unfeasible (and rather expensive) approach.

Using an FAQ page to filter out common questions and problems before escalating to personal interaction seems like a good intermediate step to take. But are we really taking advantage of what an FAQ page can do for us, or are we using it as a bandage for a problem we could solve?

Where Did the FAQ Page Come From?

We can look at the FAQ page as one of the early and rudimentary conceptualizations of user-centered websites. The FAQ page was the webmaster’s (that’s what they called themselves back in the day) only way to address the needs of the masses. Before Twitter, Facebook, or even contact forms, users who had questions about a site or a piece of information were simply and sadly out of luck.

The only thing that stood between them and giving up was a list of questions sites always seemed to have; and maybe, just maybe, their question would be included in the list.

In the days of the early web, the FAQ page was a powerful tool for keeping site visitors happy. And while the web has certainly evolved since then, for the most part, the FAQ page has not.

Solving Problems vs. Providing Answers

Too often, the FAQ page is constructed in a lazy fashion. Clients don’t want to generate content for it and web designers don’t want to waste precious time on it. FAQ pages are an afterthought. Many use it as site content filler; other sites have it, mine should have one too.

We would love to just get rid of the FAQ page, but we still need it, don’t we? If the FAQ is left out, we will certainly regret it when emails with simple and basic questions such as What is this RSS feed thingie that you keep telling me to subscribe to? start coming in.

It can be impossible to predict all of the problems users might have with your shiny new site, and when they start having these problems, the FAQ page is the first thing they are going to look for. As a web designer or site owner, we need to be ready to listen to these user problems — and not just listen, but also act on them. An even better approach: How can we resolve users problems before they experience it?

A well-constructed FAQ page relies on user input from the beginning. The great thing about modern technology is that we don’t need to rely on users having a huge problem before we can solve it. Analytics apps and data-driven design decisions such as split testing will help a web designer realize that their users are taking the wrong path to a product page or not responding to a call to action.

Are your users spending too much time on your site bumbling around for the information they are seeking? Do they take the wrong steps to get to a product page? Or are they landing in the wrong areas and getting frustrated with your site and leaving? All of this is information that we could use to build a helpful FAQ page — but it’s not the only thing we should do.

An FAQ page provides answers, not solutions. And while answering user questions is the right thing to do, an even better thing to do is take this information and build a solution so that the next user never has that question to begin with.

When you address a design problem or bug using your FAQ, I call this FAQ bandaging. Instead of solving design issues, you make your users do the work by giving them help documentation. This is why old-school GUIs have 1,000-page user manuals — let’s put the burden of making the product work properly on the users, not us.

If people aren’t able to figure out how something works, don’t just give them step-by-step instructions on your FAQ page. Make design changes that fix the issue and provide inline help text. If users can’t find your contact web form, think about ways to highlight it better rather than creating an FAQ entry on how to find the web form. If users continually see old content because of your buggy Ajax script, don’t create an FAQ that tells them to refresh their browser when this happens, fix your buggy Ajax script or replace it with another method.

The Problem of FAQ Bandaging

Providing an answer instead of building a solution can quickly become the default thing to do because the alternative — which is to rework and iterate on your design — is costly and hard.

Sooner or later, though, your FAQ is going to get pretty bulky because of all these unresolved issues. Every web designer knows that a good site requires regular tweaking and modification in order to continue serving its customers the best way possible.

The goal, then, is to have the shortest FAQ page possible. If it doesn’t have a lot of questions, the design is intuitive and user-friendly. A site with an FAQ page spanning multiple pages, on the other hand, needs to evaluate their design.

Action Is Better Than Reaction

It’s unreasonable to think that site owners would be able to solve every problem any of their users might happen to have on their website. However, it is within reason to believe that a high-traffic site could build a complex environment in such an efficient way that it would be able to solve its users’ problems on a personalized level. The trick is to know as much as you can about the users that come to your site.

We can safely assume certain instincts and behaviors that dictate the way our users will interact with our site, allowing us to make solid design decisions before a site is even live. It is the knowledge of fundamental user interaction principles, along with persistent monitoring and testing of our website, that allows us to run a skinny FAQ page.

Answering the Right Questions: The Importance of User Feedback

So you promise to look at your FAQ and see what solutions you can build in order to eliminate questions to begin with, right? Good! I am really proud of you; we all are.

But your work isn’t done: user feedback remains important. Naturally, the bigger your site gets, the more types of problems you’re going to have. Things that weren’t problems will be problems when your site is visited by many different types of people. Whether you decide to go FAQ-free or not, it is still very important that you encourage your users to submit questions to you if they have them.

Don’t you hate it when you walk into a retail store and immediately get asked by a super-enthusiastic employee if you need help finding something? Like your plan for the entire afternoon was actually to walk into a random department store with no pre-determined thought on what you might need there. It kind of bugs me when people ask if I need help when I don’t need it. However, it bugs me even more when I do need help and no one is around to help me.

Websites that don’t allow users to submit feedback of some sort tend to be the same way. Make sure that your website incorporates an easy way for users to get in touch with someone at any point of their experience. Most often, this can be a simple link to a contact web form or an email address. If you anticipate (or want) more user contact, even a small web form on the footer or sidebar of your site template could be a good way to go. Other ways are keeping up with social networks and responding to tweets and Facebook comments, as well as creating a culture where site users feel comfortable contacting you without feeling like they’re an annoyance.

Pulling It All Together

The main idea to take away here is that your FAQ page should never be an afterthought. It should be functional. It shouldn’t be something you tack on at the last minute. If you don’t need an FAQ, don’t have one.

Another thing you should keep in mind is that you shouldn’t use your FAQ page as a crutch to poor design, interaction, and usability. Don’t use FAQs to bandage failures in a web design. If people are constantly having trouble with a particular aspect of your website, fix it. Don’t bandage it with an FAQ entry.

Allowing user feedback to shape your web design is a fantastic way to build a user-centered and responsive site. Ask users what’s wrong, iterate, repeat. Give users the opportunity to share their ideas and suggestions with you.

It is important to take user questions and suggestions seriously. Thank your users for providing you with their input because they certainly aren’t forced to do so. More importantly, act on what they have to say if many other people are also saying it. Nothing says Thank you more to a user than actually solving their problem and making them feel they have contributed to the improvement of the site.

The FAQ page has a tendency to be overlooked, but it can be a very powerful tool under the right circumstances.

What has your experience been with the FAQ page? Are you guilty of overlooking this area or have you built some creative solutions to user problems?

Related Content

• Basic Tips for Designing a Quote Request Web Form
• Important Features All Blogs Should Really Have
• How Fun is Your Website?
• Related categories: User Interface and Web Design

Jason Gross is a freelance web designer focused on creating clean and user friendly websites. Jason currently lives in Indiana and can be found on Twitter as @JasonAGross or on the web at his personal blog and portfolio.