Prototypes in Technical Writing: What are They?
A prototype is, generally speaking, a preliminary model of a larger, more detailed object. In technical writing, a prototype might be a full table of contents (with summaries for each major section) and one or two complete chapters. If conducting a survey is an important part of your project, your prototype might be a complete survey of a small number of subjects, designed to iron out the kinks in the questions you want to ask.
A good prototype will help you identify flaws (such as incomplete research or mistaken assumptions) before you have multiplied their harmful effects by investing additional effort in them. A sculptor makes a scale model in clay -- a prototype -- before chiseling away at a full-sized chunk of marble. It it much easier to fix major mistakes in clay than it is to throw away a ruined chunk of marble and start over again.
You cannot grab a random glob of clay, throw it on a table, and call it a prototype. Testing such a blob would be meaningless. Likewise, taking a good prototype, and poking at it randomly is equally useless. The prototype is a means to an end; its purpose is to identify the flaws in your work, early in the process, while you still have time to do something about it.
So, how do you identify the flaws in your work? You don't actually do it yourself -- instead, leave it up to your test subjects. (See: "Usability Testing: What Is It?") But before you go hunting for volunteers, you need to have something worthwhile to show them.
Prototype both Breadth and Depth
When preparing a technical writing prototype, you need to present enough of your document that your readers will get a sense of how the components are supposed to relate to each other; yet you must also be willing to throw out your work and start over, if necessary. You need a balance between shallow breadth and narrow depth.
To provide breadth, include rough drafts of
- the table of contents (with descriptive titles of sections and subsections)
- the general introduction, and
- synopses of the major sections (explaining what each section will contain and providing sample details). (See: "The Synopsis")
The summaries or outlines should be detailed enough that your reader also has a good sense of what will not be in any particular section.
To provide depth, offer fully-fleshed out versions of
- at least one complete chapter or major section (fleshed out in the kind of detail your research has led you to believe your user will need), and
- whatever glossary terms, illustrations, appendices, or other supporting material that the reader will need in order to use the other sections that you have prototyped.
|T of C||Intro||Chapter 1||Chapter 2||Chapter 3||Chapter 4||Glossary|
|*Full Draft*||*Full Draft*||*Synopsis*||*Synopsis*||*Synopsis*||*Synopsis*||*A-C*|
|Section 1||*Section 1*||Section 1||Section 1||D-Z|
|Section 2||*Section 2*||Section 2||Section 2|
|Section 3||*Section 3*||Section 3||Section 3|
Use the results of your initial user testing to help you determine which sections are the next most important for you to complete. Your users might decide that one proposed chapter is unnecessary; they might beg for a new chapter that you hadn't planned to provide. Now is the time to revise, rethink, and retest -- before you have dotted all the i's and crossed the t's, and have no time left for major revisions.
Warnings and Advice
As an instructor, I try to teach a well-respected method that companies respect because it steadily delivers good results. That method begins with advance research, and continues with a cycle of prototyping, user testing, and revision, which continues up until the time and/or money in the budget runs out. If you never test a prototype, you may still be able to deliver a decent product; but unless you can actually produce statistics that illustrate the effects of the improvements that you made since your first prototype, you will have no way to demonstrate the effect of your own individual skills and abilities.
- Perfectionists beware -- you should NOT think of your prototype as a complete, polished draft. Everyone learns -- sooner or later -- that something or other is not right about their initial conception of a writing project. You won't be penalized if your users find flaws in your prototype; in fact, you want the users to point out the flaws at this stage, so that when you flesh out the other chapters, you won't repeat the same problems. A prototype will help you identify problem areas before you have committed a lot of effort to them. Your test subjects which sections are good enough as they are, and which need more of your attention.
- Procrastinators beware -- If you wait too long to start on your prototype, you will tend to ignore any evidence that your prototype falls short. Since you won't have enough time to throw out your mistakes and start over, you will try to convince your client and superiors to believe that that your first try was pretty good -- even if you don't have the numbers to support your claims. You may bluff your way through this initial problem, and thus convince yourself that working with a prototype is a waste of time; but your end users will be confused and frustrated by the very same errors that you ignored when they turned up too near the final deadline for you to do anything about it.
- Free spirits beware -- if you think of user testing as just another annoying piece of administrative busywork, and you'd rather ignore it and do things your own way than listen to what your users have to say, you've either never seen the results from a good usability testing session (and therefore don't know how much prototyping can help) or you simply don't understand the concept of technical communication (which requires the writer to identify and adapt to the needs of the reader, not vice-versa). If you believe that you can produce quality work by waiting until the last minute and letting adrenaline guide you through bursts of sudden creative inspiration, then you are ignoring your best source of input -- your users. If I cannot convince you of the value of user testing, please don't ever take a course from me or ask me for a letter of recommendation. (See: "If They Don't Test, Don't Hire Them")