TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Holly Dunagan is <<starting a project working with advertising to discuss
on-line instructions even though the web site wont be live until next
January. I am wondering how to put something together that will actually be
useful.>>
Do you have any audience information whatsoever? If not, and you've really
got almost 6 months before the site goes live, the first thing you should be
doing is getting some audience analysis done. Anything we can tell you here
will be good, practical, theoretical advice, but may be completely
inappropriate (or at least way too vague) for your actual audience.
<<Do on-line shoppers expect clear step-by-step help on an e-commerce
site?>>
No, but think how pleasantly surprised they'll be when you give them some.
<g>
<<* Do they expect the copy will be mostly promotional over functional?>>
Probably. Again, think "pleasant surprises"!
<<* Is there a good rule-of-thumb for the length of answers to FAQ
questions?>>
Yup. "Long enough to answer the question." <g> My experience, supplemented
by a fair body of anecdotal evidence, is that readers who are interested in
a topic or who need lots of information are happy to read a long
explanation--provided the writing is good, the topics are well organized,
and you've used white space and graphics appropriately to break up and
support the text. If not, they won't read it. A reasonable compromise
involves providing a short but very specific summary in the first paragraph,
so readers can determine whether the text answers their question (and
experts will get the answers they need in that first paragraph without
needing to read further); if so, they'll keep reading, but if not, they'll
look elsewhere.
<<* Can the FAQs meet the needs of shoppers who are really new to computers
and internet, or must the FAQs focus on the specific application to be
effective?>>
Both. You'll rarely have a completely homogeneous audience, and that means
that your documentation (here, the FAQ) must address the needs of both
populations. My single biggest problem with FAQs is that they never have any
obvious sequence to them, and I rapidly get frustrated scanning through
endless headings to find the one specific topic I need to find. IMHO, the
only way to make a useful FAQ is to treat that part of your site like the
index to a book: provide fast, obvious access to specific related lists of
topics through a hypertext table of contents, with additional tables of
contents if necessary. Never force readers to scan linearly through the
entire FAQ; that's a guarantee of failure for all but the most persistent
readers.
<<* As a writer, should I be focused on "closing the sale" or on clarifying
software?>>
Both--sort of. <g> Your role in documenting the site is to make it as easy
to use as possible, thereby making it attractive to use the site. That'll
make more sales than all the marketing bumf in the world put together. Let
the marketers do their own evil magic, and concentrate on what _you_ do
best: making something usable. You suggested being the usability expert for
the sales staff, and that's a great idea. Take it and run with it, and
produce the first e-commerce Web site designed for users, not for the
designers!
"Technical writing... requires understanding the audience, understanding
what activities the user wants to accomplish, and translating the often
idiosyncratic and unplanned design into something that appears to make
sense."--Donald Norman, The Invisible Computer
