Are FAQs obsolete?

[jct821]

During a recent meeting about content strategy, a question was raised:
Are FAQs obsolete?

Some argued that yes, they're useless; FAQ content would of better
service to the user if reworked and placed more strategically on site
pages devoted to the FAQ subject matter.

Others felt that FAQs have been around so long, users have come to
expect them; FAQs are a "life preserver" in case of content crisis.

Has the FAQ question come up in your work? I've spent a little time
researching this topic, but I've not really come across anything on
point as of yet.

[Carolyn Wood]

For me, it depends on the type of site, the amount of info, the type
of info. For example, if the site was Pottery Barn, it might need an
FAQ-type of section within the ordering and shipping section or how to
you return merchandise, or within the how to choose curtain sizes
section. But, you may or may not call it FAQ.If it was a web design
company, usually you wouldn't need FAQs; it seems to me that the info
should just be placed in other categories. If, on the other hand, it
was a company that custom contract manufactured dietary supplements,
there's a bunch of information that would immediately answer some
broad questions that people had that they'd want right away without
working their way through a lot of other information. They'd be
searching for the right company, and an FAQ could zero in on the top
questions that people have when comparing companies. But, some of that
info should be also be within the sections of the site that apply
specifically to that same information. So, I don't see any reason for
a hard and fast rule. And, sometimes, what was more often called FAQ
in the past may now be called Help.
So, I'd argue, "It depends." :)

[Rahel Bailie]

I thought that FAQ pages were obsolete, but after being asked to write a
piece about creating good FAQ pages and researching it, I came up with the
following article:
http://www.thecontentwrangler.com/article/how_to_create_a_faq_page_your_cust
omers_will_love/

It's interesting to note that I had several requests to create specialized
versions of the article (e-learning, project management, support teams, etc)
so I can definitely say they're not dead.

My own POV is that if there's a problem with the software/site, it should be
fixed, not documented in a FAQ. There are still questions that are bound to
be asked, and depending on the situation, one could argue that there is a
need for a section (maybe called FAQ, maybe not) where those questions get
answered.

Rahel

[josh teixeira]

first time caller, long-time listener:

this info must be contextual such that the user can inform their
decision making process appropriately. however, it should also be
compiled in a globally-accessible repository.

coming from a technical writing background, i am loving the evolution
of "help text," but we are not at the point of killing the "help" or
"FAQ" link.

best.

j

Sent from my iPhone

[rsgr...@gmail.com]

I'd be on the first side of the discussion: I HATE FAQs as a user because they never answer MY questions.

I'll one big "unless." UNLESS they really ARE the frequently asked questions of your site (backed up and followed up with monitoring) AND you're also addressing the issues raised in the monitoring.

A FAQ really shouldn't be the only way a given piece of content is conveyed on your site: It should hold the same rank as "sitemap."

Stephen

Sent via BlackBerry by AT&T

-----Original Message-----
From: jct821 <junct...@gmail.com>

Date: Mon, 8 Jun 2009 19:11:35
To: Content Strategy<content...@googlegroups.com>
Subject: Are FAQs obsolete?

[richardingram]

I think if any questions are truly asked as 'frequently' as suggested
by an FAQ page they really should be woven into the fabric of the web
site's content.

That said, I'm all in favour of pages that answer direct questions
relating to a specific task (say, advice on a company's returns
policy).

Richard

[Ginny Redish]

I wonder if the question came up because the person raising it attended the Rosenfeld Media webinar I gave recently on Content as Conversation:  http://rosenfeldmedia.com/webinars/content-as-conversation/

In the webinar, I showed pages on the same topic from two different sites -- one full of text with no headings, the other presented as questions and answers.  The page with Q&A is not in the architecture as an FAQ page.  It is THE page on the topic. 

When I show pages like these in my workshops and ask people which they would be more willing to use, almost 100% vote for the page that is in Q&A.

Think about it:  Why are FAQs so popular?  Isn't it because people come to web sites with questions?  

I'm not suggesting making your entire web site one huge FAQ – no one would be able to find anything.

I am suggesting that within a specific topic, on a specific web page, you should plan and write that page by thinking about the questions your site visitors have about your topic. 

Consider the questions to be your site visitors' turns in the conversation. The answers are your turn.

In the webinar, I suggested that you look at each FAQ page in your site and ask yourself if it exists because the main page on the topic is not as clear as it could be or does not contain the content that really matters to your site visitors.

I agree with others in this thread that situations exist on web sites where an FAQ page as an addition to other pages on the topic might be needed.  But, in many cases, FAQ pages exist unnecessarily because the first writing on the topic doesn't satisfy the conversation the site visitor brings to the site.

For more on content as conversation, you can download one of my recent talks or listen to podcasts in which I talk about the topic.  Links to those are on the home page of my web site at www.redish.net

Content as conversation is also the theme of my book on web content:  Letting Go of the Words -- Writing Web Content that Works.

http://www.redish.net/content/books/lettinggoofthewords.html

You can download two chapters, including Chapter 1 where I introduce the idea of content as conversation and give an example changing a page in traditional style into a Q&A page -- not called FAQ, just giving the content as Q&A:  http://redish.net/writingfortheweb/index.php/sample-chapters/ 

Best,

Ginny Redish

Janice (Ginny) Redish, Ph.D.

President

Redish & Associates, Inc.

6820 Winterberry Lane

Bethesda, MD 20817

301 229 3039

www.redish.net

Visit the web site of my book at www.redish.net/writingfortheweb

[Carolyn Wood]

Is it my imagination, or did we all just write our own versions of the
same answer? ;-)

[Richard Sheffield]

