Re: info vs. products

[Mc Jdub <wigginje -at- PSSCH -dot- PS -dot- GE -dot- COM>]

I think it is misguided to suggest that we should let users "figure out"
how to use a product "for themselves."  Of course in the sense that
users look to documentation for answers they are trying to do just that
(as opposed, for example, to having a "live" person --or not, depending
on where you work-- show them how to do a particular task).  But as I'm
sure many know, "figuring it out on your own" can amount to a big waste
of time.

Imagine that you had never seen MS Access, for example, and your job was
to construct a database with specific queries, filters, etc.  Without a
very strong affinity for software in general, cue cards, help files, and
a decent manual, my guess is that most people would be fairly mystified
as to where to even begin. I know I would be.

Chandler reportedly believes instead that "We should tell [users] how
the products can meet their objectives," but, as someone else pointed
out (I think it was that excellent post by Stuart Burnfield), we don't
-- and can't -- always know a user's objective(s) in advance.  To
paraphrase Burnfield (?), a characteristic of the best software is that
it is used  in ways its designers never intended. The same could be
said, I suppose, for a lot of products, not just software. It seems,
then, that the correct way to approach this is to detail what the
product is capable of doing -- that is, to provide *information* -- and
let the user decide what he or she wants to do with that info.

Not to belabor the point, but how often has it also happened that a
user's particular objective was modified upon discovering a previously
unknown feature of the product?

I thought Elna made an *excellent* point regarding the paradigm shift
needed in industry toward emphasizing a new priority for documentation
and information. Products are more complex than ever before;
accordingly, we need information to know what these products are capable
of doing so we can then know what we are capable of doing with them.


Jeff Wiggin
wigginje -at- pssch -dot- ps -dot- ge -dot- com
======================================================
The opinions expressed above are not necessarily my own, but have been
generated randomly from cross-currents of available discourse.
======================================================


> ----------
> From:         Larry Kunz ((919) 254-6395)[SMTP:ldkunz -at- VNET -dot- IBM -dot- COM]
> Sent:         Friday, June 27, 1997 1:14 PM
> To:   TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
>
> How many of you caught Rick Chandler's talk during the Trends
> Forum at the STC Annual Conference last month?  (He was the guy
> who pulled three people out of the audience and had them make
> paper airplanes.)
>
> At the risk of oversimplifying, his thesis was that we shouldn't
> tell people how to use products.  We should tell them how the
> products can meet their objectives and let them figure out how to
> use the products for themselves.  Our proper role as technical
> communicators is to convey understanding, not instructions.
>
> I was reminded of this when Elna Tymes was quoted earlier this
> week as having said:
>
> > Companies who understand that they sell information are ones who
> work
> > closely with customers, who pay attention to how products are used
> and
> > what business problems they solve.  The customers of these companies
> buy
> > products and services based on how well a particular set of problems
> can
> > be solved - and it's the information that tells them how to solve
> the
> > problems, not the things.
>
> Rick says that companies sell products, and good technical
> communicators inform, rather than instructing, the consumers of
> the products.  Elna seems to go even farther, saying that the
> best companies don't even sell products.  They sell information --
> information directed at meeting the consumers' objectives or
> solving their problems.
>
> What do you all think?
>
> Larry Kunz
> STC Assistant to the President for Professional Development
> ldkunz -at- vnet -dot- ibm -dot- com
> http://www.networking.ibm.com/eNetwork
>
> ~~
>  TECHWR-L (Technical Communication) List Information: To send a
> message
> to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot-  Send
> commands
>    to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
>   Search the archives at http://www.documentation.com/  or search and
> browse the archives at
> http://listserv.okstate.edu/archives/techwr-l.html
>  Send list questions or problems to the listowner at
>

 TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot-  Send commands
   to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
  Search the archives at http://www.documentation.com/  or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html