Re: Understanding v. instruction

[Jim Purcell <jimpur -at- MICROSOFT -dot- COM>]

Larry Kunz writes:

> At the risk of oversimplifying, his [Rick Chandler's, that is] 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.
>
Well, this does sound like a massive oversimplification on either
Larry's or Rick's part. There are times when our proper role as
technical communicators is to convey general understanding, and there
are other times when our proper role is to provide instruction. In the
software industry, for example, most manuals--even user's guides--are
basically reference documents that either describe the features and
commands and so forth (product-oriented reference manuals) or explain
how to do the tasks the software was designed to help with
(task-oriented user's guides). You can learn a lot from software
documentation, but in general its primary purpose is not pedagogical.

Tutorials more closely fit the model Larry describes above. Tutorials
often fail to "convey understanding" because they rely too heavily on
procedures at the expense of concepts, or because the exercises are
little more than typing practice. This was the problem that, by my
reading, John Carroll was trying to address with minimal documentation,
training wheel interfaces, and guided exploration: give the user a
conceptual interface, don't let them hurt themselves too much while
they're learning, and let them discover the product using examples from
their own work environment. It's a good model for teaching and learning,
but it was never intended to supplant the more conventional forms of
documentation.

> 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?
>
I think that "inform, rather than instructing" is a false distinction:
is not instruction a form of information? I think that for many
companies, information that solves customer problems  _is_ the product.
Companies that do this well will be very successful in the biggest
growth industry of our time.

I don't think that's what Elna is talking about, though, as her
subsequent post confirms. She is talking about companies that sell
solutions in the form of products, be they software or machinery. An
important component of those solutions is explaining how to use the
product to solve the problem. These explanations can take many forms:
conceptual, procedural, descriptive, or tutorial. To privilege any of
these forms without knowing the situation in detail is asking for
trouble.

Jim Purcell
jimpur -at- microsoft -dot- com
My opinions, not Microsoft's

 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