|
Jonathan Price
President, The Communication Circle, LLC
http://www.theprices.com
On the Web, people prefer a conversation to a lecture. And
traditional Help, even when it is mounted on a Web site,
energized with Dynamic HTML and JavaScript, linked to
embedded customer assistance, and delivered as active server
pages—well even then, Help seems like a lecture. But a set
of Frequently Asked Questions, even when done poorly, seems
like a conversation.
When I started writing for the Web, I hated FAQs because the
authors ignored so much that technical writers had learned
in many years of developing manuals, Help systems, and, most
exciting, CD-ROMs. The FAQs did everything wrong, but they
got attention. People demanded FAQs. How come?
Think of the origin. FAQs were invented by the moderators of
those all-text discussion lists that sprang up back when the
Internet had not even imagined a World Wide Web. The
moderators got angry at having to answer the same question
over and over. So to avoid having to keep sending out
individual emails over and over, the moderators invented the
list of Frequently Asked Questions with answers.
This laborsaving device, the FAQ, appealed to participants
because here was the head of the whole list talking to them,
answering their questions. In effect, an FAQ offers a
freeze-dried conversation.
Now on the Web, people see that despite the coldness of the
computer, the stupidity of the software, and the slowness of
their connections, hey, some human contact is possible. New
people, new points of view, new rants. People do not just
want information on the Web; they want a sense that they are
talking to another human being. The FAQ gives them that
feeling.
Instead of fighting the convention of the FAQ, I think we
ought to give in to the popular demand for this odd,
democratic, and chatty genre and adopt the FAQ. Then, I
suggest we also bring along some of the tactics we have
developed in technical communication to improve the FAQ.
Write the questions in the persona of the guest
As we have seen when writing troubleshooting sections,
people have a hard time recognizing their own problem in our
prose. So we have switched from phrases like "Connection
Failure" to "I Can't Seem to Connect to the Internet." Take
that "I" one step farther and turn the problem statement
into a question. "How Can I Connect to the Internet?"
Change the perspective to increase the illusion of a
conversation. Too many questions are self-centered,
reflecting the marketing department's desire to communicate
the latest features. "What is Splendorama?" Not a question
that many of us would ask. We must rethink existing
questions to reflect what users might really be asking in
their own terms.
Include more sections of troubleshooting
Many FAQs shy away from problems, perhaps because the
marketing department has written so much of the current
content. But we know how many snafus people can get into
even with well-designed software. So let's take the top
fifty calls to customer service and turn them into a set of
FAQs. The question states the problem, and the answer comes
in two parts: a diagnosis and, hopefully, some kind of
solution.
For problems that are too complex to diagnose off the top of
your head, put together a branching diagnostic, like the
ones for a printer, where you lead people through a series
of questions so that you can eventually pin down the
diagnosis. In this way, you are imitating the technique of
personalization, where a site asks a whole series of
questions then unfolds the perfect product or the right
content for that individual.
When visitors see a concrete payoff ahead, they continue to
answer the questions even when they thought, at first, that
they would get a simple answer.
Write procedures
In most FAQs, instructions have been blended,
higgledy-piggledy, with marketing fluff, half-explained
concepts, random explanations, and, oh, another spate of
instructions—all in one answer. We know from usability
research that this approach does not work very well for most
people. So edit the heck out of existing FAQs to make them
work better.
If you are telling people how to do a task, pull the
procedure out of the paragraph. Give real numbered steps.
Separate explanations from instructions. Do what the best
technical communicators do in manuals and Help.
Show me the picture
Back when we created manuals, we used to include screenshots
to show where to carry out the next instruction or to
confirm progress. "Yes, you have configured your system
correctly!" But when we developed online help, pictures got
dropped on the cutting room floor. And, oddly, most FAQs
follow that tendency. In a recent survey of FAQs, we found
that less than 5% offered any graphics.
But outside of the FAQ, the site is probably jammed with
photos, diagrams, and animations. You might, then, consider
adding a diagram here and there, a partial screenshot
showing the tools to use, a screenshot showing the result of
a complicated operation. Of course if you include visuals,
you extend the convention of the FAQ, which started out in
an all-text, low-bandwidth, exchange of emails.
Find out if you have answered the question
At the end of every answer, include a real request for
feedback. Whoever writes the FAQ should be willing to get
the email.
Continue the conversation. Ask your visitor, "Has this
answered your question? If not, please try the Search or
email me." Notice the me?
Conversations take place between people, so your persona
ought to be that of a person, not a corporation. And just
allowing other folks to send you email increases their trust
and satisfaction.
|
