Previewing Chapter 5 of An Overview of Training and Development

How can you distinguish myth from reality in the advice given to training and development professionals?

Learn how usable learning expert Julie Dirksen masters learning research and applies the resulting insights into the programs she designs. Check out Chapter 5 of the newly published book, An Overview of Training and Development: Why Training Matters



A Most Touching Case of Plagiarism

Over the past few months, several people have raised questions about using copyrighted materials.

Here’s a cute story about what happens when people do so without permission:

Another Observation about Television

In a recent post on the sibling site, The Commerce of Content, I noted that Americans still overwhelmingly consumer television traditionally, despite the availability of Internet and mobile viewing.

Another study, from the Organization of Economic Cooperation and Development, indicates that the 140-plus hours of television watching per month reported by AdWeek is seriously out of alignment with television viewing habits in other developed countries.

Check out the data and conclusions at

Conceptual versus Practical Communications Education Causes One School to Suspend a Program

Although I have not heard of a suspension of a technical communication program following a program review, each program review brings about the possibility of a suspension of a program.

The particular issue that should be of interest to programs in technical and professional communication is the expectation of practical courses in addition to conceptual courses.  In this particular case, the people reviewing the program felt that practical, skills-based education got the short shrift and that needs to be addressed before the program is reinstated.

More broadly, this tension between conceptual and practical education exists in all types of programs, and is one of the most common concerns raised by practicing professionals.

Also note the source—  This is a terrific, collaboratively published and maintained site, that serves the journalism community in Canada.  It includes a mix of industry news, industry events, news about academic programs, commentary, and career advice.

View the entire story at:

Evidence and Plain Language


“Evidence-based” is a term that started in medical fields and has been adopted in many others, especially education. 

It’s the current incarnation of longer-term efforts to integrate extensive bodies research into everyday practice.  It’s similar to previously promoted concepts like  “What Works,” and research-to-practice.

STC has run some virtual research-to-practice conferences, and published a great compilation of research-based heuristics for developing web-based information in the Third Quarter 2000 issue of Technical Communication.

Iva Cheung summarizes a 2013 presentation by Karen Schriver that discusses evidence-based practices in plain language and that addresses these specific topics.  Some of the recommendations differ from earlier ones as technology changes and our base of research goes.

  • Audiences, readers, and users
  • Nominalizations
  • Conditionals
  • Lists
  • Text Density
  • Serif versus sans-serif
  • Layout and design
  • Impressions and opinions
  • Technology
  • Teamwork in writing and design

Check out the summary at:

Lessons for Content Design from the Experience of Online Shoppers

Like most online shoppers, you probably have experienced:

  • Frustration with searches that produce useless results
  • Annoyance by efforts to “upsell” you (that is, get you to buy things you don’t want)
  • Irritation with online checkouts that never seem to go smoothly

Google Analytics produced a series of videos to sensitize online retailers about these issues (and, of course, to market Google Analytics, a service that etailers can use to analyze where customers who do not purchase drop off the site so etailers can analyze and fix the problem that might have driven these prospects away).

Although presented in the context of etailing, the issues that Google raises are not limited to that situation.  Consider these issues:

  • Non-intuitive navigation that prevents users from finding the information they seek
  • Disruption of the online reading and learning experience with endless links to “related” articles (some as outdated as 1990s pop music) and short screens that require constantly loading new pages
  • Online forms for whom whatever information is provided is never sufficient

The truth is, most of us are aware of these issues but, challenged with producing content on ever-compressed schedules, keeping visitors on-site as long as possible, and meeting a variety of political needs (often at odds with user needs), most of us forget about them.

Check out the videos at


Say It Simply

One of my former students shared Robert Krulwich’s recent post, Why Not Say It Simply? How About Very Simply? with me.

It’s the most eloquent and illustrated case for plain language that I’ve seen in a while-and has a great example of a figure of a Saturn 5 rocket with plain-language callouts.

Check it out for yourself at:

How to Write Procedures


In this Article

What Is a Procedure?

How to Write a Procedure


What Is a Procedure?

