Re: What is quality?

[Edward Bedinger <qwa -at- CARSON -dot- U -dot- WASHINGTON -dot- EDU>]

Cc:

In article <9312301725 -dot- AA28575 -at- gensym1 -dot- gensym -dot- com>,
Paul Sholar  <pks -at- gensym -dot- com> wrote:
>I think that the most promising approach to the quality of products in
>general, including software product documentation, is "quality is
>conformance to specification."  That is, the closer that a product's
>implementation conforms to the product's "design," then the higher the
>"quality" of that product.  In turn, the more closely that a product's
>design conforms to how the customer actually uses the product, the


     Clearly this approach emphasizes specs
     and design.  I feel a little nervous about
     this, if the suggestion is going to be that
     product design must be recapitulated as instructional design....



>higher the "quality" of the product's design.

>In other words, the "quality" of a thing is a/the by-product of using
>a certain approach to making that thing.  The person (Deming?) who
>authored the above definition of "quality" is obviously more concerned
>with describing the process of producing quality products than with
>describing product characteristics.

>In my world, that of producing software product documentation, certain
>tasks are required in order to "specify" a document.  Several of us
>in this mail list have described doc plans, customer surveys, reader
>testing, etc.  The Society for Technical Communication (STC) and other
>organizations probably have an adequate handle on raising these issues
>and educating technical communicators about these tasks.

>Therefore, I think that the greatest constraint on the quality of documents
>is how documentation projects are conceived and managed.  I think that the
>major organizations (such as STC) that support technical communicators have
>not yet sufficiently raised the consciousness of (on the one hand) product-
>development management and marketing management and (on the other hand)
>readers of product documents to see:

>* Customers want useful documents about the products they buy.

>* Customers expect product-development companies to do a good job of
>   figuring out how to make these documents "useful."  That is, if the
>   company presumes to know enough about what the customer wants to have
>   built a product, why doesn't the company also know enough about how
>   the customer will actually use the product to write documents that
>   appropriately describe the product?

       I think there are lapses in the chain of responsibility.  As long
       as management fails to bring writers into the loop at the beginning
       of a product cycle, then the writers will probably never have access
       to the content and substance of decisions that shaped the product.  And
       as long as that is the case, the writer function is confined to
       describing a gizmo with no context.

       If a product is designed on spec, as a solution to a specified
       problem, then at a certain level it is safe to assume that everyone
       already is in agreement that the product can be assimilated
       and used correctly.  This vast oversimplification seems to have a lot
       in common with the approach to documentation  used by some companies.
       The only questions ever asked about instructional issues are things
       like "where did you go to school?"



>* There are generally accepted ways of gathering the information that
>   supports a definition of a document about a product.  Customers should
>   be better aware that these techniques exist and should expect product-
>   development companies to be performing those information-gathering (both
>   internal to the company and external) tasks before producing documents.

>* The published document should state its own purpose (including the scope
>   of the document's information) and should state the practical benefits
>   to the reader of reading the document.

>* The document should present the criteria under which its "quality" can be
>   assessed by the reader.  (For instance, the document could state that
>   by using this document, the reader will become proficient at x, y, and z
>   tasks and will do so in a particular timeframe.)  This sort of statement
>   invites a response from the reader, which should be incorporated in the
>   process of evaluating the document's "performance."


     Absolutely.  You're fobbing the whole Idea of an instructional design
     here.  If you have ever worked with writers and engineers who resent
     the notion that instruction is best delivered by instructors, then you
     know why something that seems so obvious to technical writers with
     instructional backgrounds still needs to be underscored and stressed
     and dragged out and aired again and again and again.

     I've worked with writers who say things
     such as "We used to do OK before they started sending designers in
     to 'help' do everything."  These are the same rugged individuals who
     hate editors.

     If there is a bottom line here, I'd say that someone with good instincts
     for instruction is good enough to do documentation.  You don't need to
     be a certified instructional designer to carry out the design functions
     that you specify.  Unfortunately, even the most intuitive instructors
     simply don't use an outline of a lesson plan, so that the instructional
     goals of a manual are often not explicit, and the quality of the manual
     is therefore much harder to evaluate.



>* A document's performance can only be assessed in the field, then that
>   assessment must be "fed back" to the authoring organization.  This is
>   probably the least developed practice in the technical communications
>   field.


     I had a marvelous conversation at a recent STC meeting in Seattle
     with a writer of on-line docs.  His product had a built-in feedback
     sheet, so that when the user found an error or problem, it was a
     simple matter of pushing a button to generate a report to the writers.



>I have only read (STC journals) of organizations that practice this kind of
>"total" approach to developing documents.  I would guess that only large
>organizations have the incentive and specialized resources to attempt to
>follow this approach to developing documents.  Most technical communicators
>don't work in large organizations.  (Is this a good assumption?  What figures
>do the STC and others have on this?)

>This leads me to a closing opinion. Every day I become more convinced that
>what technical communicators do is, in the medium to long run, bound to
>become a predominantly "out-sourced" activity.  I think that there is probably
>a good living to be made for persons willing to organize commercial ventures
>that provide these kinds of "total" document-production services to
>product-development companies.

>Your comments are welcome.

>Paul Sholar                        pks -at- gensym -dot- com
>Senior Technical Writer
>Gensym Corporation
>Cambridge, Massachusetts  USA


Ned Bedinger
Freelance Writer/Editor (available)
qwa -at- u -dot- washington -dot- edu