The dangerous myth of the "completely intuitive product"

[Typo? What tpyo? 05-Jan-1994 1040 <jong -at- TNPUBS -dot- ENET -dot- DEC -dot- COM>]

In responding to my thesis that there is no such thing as an "intuitive"
non-trivial software product, Brian Daley <briand -at- MEI -dot- COM> said:

>> I think the idea behind intuitive products is not to get rid of tech
>> writers or to make us second-class citizens, but to give the users of the
>> product something they can really use....

>> ... I think an intuitive product is always the goal, and that there will
>> always be a need for technical communicators (or "human factors
>> specialists" or something related...)

I recognize and support that goal.  It certainly doesn't bother me to think of
developing information products for on-line display only instead of printed
pages.  Indeed, if more people gain access to my work, I'm happier!

But I disagree that the "idea ... is not to get rid of tech writers."
All too often, it *is* the idea -- at least, that's the impression I get from
the context of the discussions.  As I wrote before, it bothers me most when I
hear someone in my own management chain report out of a meeting with some
engineering vice-president, lips chafed, and drop that line.

Larry Kunz <ldkunz -at- VNET -dot- IBM -dot- COM> turned to the automobile analogy, which I
considered before posting my thesis.  You'll note that I did not mention
hardware at all.  An automobile is a design whose user interface has not
changed fundamentally over fifty years.  You have been exposed to automobiles
all your life.  More importantly, you took driver ed, driving lessons, you had
to take multiple tests, you had to be licensed to use your auto, and you will
have to take period re-tests all your life. While using the car, you cannot
read documentation. And yet cars *still* come with manuals, albeit relatively
brief ones.  One reason is that cars have the limited function of locomotion.
If you list the tasks that can be done in a car, I wonder if it will be
anywhere near as long as the list of things you can do with a software product?
Also, need I mention the ancillary documentation?  How many pages is the
Chilton's repair manual for your auto?  I'll bet it's over 1,000 pages.

An automobile has a small set of controls, indicators, and counters (such as
the odometer).  We sell DECnet/OSI networking products: a DECnet/OSI machine
can have ten thousand (!) counters, characteristics, and attributes. I have
just finished writing a manual for a product called the DEC SNA Peer Server,
which slightly extends the architecture.  My document has an appendix
tabulating the relevant management objects; the appendix runs 43 pages. Intuit
that. 8^(  Yet a colleague came to me for advice about another product, also an
extension to DECnet/OSI functions, not as complex but complex enough, for which
the engineering team wished to provide *no documentation at all*.  They
believe, I think, that their product will be intuitive enough not to need it.
Intuition by fiat?  I have advised that they provide the necessary
documentation in some form.

We must be very careful and clear to make the distinction between moving user
information from paper to online delivery, which I think is all to the good,
and the dangerous myth that the information is not needed.  In the former case,
we still turn out usable products and we still have jobs; in the latter case,
neither is true.

                -- Steve