RE: The origins of task-oriented writing as a preference

["Locke, David" <dlocke -at- bindview -dot- com>]

Mark said,

> Can anyone tell me the origins of this movement toward task-orientation
> in writing?

> Has anyone had any experience surveying computer-savvy users of more
> complicated software (like ours) to see whether they want tasks or
> reference information?

It is not a recent movement. Ed Weiss'es How To Write Usable User Manuals,
1st ed. based manuals on a task analysis, and distributed content by role. 

There are some general indicators about what "computer-savvy users" or
technical enthusiasts want from documentation. They don't want documentation
at all. They are model constructors. They will build them on the basis of
what the UI presents, they will ignore the book, and trust experience.

------

The problem boils down to technical enthusiasts vs everyone else. Technical
enthusiasts don't read manuals they construct conceptual models. They are
the people that guided discovery and minimalism was invented for. Everyone
else happens to be rote learners. They will not make the jump from reference
to action.

The entire software industry is in one business improving task performance.
If a product does not do that, it will not sell. Tasks are central to the
user experience regardless of their literacy. If they have poor experiences
with a product, they will not be retained by the vendor, and they will not
buy upgrades, which represent a huge profit to the vendor when they sell to
retained customers. Task performance is critical.

The notion that we can write more documents to improve task performance is
not an economic reality. And, it is not the cost to produce those documents
that is driving reality. The real point is that users are either doing
productive work or they are doing other things like reading manuals. The
productivity paradox surrounding IT investment is real. Everyone wants to
know why they can't seem to get more than an 8% improvement for their IT
investment. It is not that someone isn't seeing the value. The fact is that
they are not seeing the costs in an explicit manner. 

The people concerned with those numbers created the concept of the Total
Cost of Ownership (TCO). This TCO focus has resulted in zero administration
efforts, and ultimately to vendors hiding their administrative components
inherent in their functionality. Use costs were omitted from the TCO. So
while administrative, and management costs have been examined and made
explicit, positive and negative use costs remain invisiable. TCO related
costs have been driven down, but they were small costs in the first place.
Zero administration would only increase the productiviy number by 7.5% if
zero administration was possible. That 8% number is driven largely by
negative use costs consisting of the salary contributions for time spent
doing doc, training, technical support, experiments, and trouble. These
numbers come from audits the Gartner Group did a few years ago. The numbers
add up.

Task-oriented documentation provides a faster time to ROI and lower negative
use costs than reference material. It is what customers, economic buyers,
want. It is not some plot against literate computing, or reference
documentation.

Task-oriented documentation is not the answer. More documentation is not the
answer. Interactive documentation is not the answer. Statistical-inference
based guidance systems (the hated Paperclip)are not the answer. The answer
revolves around creating intuitive UIs, because they reduce negative use
cost quicker than anything else. 

-----

And, on the subject of hubris, when you take the view that you or your users
are smarter than everyone else, you are making your market smaller. The
market will punish you for your attitude. I worked in companies that died,
because they thought that they were smarter. Some of these even thought that
users were just like them. If users were like product developers, they would
write the stuff themselves. 

The problem is that lesser beings can't figure it out. They knew that they
don't have to, and don't want to. These lessor beings control most of the
money spent on software. 

Technical enthusiasts occupy the very front end of the technology adoption
cycle. They are the influence network. But, they also are the people who
demand control, feature bloat, and a software discipline focus rather than a
domain focus in products. The mainstream finds feature bloat objectionable
and the lack of domain focus problematic. The mainstream does not buy
software so they can play with it intellectually. They buy it to get work,
i.e. tasks, done.

Try to see where your economic value-add is before you reject the
task-oriented approach. 

I don't care how literate they are I want their money, their loyalty, and a
low cost of sale when I get back to them in the future. I wan't their name
in my database. I even want them to call technical support, so we can send
them a fax tip that makes them an expert and advocate for our product. And,
to do that I will have to omit some content and tell them to call for it.
Less doc, more content distribution. The call better be free.


David W. Locke