I also hate FAQ pages for several reasons:

 

1 - They are rarely "Frequently" asked questions. These pages have come to replace the idea of online Help in many sites. I myself have been asked many times to write FAQs for brand new applications. No questions have EVER been asked about these apps :) We are just making up questions about parts of the interface that are complex or complicated.

Solution - Fix clunky interfaces and label Help content as Help content. We do have two places on the site with real FAQs that we get from our Customer Support team, it's a short list and easily scanned and frequently updated.

 

2 - FAQ pages are awful for users in search results. If a user searches your site for help and gets an FAQ page as a result, the likely hood of them finding the answer to their specific question on this long scrolling page of content is almost nil. We see visitors bouncing off FAQ pages pretty quickly.

One possible solution - We broke up all our FAQ content into distinct chunks and provided search boxes all over the site that just search context specific Support content. Now the search results are list of individual Q&A pairs, not all the Q&A pairs scrolling down one long page.

 

I try to reduce the need for FAQs by improving on-page content around complex functions.

 

Hope this helps :)

Richard Sheffield

 

[R. Stephen Gracey]

I feel the same way about "Quick Picks." Please, let's just give users good navigation...

Stephen

--
R. Stephen Gracey
rsgracey.com

[Rahel Bailie]

Frankly, if an organization is still answering the same questions today as last year, customers will likely assume that the problems the product or service still has last year’s problems, and that’s an entirely other set of customer service problems. But let’s assume that the questions being asked are not due to poor product design or bad service practices. Let’s assume these are questions that fall within the normal range of experience of people who are generally satisfied but need more information, either while considering the product or service, during setup, or as customers. It could be a site for developers who have questions about the newest upgrade, or it could be a consumer site where they ask about certain policies.

 

If there is a customer service department, support center, or call center, what simple questions do they regularly answer? What questions get asked through the feedback form Can the FAQs be dynamically generated – in other words, the top “x” questions always come to the top? These are all valuable sources of information, both in harvesting questions and in providing answers. If a few people need an answer, you can assume that more people need the same answer. And no marketing speak in the answers – people are there to get answers, not to get a pitch. (Remember, they’ll be annoyed anyhow, looking for a fix to something broken.) Look at how MySpace does their FAQ: http://www.myspace.com/index.cfm?fuseaction=misc.faq – Top 6 questions (I can’t tell if they’re dynamically generated, but it would be cool if it were.)

 

It may be hard to get past the presupposition that a FAQ page is a dust-covered museum of questions from the late 1990s. Just as FAQs change, so should approaches to FAQ presentation; what works today may be obsolete in a year or two. Today’s tips: 

·         Use a software utility to extract the top questions and list them as a sidebar.

·         Don’t call the FAQ a FAQ. If you have lots of questions, consider a more useful name that tells customers what the questions are about. If your questions supplement your support, call it a Support Center, as Symantec does. Or, if your questions are all about how to set up an account, call your page Getting Started.

·         Make the FAQs printable. Particularly when an instruction calls for a system reboot, it’s handy for the customer to be able to refer to printed instructions and to return to the URL once they are back online.

·         Refer to the FAQ page from elsewhere. For example, if you have a FAQ section on Return Policies that limits returns on certain clothing types, you can link to it from those types of clothing. This indicates to customers that you respect their time enough to point out their obligations before they buy.

·         Include a link so that customers can ask questions that don’t yet exist in your FAQ repertoire.

 

My $0.02 (Canadian funds) on the topic.

[Keri Maijala]

We're trying to phase out FAQs. We feel our help documentation should be robust enough to answer any questions a user might have. We still get requests to develop FAQs, and we pick our battles at the project level.

Keri

[Dan Haley]

I work in health care--as it appears you do as well, jct821--and still
find FAQ pages very helpful to users. The large site I manage has a
lot of specific info about medical procedures, for example, and I'm
told by clinical staff that patients typically have a small handful of
the same questions.

Take a web page about MRI. I can post robust, best practices content
about how MRI works, what it can show doctors, what the process is
like for patients, an image slideshow tour, etc. I can also post a
quick 'n' dirty FAQ page that answers the small handful of patient
questions: "Will I feel claustrophobic?"; "Is it loud?"; "Does it take
a long time?"; "Can I have an MRI if I'm pregnant?"

So yeah, like others have said above, well-designed FAQ pages are
still great in some contexts--as a supplement to other good content.

[Brian E. Kirby]

I'm also finding this topic to be of particular interest, since I'm currently engaged in freshening up an internal support site for (fittingly) our company CMS, and the FAQ section actually comprises the majority of the site's content. Since these were initially written by other folks in my department based on their own experiences learning the CMS, the docs were more "possibly useful" than "frequently asked."

Now that the site has been live for several months, we're about to go through the web analytics and see just which of these questions people have shown interest in and "promoting" them with more prominent placement. I'll also be pushing to improve the signal:noise ratio by eventually removing those questions which are showing very little traffic.

One of the reasons I'd give for keeping FAQs--and I have absolutely no evidence to back this up--is that it's a label whose purpose is largely known by its intended audience, much like "Search" and "Sitemap." While a user might expect to get questions answered whether or not they're in the FAQ or Help sections, the *type* of questions may vary signficantly. For instance, they might go to a FAQ for "Do you deliver to military bases?" but navigate to Help to learn "Why doesn't this POS work?"

-Brian

PS - Keri, I assume that by "robust" you mean "online, modular and concise?" I've made some absolutely lovely user manuals that explained processes in step-by-step detail. They came in quite handy when I'd get calls about those steps, since I could just read aloud from them over the phone.