[Sigia-l] Collation of faq responses

[Richard Hill]

[Forwarded for Samantha Bailey because of as couple of HTML posts.  Dick Hill]

Hi,

About a week or so ago I asked folks to help me out with some issues around 
FAQs--the rest of this message is the responses I got. Thanks very much to 
everyone who contributed--there's a lot of valuable info here.

Samantha Bailey
<mailto:samantha at baileysorts.com>samantha at baileysorts.com | 
http://baileysorts.com



FAQ feedback from SIG-IA list
Original Question
Hi,

I'm working on a project to improve the FAQs we use on
our site and would really appreciate some alternate
perspectives.

1) Do you distinguish between FAQs and content
presented in a Q&A format on your site? If so, how?
Also, why?

--We currently are putting everything info an FAQ
format and I'm finding that is breaking down our
original model, which attempted to limit FAQs so as to
place pertinent information at our users' fingertips.
Our business partners, however, *love* presenting
content in a Q&A format and are quite resistant to
changing the content to a paragraph based style.

2) Do you use FAQs primarily to facilitate information
retrieval, for marketing, or for general
communication? In other words--are they structured to
meet a specific need, or more general?

3) How do you keep your FAQs from becoming
miscellaneous catch-alls?

Thanks very much for any feedback you can give; feel
free to reply either to the list or to me--I'll
compile and share with the list as a whole at the end.

Samantha Bailey
Wachovia Corporation

Response 1
Samantha,

While I'm not part of the comm team that actually produces FAQ docs, I have
worked with the team to put those docs into some databases.  They use a
simple rule for determing what goes into them: if an actual person has
actually asked the question (by email or by phone) and it's a question
likely to be asked again, they put it into an FAQ. Actually, they call them
QandA docs but it's the same thing.  It's not the primary method by any
means of organizing info, but is most useful for times when the need to
produce and publish a lot of new information quickly is great.  Much of this
info will eventually get moved into some kind of topical scheme.

Ralph Lord
System Analyst
Northrop Grumman Mission Systems
Centers for Disease Control and Prevention
770.234.6562

Response 2

Hello, Samantha:

What a great series of questions. I can address some of this.

I need to say that I am profoundly frustrated with FAQs and
disappointed with almost every FAQ I see. There are so many problems
with them. For one, I expect that most graphic and text designers
would tell you that to be readable, FAQs need to look more like good
Web page layout, and much less like some list produced on a
typewriter. Often, a hideous catchall.

My strategy (in the face of an insistent client) would be:

1. Suggest numerous FAQs, arranged like the overall architecture of
the site and located throughout the site. Even only one or two FAQs on
a page would be just fine. Long, long lists are preposterous. I'm
betting that some managers think, "The more the merrier."

2. Insist on honesty, transparency. These must be true FAQs, submitted
by real customers, and not just nice ideas about questions that people
might ask. That should whittle down the list. Ask that call center
personnel log questions for a year, as part of the process, for
example. What are other actual sources? Would each employee submit a
question or two each week that they have answered? Managers need to
think seriously about the costs of producing this and maintaining it.

3. Indicate that such questions must drive the (information) redesign
of the entire site, so that frequently needed information is available
in the best possible format. (Let's just assume for the moment that
good page design with different fonts, sizes, colors, type treatment
and page location is a better format.)

4. The format should change to, "Questions asked this month / year" -
and not a list of every question that was ever asked. Over time, the
answers most people need should be easy to find in Web pages, and also
via search. ("Best bets," for example.)

4. Remind the client that if they go down this road they are
eventually going to be providing much company information in two
different formats. There are financial and legal reasons to avoid
having to monitor, edit and change both versions in a completely
reliable way over the years.

5. Ask the FAQ Defenders if they have ever come across a book that
consists of long strings of questions and answers. Perhaps there is
one like this in the corporate library. If they have such a book, ask
if it works better for them than a normal text or trade book. Ask the
same question about periodicals they use. Why should their customers
get anything less than the carefully crafted structure found in the
WSJ, for example?


Sincerely,


David Austen

Response 3

  From: "Bollaert, Jodi" 
<<mailto:Jodi_Bollaert at compuware.com>Jodi_Bollaert at compuware.com
  To: "<mailto:'slbailey at yahoo.com'>'slbailey at yahoo.com'" 
<<mailto:slbailey at yahoo.com>slbailey at yahoo.com
  Subject: Re:  Question about FAQs
  Date: Tue, 28 Oct 2003 12:05:03 -0500

  Hi Samantha!

  Here is a link to an article I wrote awhile back
  that you may find helpful.


  Mind Your FAQs

