Documents and other tools that the public interacts with are a kind of performance support; the goal is to help people accomplish something they want or need to do. Job aids are one form of performance support, and I see a ballot as a kind of collector worksheet (as opposed to one that helps calculate): information on the ballot form is organized, typically by office or issue, and the voter has a way to indicate her selection.
The Center for Civic Design has for its goal making “every interaction between government and citizens easy, effective, and pleasant.” I’ve just come across a post of theirs from 2008 that discusses in depth a usability test for state ballots in New Hampshire.
The test looked at a single question: is it better to left-align the names of candidates, or to right-align them so each name is as close as possible to the circle that the voter would fill in?
From a performance improvement viewpoint, and as someone who’s worked as an election judge several times, I found the discussion in the full report enlightening. As for the conclusions, participants in the test who used Ballot B:
Took slightly less time to vote.
Made fewer errors.
Preferred Ballot B to Ballot A.
From CCD’s conclusions:
Although the difference in the number of errors made by participants when voting on Ballot A and Ballot B is not statistically significant, the data indicate that there is a trend toward fewer errors when voting on Ballot B. For this reason, we recommend the use of Ballot B (right-aligned names) for the general election in November.
A strong proximity relationship between candidate names and fill-in ovals is more important than the alignment of names on the ballot.
Job aid design usually starts with an analysis that asks about conditions, steps, signals, responses, the desired accomplishment, and its criteria.
In this post, I’m showing a job aid I created that started from a different point: something I wanted to have, but didn’t.
What’s the problem?
My Building Job Aids workshop is made up of parts I think of as elements. One might be a mini lecture; one might be an activity to produce a decision guide; another, a quick judge-these-examples round I call Best in Show.
Although I have a plan for each session, the actual workshop varies from the plan. I shorten or drop or swap elements based on the skills and interests of the participants (or, sometimes, the relentless ticking of the clock). And after the fact, I go over what took place and decide what I want to do or do differently next time.
This isn’t easy to manage when you’re mainly concerned with running the workshop. What kind of support was I looking for?
A list of planned elements, with an easy way to see duration and order.
A list of potential elements that I could add or substitute on the fly.
A tool to track the elements, duration, and sequence I actually used, including any changes.
A way to record short notes in passing.
Enter the session scanner
I tried several layouts before deciding that what worked for me was a half-day plan on a single page. (For a full-day, I’ve got a second page with the afternoon hours.) 15 minutes felt like the smallest chunk of time, so it became the basis for a grid. Here’s what the scanner looks like when I’m done planning:
In the Planned column, the shapes represent individual elements, like the Makeover activity scheduled for 11. The height stands for the planned duration. The color around an element doesn’t mean anything; I just find them easier to distinguish when they’re not all the same color.
The Actual column is for tracking what elements I used, and how long they took in the real world.
You can figure out what the Notes column is for. And the Options column in the example lists three elements that I can add or substitute on the fly.
In the element shapes, checkboxes remind me about supporting materials for the particular element. Bullet items summarize of the main steps or stages.
The scanner at work
The next example shows the scanner after I finished the first element: an arrow to indicate elapsed time, and a couple of notes. (“Drafts had lots of ‘why'” would be important to me — suggesting the activity was not making the point that there shouldn’t be much “why” in this job aid.)
Next, the scanner about an hour later. The Analyze element didn’t take as long as planned, so I added the optional Paradigm Demo element.
One more example. The BermCo activity started later than planned, and also ran longer. My notes remind me that there were extra questions during the “check” stage, and that the debrief activity also ran long but didn’t strike me as a problem. (This example also shows the highly innovative “cross it out” method of showing a dropped element.)
So far, so good
If I were faster at digital note-taking on the fly, I might create an electronic version of the scanner and keep it on a tablet. But I’d want to avoid lag from a screen that had blacked out, and I’d need a way to write notes at least as fast and as legibly that I can using pen and paper.
All in all, I’m pleased with the current incarnation of the session scanner. It helps me in preparation, in delivery, and in post-session analysis.
(A makeover: the before version. Here’s the after.)
In my collection of job aids, there’s a special place for a particular set of assembly instructions. I’ve created a fictional version so as not to embarrass whoever created the original, and to show ways that even extremely inferior job aids can be improved.
That original was a set of instructions for assembling a piece of industrial equipment that I call the widget vat. Here’s a sample page (which you can click to enlarge):
I’ve fictionalized this, as I said. There is no Quasimodo Assembly Corporation, so far as I know, and I’ve altered other identifying bits of information. Otherwise, the layout is identical to the original. That’s page one above; here’s page five:
This job aid has a carload of problems. One of them–and by no means the most important–is that it was created in Excel. Let’s look at some of the others.
Background on the assembly guide
Suitability:what’s this job aid for? What’s its purpose?
You can ask that question from a performance-support point of view: what’s Quasimodo Assembly trying to do, and how could this job aid get it done?
The granular version is: they want to guide workers who are assembling widget vats. True so far as it goes, but I think a sharper focus comes from the desired results. I never spoke with anyone at Quasimodo, but I feel safe in expressing their goal this way:
Produce assembled widget vats that pass inspection and meet cost guidelines.
In fact, the original includes (on page 16 of 17) that kind of information:
I haven’t posted all seventeen pages, but it’s clear that this document was meant to guide two or three people, working in a factory, through the process of assembling a piece of equipment that would fill a roomy parking space. Those people handle the job from start to finish–this isn’t something that moves down an assembly line. The process involves more than 50 steps, and several of those are variations on “repeat steps 1 to 5 for all four edges.”
Many of those steps are sequences of actions with few decisions:
Position center end wall panel CAD on seembly fixture.
Use two people or a jib crane to life panels.
Check submittal [an assembly document ] for end wall connection and bottom connection orientation.
Fasten center end wall panel CAD to floor plane using 5/16 x 3/4 LG tappers.
Fasten center end wall panel CAD to floor support channel ZCA using 3/8 x 1-1/4 LG screws.
…and so on, and so forth…
My guess is that the instructions were printed, perhaps with the pages stuffed into sheet protectors and stored in a ring binder at the assembly area. So, like most procedural job aids, they’re like a recipe.
99 problems, and Excel’s just one
Since the assemblers weren’t using Excel when consulting the guide, this deranged choice for creating it doesn’t matter all that much to them. Using Excel for text layout, however, needlessly and foolishly complicates the task of updating, revising, and even searching the source document.
More than that, layout is not even well-done within the parameters of Excel. Here’s a detail from page 5, above. Note that there are two callouts labeled CA. The accompanying text refers to CAA, CAB, and CAF.
If you had the original file, as I do, you could enlarge those callouts–the text just ran outside the space of the callout box. The assemblers could not. Whoever created this was, let’s say, not at high strength for proofreading.
The real reason that Excel is a poor choice here, though? Nothing calls for Excel. There isn’t a single calculation in the entire document. You might just as well have created the guide with photos of alphabet-letter magnets arranged on your fridge.
Other drawbacks (and they are many)
From a graphics standpoint, the widget vat guide stolidly assigns equal weight to task photos and procedural steps. They get the same amount of space, whether they need it or not.
Similarly, half of each page is take up by six equal-sized boxes, one of which (“quality”) reads “n/a” on every page but one.
So most of the time, a third of the page is doingnothing–other than confining the actual instructions to an all-capital prison.
Other barriers to effective performance:
“Before you begin” information (like equipment you need and parts you should have) comes after the steps of the procedure.
Visuals are marooned in a reserved parking space instead of positioned near the step they illustrate.
Actual steps (the heart of a procedure) are distributed across a trio of all-caps, non-indented, top-to-bottom centered boxes:
Did you notice in the detail that step 5 says “repeat steps 1 – 5?” No doubt the assemblers figured out that they didn’t need to repeat that forever, but no thanks to the designer of the guide.
* * *
In summary, the widget vat assembly guide is hard to read, hard to follow, and hard to update. It’s not going to improve the process of assembling vats, at least not till the workers have done enough of them that they don’t need the guide any more.
In the next post, we’ll move on to what we’d change and why we’d change it. Spoiler alert: we won’t be using Excel.
(A makeover: the after version. Here’s the before.)
In the previous post, I showed a fictionalized example of an actual guide for assembling a piece of industrial equipment. The original, written on seventeen sheets in an Excel workbook, had more than 50 steps. I didn’t fictionalize them all, and I haven’t tried to revise them all. I’ve done two pages that cover what 5 of the original pages did. I think these revisions are representative. (You can click each image to open a full-sized version in another window.)
By the way: I don’t have any documentation other than what’s in the original widget vat instructions. In some places, I’ve made an educated guess about details that aren’t clear; in other cases I made things up. I’ll point these out along the way.
On to the revision!
How we got here
There are a lot of steps to follow in assembling a widget vat. Based on their number, and their occasional complexity, and on my assumption that speed is not a major factor, a job aid makes sense.
And many of my revisions are part of what any good job aid should include.
A clear title
The original title, “Main Assembly Instructions,” was at best ambiguous, unless Quasimodo Corporation only assembles one thing.
Here I’m imagining that there are several models of widget vats that differ mainly in size. I’ve put the model numbers into the title so the assemblers can tell easily if these are the instructions they want.
First things first: safety and prerequisites
Every page of the original version had a box listing the same three pieces of safety equipment–as if the developer thought the assemblers might take off their safety glasses between pages 11 and 12. I’ve put them at the beginning, on the assumption that you shouldn’t be roaming the plant without your safety equipment.
I’m also assuming that the “submittal drawing” spells out things like how many fasteners you need of each type. If that were not the case, I’d have to find out from my client whether (for example) the fasteners were stored at the assembly point, and if so how the workers could get more when they needed.
Emphasizing what’s important
The original version didn’t make much effective use of contrast, alignment, or spacing, so it’s much harder to figure out what’s important. And USING ALL CAPS IS PRETTY MUCH SAYING “WHO NEEDS EMPHASIS?”
Good job aids use emphasis techniques (like capitals, boldface, or italics) in specific, consistent, limited circumstances. One of the most obvious circumstances is to highlight warnings and exceptions–DO NOT, EXCEPT, UNLESS, DANGER, and so on.
Don’t confuse people with detail
The original used over 50 photos; in my revision I’ve hardly used any. In part that’s because I didn’t have good replacements for the photos–but also because many of the original photos fail to contribute useful guidance.
One problem with the original images–and with photos in general–is that they often provide too much detail, making it hard to grasp what’s important. Or they ignore context, also making it hard to grasp what’s important.
Take a look at these three examples from the original (click to enlarge):
Left: Why do I need to see a picture of the parts cart? The instructions say it’s important to push rather than pull the cart–but they don’t say if there’s a specific end I should push from. If there is, show it. If there isn’t, spell that out.
Center: you might be able to figure out, after studying this picture, that you’re viewing the assembly area from the side–but you can’t tell whether the top of the assembled widget will be on the left or the right.
Right: the instructions tell you:
CHOCK ONE (1) WHEEL ON EACH END OF EACH VAT ASSEMBLY FIXTURE (FOUR (4) CHOCKS TOTAL).
In my first revision, I’d missed the “four chocks total” part, which implies that neither the all-caps approach nor the FOUR (4) text/numeral approach helped.
Although I didn’t have much to work with, I have a couple of examples of images I think would work better.
The top picture in “image detail” shows a closeup helpful for one assembly step: the flanges should face up, and they should face out from each other.
(Yes, I made up the term “bleem flange.”)
The lower picture is a line drawing rather than a photo. Line drawings are a great way to eliminate unnecessary detail. I’ve teried to reduce details to the essentials: you’re fastening two (more-or-less) L-shaped pieces together, and you fasten through holes that alternate large/small/large/small.
(I’ve made the assumption here that the assembler should alternate directions when fastening these things: one fastener from one side, the next from the opposite side. If it were important to do that alternating while fastening, I’d add a box to spell that out. If you can install all the fasteners from one side, and then from the other, I’d spell that out. )
Some problems in the original version stem from the decision to always use three photos per page in the original. That’s a lot like deciding that you need to use one semicolon per paragraph: not wrong, exactly, but needlessly specific.
What I’d do instead:
Leave out the cart photo. My assumption: the assemblers know what the parts cart looks like. If they don’t, they shouldn’t be assembling widget vats.
Possibly include a close-up of the portion of the cart that I’m supposed to push, assuming there’s some sort of handle or push plate.
Use a bird’s-eye-view line drawing to show the layout of the assembly area.
In the text for this step in my revision, I made up some floor guidelines to show “top” and “bottom” of the assembled widget.
I also made up guidelines on the frame to show where to place some of the initial pieces.
Clarify where to place the wheel chocks.
Chock one wheel of each assembly fixture.
Written this way, it doesn’t matter how many fixtures you have, so you don’t need the FOUR (4) business so beloved by people writing procurement specs.
Place the chock so it’s closer to the center of the fixture than the wheel it’s touching. (If this is a best practice; I have no idea.)
Trying to build a useful set of performance guides like this can be a tool for analysis tool as well. You can’t create a successful guide without knowing what the inputs are, what the process is, what the outputs are, and what the standards for success are.
How many assembly fixtures do I need? On the framework, which side represents the top of the assembled piece? Can I install 20 fasteners in one direction, all in a row, and then 20 in the other? And what the hell is a “submittal drawing,” let alone the cryptic “BOM?”
What’s more, you can identify items that don’t need to be in the guide. Frankly, I think it’s…perhaps less than helpful to list “vat part cart” as an assembly aid. That’s like saying, “In order to build your IKEA Poang chair, buy the Poang chair and bring it home.”
In a sense, it’s easy to build a job aid for a procedure or for guiding decisions. Tasks like that tend to have a specific audience working toward a specific outcome. I want to share ideas on how to develop a reference job aid, using the weather-temperature converter I wrote about as an example.
Reference job aids collect and organize information. They might have just one such set, like the Fahrenheit-to-Celsius converter, or many, as with the w3schools.com HTML reference (an alphabetical list, a category list, an attribute list, and a dozen others).
Even if you know some of the material that will go into the reference, it’s good to spend time thinking through its purpose.
Who’s going to use it? What for?
Stated as a formula, and then filling in for my example, the purpose of the converter job aid is:
To guide X in accomplishing Y
To guide a Celsius-using person in understanding temperatures in Fahrenheit
That’s not bad, but for the job aid I had in mind, clarity came from building context in.
To guide a Celsius user in understanding weather temperatures in Fahrenheit
It actually took me three or four drafts to get to that, which suggests context isn’t always obvious. More important, context can suggest that you need more than one reference. The context informs the task analysis, and in some cases refines it.
In the case of my converter, context led to these design considerations:
My original audience was people traveling to a conference. They weren’t scientists or engineers looking for highly accurate measures; they wanted an idea of how hot or cold it was outside, so close enough was good enough.
Along those lines, I wanted to help with ambient-weather temperatures, not a wider range. No need for the boiling point of water or the freezing point of mercury.
I wanted the reference to be easy to use, which would increase the likelihood that it would be used.
Context leading to design
Since close enough was good enough, I could use bands of temperatures instead of a chart in one-degree increments. For most of North American, an overall Fahrenheit range of zero to 100 covers the territory pretty well. And as it turns out, a span of 10 Fahrenheit degrees is about 5.5 degrees Celsius.
Putting those together:
It was 83 degrees in Las Vegas one day during the conference. A Celsius user could:
Skim down the left-hand column
Read across from 80 to 27
Guesstimate the temperature at about 28 Celsius (it’s a little more than 80, so it’s a little more than 27).
It doesn’t hit 27 Celsius that often in most of Canada, but Canadians have a sense of what 27 means — in the same way that it doesn’t hit 98 that often in upper Michigan, but someone living there knows 98 is “hot,” and significantly hotter than 88.
Often more than one reference
Many times you can organize the same reference information — or a subset of it — in multiple ways: HTML codes alphabetically, HTML codes by category. There are many different people who use HTML codes, and their reasons for looking up the codes can vary, like interpreting a tag in someone else’s code, or checking what the values are for a particular attribute.
Having created the F-to-C converter, I saw the obvious possibility of a converter for C-to-F (to help Fahrenheit users understand weather temperature given in Celsius).
Most of the time, I think a given individual would use only one of these — people already understand the weather in the temperature scale they’re accustomed to. But a person might want to convert her own system when communicating to someone in the other.
That’s the nature of references: you can’t always be sure who’s consulting them, or why. The “task” is much more amorphous than, say, assembling IKEA’s Billy bookcase, which makes it worth your time to ponder the two aspects of a reference job aid’s purpose: who’s going to use it? What for?
This is the first in an occasional series in which I’ll improve an existing job aid and explain the reasons for the changes.
This is a fictionalized version of a table found in a user manual for some electronic equipment. I’ve changed details to refer to the (imaginary) MacLellan Weight Monitor, a type of checkweigher. The Weight Monitor checks the weight of boxes of pharmaceuticals on a packaging line. (I’ve put some background at the end of this post, but it’s not essential to the job aid makeover.)
The original job aid is a reference to show various statuses that the Weight Monitor can have, as well as the indicator lights that display for each status. I’ve rewritten some of the statuses here, but the language of the original is similar.
What’s wrong with the original?
Purpose: What’s the table for?
A technician might say “it tells you what status the different lights represent,” but the way it’s set up, it really tell you “if the status is X, then the lights will be Y.” On the job, the user can already see the lights; he wants to know what they mean.
Language: It’s not obvious from the table, but the typical user will not be familiar with terms like initialization, configuration, to say nothing of parameter failure. Too many engineers, not enough packaging line operators.
Title: not helpful. As is, could just as well be left off.
Organization: How is this table organized? Not by sequence, not by frequency, not alphabetical by status, and not alphabetical by color.
What and why
Purpose: explain what the Weight Monitor’s lights mean.
The new version shows the when/then principle in action: start with what the worker sees or receives or experiences — in this case, the colors of the lights. So colors go on the left: “WHEN the light is flashing red…”
Once you have the color, you move to the meaning: “THEN there’s a jam where the packages exit the Weight Monitor.”
In the original version, the layout was backwards: the left column showed meanings, and I had to skim each one and check its color in order to figure out what a flashing red light meant.
Starting with “device status,” which is now “what it means,” I’ve rewritten several items to be clearer from the worker’s point of view. “Parameter failure” was the engineering way to say that a package didn’t fail within the minimum / maximum weight range. Either way, the Weight Monitor will bump the package off the line and flash red and yellow lights. “Package over or under weight” is clearer.
As simple as it seems, “Weight Monitor status” sets the table in context. What the engineers called indicator lights are meant to show the status of the machine in the workplace.
…As for organization, this first draft has the same order (or lack of order) as the original. I can see a number of ways to arrange the rows, such as by sequence in the process. But in a second pass, I went with color:
Makeover, version two
There are a lot of colors here. I decided to put the single colors first, in green-yellow-red order, followed by the combinations. In the case of those multi-color states, “flashing red and yellow,” like most of the items above it, relates to the operation of the packaging line. The last two combinations are one-time indicators that you’d see when you started the device up (initialization) and once you’d entered the programming for the specific item you were packaging (configuration).
Background on the Weight Monitor:
As part of the packaging process, Dosage Pharmaceutical programs the Weight Monitor with an acceptable weight range for one packaging unit. For example, when the line is packaging physician samples for 200-milligram doses of Nullaproxin, the package unit is one carton, and the weight is based on:
– The carton itself, its label, and its seal – An eight-page information package for the physician – 24 wallets (the medication sample package given to a patient)
Each wallet is made up of a cardboard case, 14 plastic blisters (thermoplastic bubbles and foil backing), one tablet per blister, and an information sheet for the patient.
Each carton moves onto the Weight Monitor. If the carton is too light or too heavy, based on the configuration for the specific product, the Weight Monitor bumps the package into a bin for a worker to determine and remedy the problem.
If you know certain details about a task, you can decide whether it makes sense to build a job aid.
Part 1 of the decision considers whether you have to build a job aid, even if it doesn’t make much sense, and whether certain characteristics tell you that a job aid won’t work.
“Is a job aid required?” isn’t as daft as it might seem. If your organization mandates a job aid for some task, then you’re stuck. Unless you convince the right people to reverse the policy, somebody’s going to be building a job aid. If that’s you, you might as well get started, and you don’t need to read the rest of this piece; your decision has been made.
Assuming that a job aid isn’t mandatory, the next question is whether speedor rateis a critical factor in performing the task. The short answer is that if speed matters, a job aid isn’t going to work.
Many jobs call for you to apply knowledge and skill in quickly, even if not predictably. Think about safely driving a car through a tricky situation, much less an emergency. You don’t have the opportunity to consult a job aid. If a kid on a bike suddenly pulls out in front of you, you can’t look up what to do.
Anyone who’s helped train a new driver knows what it’s like when the novice is trying to decide if it’s safe to turn into traffic. We experienced drivers have internalized all sorts of data to help us decide without thinking, “Yes, there’s plenty of time before that bus gets here; I can make the left turn.”
The newcomer lacks that fluency. She’ll acquire it with practice, but not via a job aid. The need for speedy performance gets in the way.
Likewise for rate–a sustained performance over time. Routinely high-volume work like factory production or air-traffic control doesn’t allow time to consult a job aid. Success depend on learning–on committing skill and knowledge to memory, and on retrieving and applying those things appropriately.
I’m a fast typist (80 – 85 words per minute if I’ve been writing a lot), but the moment I glance down at the keyboard, my rate drops. The visual signal interferes with the virtually automatic process I normally use at a keyboard.
Part 2 of the job aid decision looks at the characteristics of the task at hand. Factors like complexity and risk of error help you make the decision, which is why I call this step:
Use what you know about the task to figure out whether building a job aid makes sense. You can go about this in many ways, but the following questions quickly cover a lot of the territory.
♦ ♦ ♦
How often does someone perform the task?
“Often” is a relative term–in fact, most of the questions in Ask the Task are relative. That doesn’t mean they’re not pertinent. Asking “how frequent is frequent?” turns your attention to the context of the task and the people who typically carry it out.
Frequency isn’t the same thing as regularity. Some tasks are frequent and predictable, like a weekly status update. Some are more random, like handling a payment by money order. And some are much more rare, like a bank teller in Vermont handling a money transfer from Indonesia.
Whether you end up building a job aid, designing training, or just tossing people into the deep end of the performance pool, you need some idea of how frequent “frequent” is, and where the specific task might fall along a job-relevant frequency scale.
Think about what frequency might tell you about whether to build a job aid. (Yes, now. I’ll have the mini-lecture later on, but we both know you ought to do some thinking on your own. Just like we know certain other people are going to breeze past without doing that thinking.)
♦ ♦ ♦
How many steps does the task have?
Some tasks don’t really seem to have steps. Or they have very few: look up the arguments for the HTML <br> tag. And some tasks have so many that it might make sense to break them up into logical subgroups: setting up the thermoformer. Testing the thermoformer. Troubleshooting problems after the test.
So, think of “step” as the lowest level of activity that produces a result that makes sense to the performer. If I’m familiar with creating websites, then “create a new domain and assign it to a folder in the \public_html directory” might be two steps, or maybe only one). If I’m not familiar with creating websites, I’m going to need a lot more steps.
That makes sense, because a job aid is meant to guide a particular group of performers, and the presumption is that they share some background. If the performers have widely differing backgrounds, you may need two versions of a job aid–see the Famous 5-Minute Install for WordPress and its companion, a set of far more detailed instructions. Essentially, that’s two job aids: the 5-Minute Install for experienced people, and the lengthier details for newcomers.
As with frequency, you need to think about how many steps in the tasks are few or many, relatively speaking.
♦ ♦ ♦
How difficult are the steps?
For someone who writes a lot and who has solid, basic word processing skills, writing a 25-page report has plenty of steps, but few of them are difficult (other than getting reviewers to finish their work on time).
In the same way, a task can have relatively few steps, but many of them can be quite difficult.
That’s the reason for two step-related considerations in Ask the Task: are there a lot of steps? Are the steps hard?
Pause for a moment and think which way you’d lean: if the steps in a task are difficult, does that mean “job aid might work,” or does that mean “people need to learn this?”
♦ ♦ ♦
What happens if they do it wrong?
This question focuses on the consequences of performing the task incorrectly. Whether a person has a job aid or not is immaterial–if you don’t perform correctly, what happens? Personal injury? Costly waste or rework? Half an hour spent re-entering the set-up tolerances? Or simply “re-enter the password?”
As with the other questions, you need to think about the impart of error in terms of the specific job. And, if you haven’t guessed already, about the relationship between that impact and the value of building a job aid.
♦ ♦ ♦
Is the task likely to change?
We’re not talking about whether the job aid will change, because we still haven’t figured out if we’re going to build one. We’re talking about the task: What are the odds it’s going to change? “Change” here could include new steps, new standards, new equipment, a new product, and so on.
♦ ♦ ♦
You’ve probably detected a pattern to the questions. So the big secret is this:
The more your answers tend to the right, the stronger the case for a job aid.
What follows is the 90-second version of why. (As your read the lines, just add “all other things being equal” to each of them.)
The less frequently someone performs a task, the likelier it is that he’ll forget how to do it. If you’re an independent insurance agent whose practice mostly involves homeowner’s and driver’s insurance, and you write six flood insurance policies a year, you could probably use some task-related support. Job aids don’t forget.
The more steps involved in the task, the more challenging it will be for someone to retain all those steps correctly in memory and apply them at the right time. Job aids: good at retention.
The more difficult the steps are, the harder the performer will find it to complete each step appropriately. A job aid can remind the performer of criteria and considerations, and can provide examples.
The higher the impact of error, the more important it is for the performer to do the task correctly. You certainly can train people to respond in circumstances like air traffic control, emergency medical response, or power-line maintenance. You do that when the on-the-jb situation (up on a utility pole) or the time-to-perform justify the expense of learning. Otherwise, a well-designed job aid is a good way to help the performer avoid high-cost error.
The more changeable the task, the less sense it makes to train to memory. That’s because when the change occurs, you’ll have to redo or otherwise work at altering how people perform. If instead you support the likely-to-change task with job aids, you’re avoiding the additional cost of full training, and you mainly need to replace the outdated job aid with the new one.
♦ ♦ ♦
A recap of those questions:
The first two parts of the decision ask:
Is a job aid mandatory? If not, does speed or rate make a job aid unlikely?
Do the tasks’s characteristics suggest that a job aid makes sense?
Getting this far, you might want to leap right into design. But people don’t perform a task within an environment.
Part 3 of your decision is to ask if that environment will hamper the use of a job aid.
You could ask these question in either order, but physical barriers are sometimes easier to address than social ones.
Often people have to work in settings where a job aid might be a hindrance or even a danger. Someone rewiring an electrical panel, for example. Or someone assembling freight trains at a classification yard:
As the narrator points out around the 4:00 mark, in the 19th century a railroader would have to ride each car as gravity moved it down a manmade hill (the hump), applying the brake by hand to keep the car below about 4 miles an hour. It would have been impossible to give the brakeman a job aid for slowing the car, so his training (formal or otherwise) would have required lots of practice and feedback about judging speed.
Remember, the goal is not to have people use job aids; the goal is to produce better on-the-job results.
Modern railroads rely mainly on computers and sensors to control speed when assembling freight trains, rather than either job aids or training to memory.
Another way to overcome physical obstacles to the use of a job aid is by changing the form. No law requires a job aid to be on an 8 1/2 by 11 inch laminated piece of paper. Nor on the formerly ubiquitous, multifolded paper of a highway map.
A road map can support different kinds of tasks. You can use it at a table to plan where you’re going to go, to learn about the routes. No barriers to such use.
If you’re driving by yourself, though, a paper road map is at best sub-optimal. It’s hard to use the map safely while you’re driving.
Real-time support for the driver now includes geosynchronous satellites, wireless technology, a constantly updated computer display–and a voice.
That voice is transformative: it’s a job aid you don’t have to read. Because the GPS gives timely, audible directions, there’s no need to take your eyes off the road and decipher the screen.
Other examples of overcoming physical barriers: attach the job aid to equipment. Use visual cues, like a change of color as movement or adjustment gets closer to specification. Combine audio with voice-response technology (“If the relay is intact, say ‘okay.’ If the relay is damaged, say ‘damaged.'”)
But he had to look it up!
Overcoming physical barriers is one thing. Overcoming social barriers is…a whole bunch of things. Your job aid will fail if the intended performer won’t use it.
Popular culture places a great value on appearing to know things. When someone turns to an external reference, we sometimes have an irrational feeling that she doesn’t know what she’s doing–and that she should. In part, I think we confuse retention of isolated facts with deep knowledge, and we think (reasonably enough) that deep knowledge is good.
At its worst, though, this becomes the workplace equivalent of Trivial Pursuit. A railroading example might be someone who can tell you not only the trains but the kinds of locomotive that ran on a certain line decades ago–but who can’t issue you a ticket in a prompt, accurate, courteous manner.
This bias toward recall may come from the performer herself–she may think it’s better not to “have to” use a job aid.
Or coworkers may have that bias–only a rookie need to look things up. Managers and even clients may prefer not to see the performer using a job aid.
One path to overcoming is bias is to embed the job aid in a tool or application, such that the performer is merely applying one feature. That’s essentially what a software wizard does. Watch me turn this data into a chart: I just choose what I want as I go along.
(And doesn’t “choose what I want” sound much more on top of things than “look stuff up?”)
Joe Harless, from whom I learned a great deal about job aids, gave the example of an injection gun used for immunizations in third-world settings, healthcare workers occasionally had to make adjustments to clear jams and similar equipment glitches.
Senior workers did not want to seem to need outside help to maintain their equipment, but couldn’t retain all the steps. (Remember in Part 2? Number of steps in task, complexity of steps?) So the clearing instructions were attached to the equipment in such a way that the worker could follow the job aid while clearing the gun.
♦ ♦ ♦
The considerations here aren’t meant as either exhaustive or exclusive. They are, however, important stops to make, a kind of reality check before you hit the on-ramp to job aid design. The reason for building a job aid is to guide performance on the job while reducing the need for memorization, in order to achieve a worthwhile result. If the performer can’t use it because of physical obstacles, or won’t use it because of social ones, the result will be… no result.
A decision table organizes information to guide someone through a decision. The two main categories of information are the conditions (“if you have this…”) and the decisions — the actions to take (“…then do this”). Often there are multiple categories of conditions, as in this example, a decision table for calculating flood insurance premiums:
There are three categories of conditions: the type of building, the nature of the coverage, and the maximum amount of coverage. A set is my term for the combination of conditions that leads to a specific action. In the table above, “other residential,” “additional,” and “maximum $100,000” is a set that leads to a particular premium calculation ($ 1,425 plus $0.30 per $100 for coverage over $150,000).
This post will show you one technique for identifying conditions, grouping them into sets, and arranging that information into a useful decision table.
We want to build a decision table help our sales staff know what price to offer customers. You’ll notice that for this exercise it doesn’t matter what the products are, or even what the business is, as long as we can identify the conditions and the actions.
Step 1: List all the possible decisions.
The individual decisions are all the possible actions or outcomes for offering a price. There are three: the VIP discount, the courtesy discount, and the standard price.
You can start your analysis with conditions if you like, but in my experience it’s a lot easier to get agreement on the actions.
By the way, this job aid doesn’t deal with what the discounts are, just when to offer them. You can decide which price to offer without knowing how to compute that price–which underscores the need to think about the task you’re guiding. Maybe you have one job aid for a complex task (choosing and calculating the price), or maybe you have two (how to choose, and then how to calculate).
We’ll stick with a simple example.
Step 2: For each decision, list each set of conditions that applies.
A set is a list of the specific conditions that lead to a particular decision (When the person is already a customer and when his credit code is 1, then offer the VIP discount).
As you analyze the task, each set gets its own row, even if it leads to the same decision as another set.
Each condition in a set has its own column, with the decision in the rightmost column.
The example has three sets of conditions under which you offer the courtesy discount. Each set gets its own row. Repeating the decision this way highlights the different routes to reaching that decision.
Also, in a given set, all the conditions must be satisfied in order to trigger the decision. Being an existing customer is not by itself enough to justify the VIP discount; a price over $999 is.
The company’s procedures didn’t spell out “all others” as a specific type of customer; we derived that from what to do if a customer didn’t meet the conditions for either of the two discounts.
Step 3: Arrange similar conditions into columns.
The information in this table is the same as in Step 2. The difference is that we’ve moved related conditions so they’re grouped in columns. Each column is a category–often pretty loose, at first, as you figure out what the various conditions are.
Step 4: Reorganize the conditions.
Some ways to do this:
Study the columns to see if one stands out as a first cut. If so, move it to the leftmost position. (In the example, Customer seemed like a good start, so it stayed on the left.)
Rearrange rows so identical conditions adjoin one another in that leftmost column.
Move to the next column. Again, consider rearranging the order of columns. You’re now filtering from a particular condition in the leftmost column. (In the example, there are three possible sets of conditions that apply to existing customers; two sets that apply to any customer.)
If you have more than four categories of conditions (more than four when columns), consider using multiple tables. If that were the case here, I might have two decision tables, one for existing customers and one for new ones.
Step 5: Add headings that make sense on the job.
You might have had headings in the previous step–they’re a good way to guide analysis and tease out what a category is really about. Here, we’re moving from analysis to job aid, and so we want headings that help a person on the job.
It’s good to eliminate repetition, so we’re trying Customer and Credit as headings.
Here’s the next version: it pulls the word “code” out of four cells, making them easier to read.
Step 6: Simplify the table.
In the leftmost column, we’ve merged identical conditions. As a person consults this job aid, she’ll decide whether she’s dealing with an existing customer. If she’s not, she can ignore the three sub-paths.
Use dashes, arrows, shading, or similar formatting to make clear that certain conditions don’t apply.
Note that the example specifically did not merge the adjoining “courtesy discount” cells in the decision column. In many cases, I think it’s worth giving each set of conditions its own actions.
By the way, here’s the same decision table with the customer conditions switched:
The logic here is that for any customer, you can offer discounts based on price, and for an existing customer, you can also offer discounts based on other conditions. To facilitate this, I moved Price to the second column; it was the category most closely related to the first Customer condition (‘any’).
Those are the basics. Some thoughts about this approach:
It’s a great analytic tool, especially when collaborating with others. Agreeing on the outcomes (Step 1) and working out sets of conditions (Step 2) can be frustrating and highly iterative, but progress is easy to spot.
It’s a tool, not a law of physics. You can combine Step 2 (identifying sets) and Step 3 (organizing conditions into columns). If you’re doing this electronically, with a word processor or even a spreadsheet, it’s not much work to move things around as circumstances demand.
It’s a great confirmation tool. Once you’ve got a working draft, a skilled performer or a subject-matter expert can try it out. Misunderstandings, omissions, and new sets of conditions emerge quickly.
When you’re building a job aid, pay attention to how you present and structure the information. Job aids don’t usually explain why to do something; they guide the performer about when and how to do something.
(Although I’m discussing features in general, you can click here to open a copy of the entire job aid in a new window.)
By the way, this is a fairly large job aid; it’s meant to avoid page-turning and could easily be a poster mounted so that the tester can view it while conducting the test. Notice that “avoid page-turning” doesn’t mean “keep to a single 8.5 x 11 page.” Not every job aid has to fit into a 3-ring binder.
♦ ♦ ♦
A clear, task-focused title
What makes this title good? For one thing, it passes the “hey, Dad” test:
Hey, Dad — watch me while I do the rapid test for malaria.
In other words, the title explains the job aid in terms of what the person using it will do. This approach is essential in a job aid guiding some task. Consider alternatives like:
Using the Rapid Test
Basics of the Rapid Test
Steps in the Rapid Test
None of these has the directness of “how to.”
♦ ♦ ♦
First things first • Consistent emphasis • Graphic cues
Directly under the title of the job aid, you find a list of supplies needed for the test. This is the equivalent of the list of ingredients at the start of a cooking recipe.
Because the rapid-test job aid deals with a medical topic, it consistently calls attention to words like “new” and “unopened.” “New” is always in bold capitals here; “unopened” is always in bold.
The job aid does not depend on color alone to convey meaning in the text; if you reproduced these steps in black and while, the capitalization and bolding would still convey emphasis.
In addition, the job aid includes graphic illustrations of the materials, in part as a reminder for the community workers who will be conducting the tests. Some may have limited skill in reading, and so the illustrations and labels support their ability to recognize what the test packet is.
Often a drawing rather than a photograph is more effective; line art can retain essential information without bringing in unnecessary detail. It’s much more important for the community worker to recognize an unopened lancet than to be able to read on the job aid the printing on the lancet package.
♦ ♦ ♦
Numbered steps • Separation between steps
If you need to perform steps in a particular order, you have a sequence. Use numbering for the sequence. In general, a numbered sequence is easier to keep track of than one with letters.
♦ ♦ ♦
Performer’s point of view • Callouts
Because the purpose of a job aid is to guide performance on the job, graphics need to show examples or technique from the point of view of someone doing the job. Note the hands under step 2 in the illustration above: they look the way your hands would if you were putting gloves on.
This job aid makes careful use of callouts — they appear only when they’re important for a particular step. At the beginning of the job aid, for instance, there’s an image of the test packet but no callout for the expiry date. It makes more sense to check the date right before you’re ready to start.
♦ ♦ ♦
Step size: can be done without rechecking
If you’re building a job aid to guide steps in a procedure, a good rule of thumb for any one step is that the performer should be able to complete it without having to refer to the job aid again.
It’s not that he shouldn’t refer to it. The point is to avoid overburdening him.
In this example, step 3 spells out what you’re removing from the test packet. That’s all that it contains. If the instruction read, “Remove everything from the packet,” though, the performer has no idea what the packet should contain.
What if there were no desiccant (say, due to a packaging error)? Because step 3 tells me I need to remove the test cassette, the capillary tube, and the desiccant, if I don’t find those things, I’m pretty sure something’s wrong.
♦ ♦ ♦
Special emphasis for safety / hazard / high-risk information.
This is a special case for the consistent emphasis mentioned earlier. Some procedures have steps that are highly important in the context of carrying them out. In this example, the entire sentence for “don’t set the lancet down” appears in bold.
By the way, preparing community workers to conduct the rapid diagnostic test involves more than the job aid. The training includes actual practice, including use of the lancet. The training would reinforce the importance of proper procedure and correct handling of the lancet and the capillary tube (which also goes into the sharps box).
♦ ♦ ♦
The features mentioned here are not a complete list, and not every one is essential for every job aid. On the whole, though, if a job aid doesn’t include most of these features, it’s likely to be less effective in supporting performance.
A few months ago, I came across a series of “field guides” related to voting. These were developed by Dana Chisnell of UsabilityWorks as a result of research she conducted with Ginny Redish for the National Institute of Standards and Technology.
I’m particularly interested in this topic because I worked as an election judge (the Maryland term for a precinct worker) during four elections, including two as a chief judge (one of the two chiefs at my precinct).
I’m pretty sure most voters have no inkling of the multitude of tasks and procedures that precinct workers — almost always volunteers, despite a small stipend for their effort — must try and carry out in order to ensure that people can exercise their right to vote.
The Field Guide series, “essentials that local election officials” can use when trying to apply ballot design guidelines to real life, have been edited by Dana Chisnell of UsabilityWorks. From Civic Design’s site you can download PDFs of four guides:
I want to highlight some of the recommendations from “Writing Instructions Voters Understand.” These make great sense in most job-aid and performance-support contexts, and the Field Guide provides detailed examples for the individual recommendations.
You can’t tell easily from the PDF, but in the printed Field Guide, illustrations and examples appear on the left-hand page, and instructions on the right, like this:
So you see the example in context on the left, and then you get details about it on the right.
At the beginning of the ballot, explain how to change a vote, and that voters may write in a candidate.
I think of this as a “before you begin” instruction. The voter might not be thinking about making errors or changing her mind; having this notice at the outset increases likelihood that she’ll recall it during the voting process.
Put instructions where voters need them.
This advice could sound like “be nice,” but the Field Guide gives specific examples:
Break instructions into groups. (No lumbering blocks of text.)
On paper ballots, put turn-over instructions at the bottom right-hand corner.
On electronic ballots, put instructions for writing in a candidate on the write-in screen.
Include information that will prevent voters from making errors.
Here’s a before-and-after approach that shows the stark contrast between insider focus and customer (or voter) focus:
If you tear, or deface, or wrongly mark this ballot, return it and obtain another. Do not attempt to correct mistakes on the ballot by making erasures or cross outs. Erasures or cross outs may invalidate all or part of your ballot. Prior to submitting your ballot, if you make a mistake in completing the ballot or wish to change your ballot choices, you may obtain and complete a new ballot. You have a right to a replacement ballot upon return of the original ballot.
If you make a mistake, ask a poll worker for another ballot.
Use short, simple everyday words.
While I do enjoy the occasional eyeroll in the director of St. George of Orwell’s prescriptionism, Chisnell’s definitely on the right track.
Particularly with the example: Avoid jargon, such as “over vote,” “under vote,” and “partisan.”
Write in the active voice, where the person doing the action comes before the verb.
Note that this guideline is itself an example of avoiding jargon. The average person isn’t good at providing an example of an active verb as opposed to a passive one.
Write in the positive.
Directly from the guide: Tell voters what to do rather than what not to do.
If that oval is not marked, your vote cannot be counted for the candidate.
You must fill in the oval for your vote to count.
When giving instructions that are more than one step, make each step an item in a numbered list.
It’s a lot harder for people to keep track of where they are in a bulleted list than in a number one.
When steps are a sequence, number the steps. That’s what the numbers are for: showing each item’s place within the sequence.
If sequence is not important, then use bullets.
An everyday example: the ingredients in a recipe appear before the steps. The ingredients are usually listed in the order you’ll use them, but they don’t have to be, because (presumably) the steps in the recipe will tell you when to add the carrots and when to add the vinegar.
My thanks to Dana Chisnell for agreeing to have the Field Guides included in the Ensampler.