A procedure is a set of instructions for performing a task. The task can be physical,
such as installing a modem, or mental, such as calculating the profit margin on a product.

Procedures are among the best known formats in technical communication.

Procedures tell users “how.” Specifically, procedures tell users how:

  • To do something, such as changing the oil filter in a car.
  • Various parts of a task relate to one another, such as how a bill passes through the a legislature.
  • Something was done. Users can then verify what happened. For example, a researcher can review the procedures another researcher used to determine whether the analysis is valid.
  • Something will be done. Users can then make necessary plans.  For example, a procedure might state the plan for a documentation project. Users can then determine when they must distribute review copies (or receive them for review) and plan their time accordingly.


How to Write a Procedure

This section explains how to write a procedure.  It starts by explaining how to start the procedure, then explains how to write the main part of the procedure, and concludes by explaining how to close a procedure.

How to Start a Procedure

Do the following to write procedures:

  • First, state the goal of the procedure as succinctly as possible. For example:

This procedure tells you how to start your car.

This procedure tells you how we conducted the study.

Often, a good heading will suffice, such as:

Starting Your Car

How We Conducted the Study

  • If readers need knowledge, supplies, or assistance to perform the procedure, next state that information in a Read Me First section, which precedes the procedure.

Present supplies needed as a checkoff list. The checkbox signals readers that they need to do something. For example:

Before starting the procedure, get these supplies:

        • Tape
        • Scissors
        • Construction

Tip! Only explain “must-know” terminology and concepts in a procedure. That’s because readers use procedures to learn how to do something, not the concepts and terminology underlying them.

For example, readers must know what a command is before they can use it. But they do not need to know how a computer processes the command. A procedure for users, then, might define the term command but not explain the physical steps the system follows to process a command.

  • Mention “Who should perform the procedure.” For example:

Who should perform the procedure?

    • Technical writers
    • Technical editors
    • Technical illustrators
  • Provide an estimate of the time needed to complete the procedure. Provide an estimate that is a little bit longer than the typical user needs to complete the procedure; if users complete the procedure in less time, they will feel a sense of success. Timed usability tests provide the best means of estimating the length of a procedure. By providing an estimate of the time needed, users can determine whether they currently have enough time to finish the procedure.
How to Write the Steps of the Procedure

Next, present the steps of the procedure. Consider these guidelines as you write a

  • Write procedures as numbered lists. That is, begin each step with a number. The number tells readers the sequence for performing the steps. For example:
    1. Open the car door.
    2. Sit behind the wheel.
    3. Insert the ignition key.
    4. Turn the key to start the engine.
  • Because users can handle only a limited amount of information at any given time, limit the length to 10 steps.

If your procedure has more steps, break them into a “mini-procedure” within the larger procedure. Present mini-procedures in one of these ways:

    • As a separate procedure, with its own title. For example, suppose you are writing the procedure for solving problems with a computer, called a problem determination guide. Few computer problems can be solved in ten steps.

So, you might present an initial procedure that helps readers identify the nature of the problem (such as a hardware or software problem), then have separate procedures for solving the different types of problems.

    • As a “procedure within a procedure.” That is, you might write the mini-procedure as a series of steps within the larger procedure.

When writing it, you indent the mini-procedure within the step of the main procedure.

To distinguish the steps of the mini-procedure from those of the main procedure, begin each step of the mini-procedure with a letter. For example:

    1. Open the car door.
    2. Sit behind the steering wheel.
    3. Start the engine.
      1. Insert the key into the engine.
      2. Turn the key away from you.
      3. Wait for the engine to start. You will hear a noise.
    4. Begin to drive.
  • Consider the following when writing the steps in a procedure:
    • Limit each step in a procedure to one task. If the step has several tasks, break the step into several steps or write a mini-procedure. Real-world experience indicates that users stop reading as soon as they encounter the action to be performed in a step.
    • Present conditional information as a clause at the beginning of a step; do not place it after the action. Users usually stop reading as soon as they encounter the action and perform it. Placing the conditional information before the action is one way to make sure readers see it. For example, if users need to use both hands to hold a piece in place om an assembly line, say it at the beginning of the step, like this:

