For any major project, building a model assists the design process. Credit: Dr Nothing’s prototype cloaking TypHoon. (Flickr user fe2cruz, some rights reserved.goo.gl/rHswxi)

A prototype is, generally speaking, a preliminary model designed to guide the development of a complex project.

A sculptor makes a scale model in clay — a prototype — before chiseling away at a full-sized chunk of marble.  It is much easier to fix major mistakes in clay than it is to throw away a ruined chunk of marble and start over again.

Whether you use clay, Lego bricks or hand-written bubble maps, planning out what you want to do before you start doing it means you’ll save time in the long run.

Many a high school student has muddled through a book report in a single caffeine-fueled sitting, but successful research term papers or quarterly progress reports require planning.

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.

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 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 (mot just a promise of what the section will cover when you get to it, but an outline of the contents and some sample details).

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 whatever major sections you are using; it might be a game level, a video tutorial, or an online form) fleshed out in the kind of detail your research has led you to believe your user will need, and
• a sampling of the glossary terms, illustrations, appendices, or other supporting material that the reader will need in order to use the other sections that you have prototyped.

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 rely on 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 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 sections, 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 components are good enough as they are, and which need more of your attention, and which attempts are not worth saving.

• 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 believe me when I say that it’s your job, as the creator, to identify and adapt to the needs of the user; it’s not the user’s job to read your mind and do things your way).
  • 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. (See: “If They Don’t Test, Don’t Hire Them“)

See also:

• The Project Cycle
• Technical Writing Handouts