<http://www-106.ibm.com/developerworks/library/us-faq/?dwzone=usability>http://www-106.ibm.com/developerworks/library/us-faq/?dwzone=usability

  (FYI...there is no Part 2.  IBM error.)

  I believe FAQs should be distinguished from other content presented in a 
Q & A format, otherwise they are not really FAQs.  By calling them out, you'll
  also save users time in sifting through the larger set of Q & As.  If it is
  a large set, I would advocate a search tool, as well as allowing users to
  browse the Q & As by category.  Presenting a long list of questions with
  links to the answers tends doesn't lend itself well to scanning and finding
  what's needed quickly.

  I think you prevent the FAQs from being catch-alls by getting management
  buy-in up-front that they should be based on an  analysis of available data,
  and reminding them of their agreement when they try to add new items.  (A
  signature in blood might help.)  Available data might come from people with
  sales responsibilities who are hearing potential customers' FAQs, or a
  customer support call center where call center reps are hearing from
  existing customers.

  Hope this is helpful!

Jodi

Response 4

  From: Karl Fast <<mailto:karl.fast at pobox.com>karl.fast at pobox.com
  To: <mailto:sigia-l at asis.org>sigia-l at asis.org
  Subject: Re: [Sigia-l] Question about FAQs
  Date: Tue, 28 Oct 2003 07:41:11 -0600

What follows is all personal opinion based experience as a user, not any 
empirical or observational experience as a designer. Caveat emptor.

  I have found two types of FAQs useful:

  1. The Brief FAQ

It's short. I can quickly skim it. It gives me a sense of common issues 
that I might run into. It's like a little test. If I pass, if I understand 
the FAQ, then I figure I'm doing real well.

  2. The Detailed FAQ

I love a detailed FAQ that summarizes a lot *more* information. I dislike 
FAQs that replace the real documentation. I may never need the real 
documentation, but I want to know it's there.

My favorite example is the FAQ for the VIM text editor. The FAQ is huge, 
but the documentation is huger (rhymes with luger?)

<http://vimdoc.sourceforge.net/cgi-bin/vimfaq2html3.pl>http://vimdoc.sourceforge.net/cgi-bin/vimfaq2html3.pl

There are at least three things to keep in mind when designing a FAQ:

  1. The FAQ is not a replacement for the real documentation.

It's merely an alternate representation of selected information.
The VIM documentation is enormous. The FAQ brings out the important bits 
and presents it in a different, more useful way, considering the task 
context of the user.

  2. The FAQ should answer real questions, not PR questions. This advice 
comes from the Cluetrain (book, pg. 71):

"There are two kinds of FAQs, I realized recently: 1) those that frame 
questions the company wants you to ask. Q: So how good ARE your products 
anyway? A: Very very VERY good!!!), and 2) those that acknowledge actual 
problems and provide solutions. The (1) variety is bulls**t PR, while (2) 
is truly useful."

  3. Quick answers are the essence of a FAQ, thus design is critical.

I loathe FAQs which separate each answer into a separate page. You spend 
all your time pogosticking between the index and each  individual entry. 
Such a design defeats the purpose of a FAQ: quick answers to common questions.

For a brief FAQ, one big page is much better. People will scroll.

For a detailed FAQ you can, maybe, divide the FAQ into chapter-like 
sections and create one page for each chapter. But hey, the VIM FAQ dumps 
it all on one page.

  All IMHO, but hopefully of some help.


  --karl

Response 5

----- Original Message -----
From: <<mailto:Mike.Steckel at sematech.org>Mike.Steckel at sematech.org
To: <<mailto:karl.fast at pobox.com>karl.fast at pobox.com; 
<<mailto:sigia-l at asis.org>sigia-l at asis.org
Sent: Tuesday, October 28, 2003 10:16 AM
Subject: RE: [Sigia-l] Question about FAQs


I very much agree with what Karl said below, and want to add something we 
do whenever possible that has worked out well. We have been trying to offer 
pieces of the FAQ to users at certain moments when they might have run into
a problem.

For instance, when someone gets 0 hits on a search, we give them the 
section from the FAQ that deals with search tips for expanding a search. 
Also when they get over 300 results, we provide a link to the piece of the 
FAQ that helps them narrow their search if they wish to use it.

This has been successful so far. We think of the FAQ as a single, rather 
long, document but try to link to pieces of it when we can tell a user 
might be looking at a screen they didn't expect to see.







Executive Director
American Society for Information Science and Technology
1320 Fenwick Lane, Suite 510
Silver Spring, MD  20910
FAX: (301) 495-0810
PHONE: (301) 495-0900

http://www.asis.org