Re: Chicago IE Workshop Announcement

[John Bowie <BowieCon -at- AOL -dot- COM>]

>Mr. Bowie:
>
>If you think I'm gonna spend $695 for someone to tell me what
>a failure I am, you know less about communication than I do.
>Perhaps you should re-think your approach to members of
>TECHWR-L?? Are any other list-members off-put by this promo?

>Dave.


Hello Dave,

Perhaps the following article from Intercom will help to clarify
what Information Engineering is all about. If you can get past the
first paragraph, you'll see that I think technical communicators are
a highly valuable, but misspent, resource.

Regards,

John

--------------------------------------------------------------------
Information Engineering: Using Information to Drive
Design (May issue of Intercom)

Many, if not most, technical communication professionals waste
their time providing services that no one wants or uses. Except in
rare cases, they provide little or no value to the organizations that
employ them, and fail in their efforts to communicate with the
users of the products they support.

To many of you, these are fightin' words. Who am I to impugn the
integrity of your chosen profession, to suggest that your labors of
the past several years have been for naught? I must be one of those
nerdy engineers, right? You know the ones--those left-brained
guys with the pencil protectors and the personalities of moles who
think technical writers are third class citizens, just engineering
wannabes.

Nope. Not even close. I'm an English major who's been working
in the technical writing field for fifteen years. I've written dozens
of manuals, reams of online help screens, even a few web pages
and CBT modules. So when I indict technical communicators for
failing to deliver on the promise of their profession, I indict
myself. I'm a charter member of Infoholics Anonymous.

How about you? Have you been working so hard at your job that
you've forgotten your mission? Your mission is not to write
manuals, or online help systems, or web pages or CBT modules--
these are just line items in your job description, vestigial methods
left over from the days when words and pictures were the only
tools you had to work with.

No, your mission is not to deliver information, but to facilitate the
communication between a human being and a piece of technology
as they collaborate in the performance of meaningful work.* And
no, this does not imply that your mission is to write task-oriented
information or develop performance support systems. It's deeper
and more subtle than that.


Information Engineering

Information Engineering (IE) is a philosophy and a supporting set
of methods that attempt to return the technical communication
profession to its true mission. Emphasizing user-to-product
communication instead of writing, IE empowers technical
communicators with new tools, new responsibilities, and new
approaches to solving the problems that originally gave rise to our
calling.

In the remainder of this article, I will share with you a few of the
key principles that form the foundation of Information
Engineering. Unfortunately, I can only scratch the surface here,
but I hope to leave you with something to think about, or to instill
in you the conviction to act on what you already believe.


The Mythical User

It's time to stop using the U word. To me, calling someone a
"user" implies that this person's identity is derived solely from the
product, that this person's purpose in life is none other than to use
this wonderful product we've sold them. It's a subtle complaint I
know, but the term has given rise to an entire culture of user-
centered design which, at the risk of being burned at the stake, I
suggest has lead us down as many detours as its techno-centric
predecessor, the Let's-Build-Something-Fun-And-Throw-It-Over-
The-Wall school of product design.

Focusing on the user has inspired many a product team to go forth
into the field and collect reams of data on the ages, education
levels, genders, zodiac signs, and hair styles of their current
customers in the hopes of finding insights that will guide their next
design. What usually happens is that the team quickly becomes
overwhelmed with data that has absolutely no relevance to the
design decisions they need to make. Then, as the schedule closes
in around them, they are forced to shelve the data and revert to
designing by their instincts.

Instead of focusing on who uses the product, IE encourages the
design team to focus on Job 1, a term we use to describe the core
goals and activities of our customers. Job 1 for a nurse is caring
for and monitoring the condition of a patient. Job 1 for a writer is
authoring, editing, and producing documents. Job 1 for a civil
engineer is designing bridges and roads.

Principle 1: There are no users, only people who want to get
something done.