Holding the piece with both hands, place the assembly in the drying machine.

Do not write the clause like this:

Place the assembly in the drying machine and hold it with both hands.

    • Write each item on the list as a self-contained task. A task is an action that can be performed physically or mentally. For tasks that users are expected to perform, write in the imperative mood. That is, begin with an action verb and tell readers what to do. Research shows that users read these types of directions faster than ones that do not begin with actions (Mirel, 1991).

Turn the power on.


Subtract expenses from revenues.

    • For procedures that users are not expected to perform, include the agent (person who is expecte to perform the task) for each action so readers know who or what is responsible for that task. (That’s another way of saying, write in the active voice.) For example:

The Information Development department will distribute the information plan by January 22.The Programming, Product Test, and Marketing departments must submit their review
comments on the plan by January 29.

Rather than:

      • The information plan will be distributed by January 22.
      • Review comments must be submitted by January 29.

In this second version, readers do not know who is responsible for performing the steps. It might be them.

    • When several people perform a procedure together, you need to state who performs each step and how responsibility passes among people performing the procedure. John Brockmann
      calls this a playscript.

For example:

      1. The technical writer writes the document.
      2. The technical writer electronically transmits the document to the editor.
      3. The technical editor:
        1. Prints the document.
        2. Identifies the passages that need to be illustrated.
        3. Completes an Art Request Form for each illustration needed.
        4. Submits the Art Request Forms to the technical illustrator.
How to Close a Procedure

Close a procedure by:

  • Telling users that the procedure is complete. You might write “You should now see the Program Manager of Windows with the New Program Icon on it. This is the end of Procedure,” or be more descriptive, writing something like “Your VCR should now be installed and ready for use.”
  • Providing anticipated problems, and how to address them. For example, you might say “If the Program Manager appears but you cannot find the New Program Icon, then you should….”

Note that you should describe anticipated problems (results that are incorrect, but likely to occur anyway from a minor mistake at the users’ end) at the place that they would likely occur, so users receive immediate feedback and can easily correct problems themselves.

  • Referring users to related procedures and other information of interest.



Here’s an example of a procedure that readers are expected to perform:

To choose a task from the action bar without using a mouse:

  1. Press F10.
  2. Move the cursor to the task you would like to perform.
  3. Press Enter.

Notice that each step begins with a number and is written as a command to the reader.

Here’s a procedure that readers are not expected to perform:

  1. Using the analysis of covariance test, Miller analyzed the data.
  2. Miller presented the results to Richards and Defoore for verification.
  3. Richards and Defoore certified the results.

Notice that each step begins with a number and that the agent for each step is
identified (the agent is the person who performed the step). Notice, too, that the
conditional clause in step 1, “Using the analysis of covariance test,” appears
at the beginning.

Also consider this example of what you should not do.

To choose a task from the action bar without using a
mouse: the F10 should be pressed, then the cursor should be moved to the task to be performed. Once the cursor is there, the Enter key should be pressed.

Notice in this example, that the procedure is presented as a paragraph and that the
paragraph is written in passive voice. This tells users what should be done, not what they should do.


How Should You Continue Your Learning Journey in Technical Communication? A Self-Assessment

Are you interested in training in technical communication? A bachelor’s degree? A master’s degree? A PhD?

Although all of these options exist for continuing your learning about technical communication, each type of education addresses a different need.

So which educational option best meets your needs? That depends—based on your goals, personal situation, finances, and how independently you want to study.

The interactive article How Should You Continue Your Learning Journey in Technical Communication? A Self-Assessment in the July/August 2012 issue of Intercom helps you to assess your needs and suggests the type of program that might meet them. In it, you answer a series of questions, calculate a score, and, in the score, learn which option might best meet your needs. Following that, this article describes the learning options available, for whom each is intended, and how they differ from one another.

To see the entire article, visit:

Note that a membership in the Society for Technical Communication is required to view the article.

Hello world!

Welcome to! This is your very first post. Click the Edit link to modify or delete it, or start a new post. If you like, use this post to tell readers why you started this blog and what you plan to do with it.

Happy blogging!