Documents and other tools that the public interacts with are a kind of performance support; the goal is to help people accomplish things 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.
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?
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.
Even conceding that many of the “blended learning” hits are from formal education (schools, academia), it’s a little depressing that only 3% of them mention job aids. I personally doubt it’s because everyone uses job aids. It’s almost as if developers, yearning to produce ever-more-engrossing courses, are blind to this kind of performance support.
This is closely related to what Cathy Moore says in the opening minute of the following clip:
And here, at 4%… is what is possibly the least expensive and most effective approach [for blended learning]: on-the-job training tasks. Apparently we are still stuck in the mindset that training is a course.
The clip actually covers a lot of territory in six minutes, including realistic tasks, application, relevant examples, and so on, but I want to focus here on the aspect of figuring out how not to train — or, more accurately, how to not train. Cathy demonstrates the use of “a mega job aid” to enable on-the-job learning. This is her term for combining a job aid (which stores information or guidance so you don’t have to remember it) with instruction (which tells you how to apply what’s in the job aid to a specific task).
I asked Cathy for some comments about job aids.
“Before designing formal training, consider whether a job aid is all you need.”
Here, she’s asking what makes you think you need formal training for X? Is there another way to help people accomplish the desired result?
“If you decide training is necessary, make sure the job aids are top-notch, and consider having the ‘course’ teach people how to use the job aids.”
It’s not a job aid if you don’t use it while you’re performing the task. So if you build a job aid but find that people need to practice using it, that practice should be like on-the-job use. They’re not going to be doing the real-world task from within the LMS (unless, poor devils, their real-work job is managing the LMS). Embalming a job aid inside a course is like disabling an elevator in hopes that people will learn how to get from the 3rd to the 9th floor without “cheating.”
“Don’t duplicate the job aid info in the course.”
Part of the decision about whether to build a job aid involves the nature of the task. Among the considerations:
The likelier it is that the task will change (and thus that the steps for accomplishing it will change), the more sense it makes to build a job aid — and the less sense it makes to duplicate the job aid inside a formal course.
Instead, as part of your formal training, use the same job aid people will use on the job. And figure out how to make updates easily available.
No matter what learning management ideology claims, there are only three kinds of people who return to an online course for reference information:
People who work for the vendor.
Actors appearing in the vendor’s materials.
People on the job who are really bored or really desperate.
Because she involves herself with what people actually do on the job, Cathy has some inexpensive yet highly effective ideas about where to get started:
To evaluate and improve job aids, physically visit learners’ work stations and look around. What support materials have people created for themselves? Often someone on the job has already created a good job aid and you just need to “borrow” it.
Even if it’s a less-than-ideal job aid, the fact that someone’s created it and is using it suggests both that the task is important and that people feel the need for support as they’re carrying out the task. That’s one heck of a head start, and you haven’t had to create a single “at the end of this training program” statement.