Job 1 is not installing software, configuring computer interfaces,
reading manuals, learning operating system commands, wading
through CBTs, etc. These are Job 2 tasks: tasks which inadequate
product designs impose upon people, often as prerequisites to
completing Job 1. Yet we often assume through our arrogance that
Job 2 tasks are essential and even important.

We often spend the brunt of our documentation efforts explaining
and supporting Job 2 tasks. In task analyses and usability tests, we
often assess and refine these Job 2 tasks without stopping to ask
whether these tasks are relevant to the user--we just assume they
must be done. Instead of refining or documenting irrelevant tasks,
IE says we should design them out of existence.


Design Maturity

When I consult with product design teams about the concepts of
Job 1 and Job 2 and encourage them to use IE to eliminate
irrelevant and burdensome responsibilities that they assign to their
customers, they often get a smug look on their face and exclaim,
"You don't understand. Our product is inherently complex. There
is no way to make it simpler or to eliminate these so-called Job 2
tasks."

Whenever I hear this, I get a smug look on my face and tell them
that their product is not inherently complex, it's just
technologically immature. Of course I don't say this in these
words, but I demonstrate to them why this is true.

Every piece of technological innovation is complex when first
invented. Look at old computers, old telephones, old anything, and
you'll see a mass of wires and crude parts that no one could use
without considerable effort and training. As the product matures
over time, its interface becomes more refined as the raw
technology disappears under increasingly intelligent and abstract
layers of the user interface. The "inherent complexity" turns out to
be not so inherent after all, and the product eventually matures to
the point where it supports Job 1 directly and, sometimes, becomes
completely invisible.

If you look at this maturation process from an IE perspective, you
can see that product evolution is a process of eliminating Job 2
requirements from the product design and building in more direct
support for Job 1 tasks and goals. Information Engineering
attempts to speed up the maturation process by using information
as a metric of complexity: by assessing a product's information
requirements, we can readily identify areas of the product design
that impose the largest Job 2 burdens on people.

Principle 2: Job 2 product design defects manifest themselves as
information.

Measuring a product's information requirements is not a simple
matter of counting pages of documentation, however. The
information requirements for each major Job 1 task must be
broken down, categorized, and then analyzed according to the
following three criteria:

  1. How relevant is the information to the human being's Job 1
     goals?
  2. How accessible is the information to the human being?
  3. How much human effort is required to understand the
     information and put it to use?

Once the information is analyzed in this way, it's usually easy to
identify areas of the product design that impose the largest
information burdens upon the customer.


Information Conservation

In many corporations, technical communicators are expected to
document a product's information requirements, no matter how
irrelevant, inaccessible, and difficult they are. Not any more.
Documentation, in all of its forms, is only one way to satisfy the
information requirements of a Job 1 process.

In effect, documentation is a lame attempt to install functionality
that is missing from the product into a human being. Think about
it: the product doesn't contain the functionality to automatically
install or configure itself, so customers must be given this
functionality. The only way to install this functionality in
customers is to program them through documentation, by forcing
them to read, process and learn information.

While programming the customer may seem like the easiest and
least expensive way to implement a function, this is rarely the
case. Documentation, training, and support costs for products with
high Job 2 burdens are often huge and ineffective, and frequently
result in high product return rates, customer dissatisfaction, and
loss of repeat business.

These costs must be balanced against the costs of designing the
product to handle Job 2 tasks. It's true that designing the user
interface more carefully, embedding intelligence and Job 1
knowledge into the product, and setting up a Just-In-Time (JIT)
information delivery system will require additional time and
expense, but this investment is often less expensive than the
alternative of overburdening the customer with irrelevant
responsibilities and information.

Information Engineering uses information to drive these design
decisions. For example, when a company decides it's less
expensive and more beneficial to replace a difficult installation
process with a new, automatic process that requires no external
documentation and little user intervention, they have, in effect,
decided to shift responsibility for the installation information from
the human being to the product.  From the IE perspective, the
information has not been eliminated; it's just changed ownership.

Principle 3: Information is neither created nor destroyed, it
simply changes ownership.

By measuring the relative costs of information ownership on both
sides of the product/customer scale, product design teams can
more easily make decisions about which functionality and
information should be assigned to the product, and which should
be assigned to the customer.


Interaction Design

In order to achieve Job 1 goals, the product and the human being
must interact, i.e., they must exchange information and take turns
performing functions. The final step of information engineering is
to ensure that the exchange of information and functions between
the product and the human being occurs seamlessly.

This sounds like something technical communicators ought to be
good at. After all, we've been shoveling information at customers
for years. The problem is, we've been telling customers the
answers without listening to their questions.

Let's say a person is using Microsoft Windows 95 and they want
to copy a file from their hard disk to a floppy disk. They knew how
to do this in Windows 3.1, but now that the File Manager is gone,
they're lost. They need information. They have a question. They
want an answer. But, not everyone wants to receive the answer in
the same way.

        Person 1 might say, "Tell me how to copy files."
        Person 2 might say, "Show me how to copy files."
        Person 3 might say, "Help me copy this file from my hard
        disk to my floppy disk."
        Person 4 might say, "Just copy the file for me."

For decades, the technical communicator's response to all these
requests has been: "Read this." This may be an appropriate answer
for Person 1, but a totally frustrating response for the others.

Principle 4: Before You Provide the Answer, You'd Better Know
the Question

IE provides a methodology for organizing wizards, coaches, cue
cards, mini-tutorials, simulations, GUI objects, and other recent
additions to the technical communicator's toolbox into an
information delivery architecture that satisfies the variety of ways
human beings might want to interact with a product. Again, the
point is to broaden the traditional view of information and
communication from a limiting paradigm of static manuals and
online help systems to include all of the possible ways a product
and a person can send and receive information.


The New Technical Communicator

I may have offended you in my opening paragraph by suggesting
that your work is of no value. But many, if not most, technical
communicators spend their professional lives documenting
irrelevance--describing tasks, concepts and terminology that are so
far divorced from why the customer bought the product that the
customers reject their work outright. But it's not so much the
writing or training they reject as the poor product design that
necessitates it.

Many of us have spent years complaining about this debacle; by
using IE, we can do something about it. As owners of user-to-
product communication issues, we can reject the notion that
hemorrhages of design can be administered to with rhetorical
Band-Aids. But we can't just complain about it; we must
demonstrate to our teammates and managers how much the
problem costs and then show them how to solve it.

Yes, there are many obstacles in our path to this new role: border
wars with those who feel we are encroaching on their job
responsibilities, time crunches as we continue to churn out
manuals while we simultaneously take steps toward Information
Engineering, skill deficiencies in many areas, including user
interface design, prototyping, leadership and persuasion. We can
find answers to all of these, but that's a subject for another time.

The information age requires a new brand of technical
communicator-one that can distinguish between information that
is relevant to his or her customers and information that is not. One
that sees the poor design of a product interface as just as much a
technical communication problem as a double negative in step 2 of
an installation procedure.  One that never loses sight of his or her
true mission, and will not allow the artificial boundaries of
corporate politics or the limits of antiquated job descriptions get in
the way of achieving that mission. One that views communication
between the product and the human being-in all its forms-as the
most critical problem (and opportunity) facing product
development today.

In the late nineteenth century, Western Union had the opportunity
to acquire the Bell patent for the telephone, but they passed it up
because they insisted they were in the telegraph business, not the
telephone business. This nearsighted focus on their current
business (telegraphy) prevented them from recognizing their true
mission (long distance communication). They failed to recognize
that their mission should not limited by the current technology that
is in use at the time. As a result, they lost a huge opportunity.

Are you so entrenched in the manual business that you have
forgotten your true mission? Are you passing up a chance to solve
the core challenges of technical communication because you fear
the solution might render your precious manuals--your business--
obsolete?

Instead of worrying about finding new ways to entice people to
read your manuals, why not invest your efforts in designing
products that don't need manuals...or online help systems...or
computer-based training...or telephone support? That's right--why
not work yourself out of a job?

There's a better one waiting-if you have the courage to accept it.`

 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