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?
Last year I traveled to a U.S.-based conference, the first time I’ve done so since moving back to Canada. It’s easy for Americans to forget that Canadians routinely use the metric system every day (gasoline in litres, road trips in kilometers, and temperature in degrees Celsius).
An American business traveler high up in a Vancouver hotel looks out one morning, sees nothing but clouds. He calls the front desk and asks about the weather.
“Cloudy all day, no rain, and a high of 14.”
After a pause, the traveler asks, “What temperature is that really?“
Mostly as a way of connecting with other Canadians at the conference, I came up with this chart:
Reference job aids like this aren’t geared to a specific task the way worksheets or procedure job aids are. This is a way to organize information so someone who has a general idea of today’s temperature in degrees Fahrenheit can figure out the Celsius equivalent.
Who’s referring to this, and why?
As Thomas and Marilyn Gilbert pointed out, when it comes to weather people don’t want to solve a mathematical equation; they want to know if they need a jacket. Explaining Celsius to Fahrenheit users, the Gilberts gave examples like 20 is plenty (“room temperature,” 68° F) and 30 is thirsty (“a thirsty hot summer day in New York,” 86° F).
The audience I had in mind was Celsius users attending a conference in Las Vegas. I wanted to offer a quick way to figure out the approximate temperature. Most of the time, in most of the U.S., a Fahrenheit range of 0 to 100 covers any temperature they’ll run into. Anything off the chart is way too cold or, as you see, too damned hot.
Two-way conversion? Maybe two charts
If you want, you can read right-to-left on the chart to see what 27° Fahrenheit is in Celsius. That’s less than optimal, I think. Typically we don’t read in that direction, and the examples in Fahrenheit aren’t as easily read as those in Celsius.
The flip side of C-to-F conversion for weather range temperature:
More to come
You’ve noticed the mnemonics in the chart; three of them in the C-to-F version came directly from the Gilberts. From a pure-reference viewpoint, they’re unnecessary, but as an aid to recall they offer a lot of potential.
I’ll return to that concept, along with some design-for-reference ideas, in a future post.
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.
A tech rider is an equipment-related checklist used by musicians and the venues in which they play. It’s a rider or addition to the performance contract.
A tech rider is a one-page document that gives the venue and/or soundman an understanding of what your technical requirements are and how to set up the stage before you arrive. It also gives them an opportunity to let you know if they can’t accommodate any of your needs.
Recently I came across the website of Rahul Samuel, an acoustic consultant and live sound engineer in Karnataka, India. He has a post on how to make the perfect tech rider for your band. Rahul was kind enough to allow his rider to be featured here at the Ensampler.
There are eight main parts–which is to say, the checklist has specialized sections based on a particular focus or concern.
The line up (band members, instruments, and tech requirements
Equipment / backline (the latter seems to mean the onstage amplifiers, which I understand are sometimes arranged in a line at the back of the stage)
Stage plot (a technical floorplan for the performance)
Input patch list (list of channels, instruments, and microphones, used by the sound engineer)
Monitor requirements (for the onstage speakers used by the band)
Special needs or requests
Band engineer’s requirements
Performers (not the musicians; the people using the checklist)
A number of people can make use of the tech rider. First, the person responsible for collecting the band’s requirements. A brand-new band can work with a sound engineer to learn about equipment and work up their own tech rider.
The other party in the performance is the venue, and probably a specialist like the venue’s sound engineer (on staff, or contracted).
Checklists, in whatever form they take, focus on completion, coverage, and verification. As Rahul says, “Tech riders are great, they not only bring the sound vendor and sound engineer up to speed, but also work as a brilliant check list for the band.”
So: the tech rider lets the venue know what the band’s needs are, how the stage should be set up, and so forth. If the venue can’t accommodate those things, both parties can deal with that situation ahead of time.
Rahul’s post includes requirements for the venue’s sound system and the FOH (front-of-house) console (sound mixer). There’s a great deal of technical information compressed into twelve lines; the goal is clarity and completeness.
Rahul’s post on the tech rider includes some tips that could easily be built into the form a band uses for its rider. Two of them are practical for form-type job aids in general:
Put the band’s name and tech contact information in the header, on every page.
Rahul mentions that when working at a festival, he’s received a patch list with no idea which band it was for.
Use “Page 1 of 4” numbering.
Far easier for someone to know if he’s missing part of the document.
On January 15, 2009, US Airways flight 1549, an Airbus 320, lost thrust shortly after takeoff and ditched in the Hudson River. The following year, the National Transportation Safety Board (NTSB) issued its report on the incident (summary,full report).
Thirteen seconds after the plane struck birds, captain Chesley Sullenberger told first officer Jeff Skiles, “Get the QRH [Quick Reference Handbook] loss of thrust on both engines.” (Skiles had recently been to recurrent training, and so Sullenberger believed the first officer could find the QRH more quickly.)
In everyday speech and in news reports, such tools are often called checklists, but because the Engine Dual Failure quick reference involves a sequence of actions, as a job aid I consider it a procedure. It’s a guide through a number of steps to follow when both engines of an Airbus fail.
At one level, the accomplishment here is to safely land the aircraft following the failure of both engines. Looking deeper, you can see that there are decision paths build into the quick reference.
Step 1 has to do with fuel.
“If no fuel remaining…” has eight substeps to complete before going on to Step 2.
“If fuel remaining…” is even more complicated, with internal decisions based on type of aircraft, ability to reach Air Traffic Control, result of trying to relight (restart) the engines; the longest path has fifteen substeps.
Step 2 (on the second of the three pages) hinges on whether the attempt to restart the engines was successful.
Step 3 deals with whether the aircraft will have a forced landing (that is, on the ground) or a ditching (an emergency landing in water).
This is a highly specialized job aid, intended for use by the flight crew of particular Airbus aircraft. It’s full of technical shorthand (FAC 1, OFF then ON; ENG MODE Selector, IGN) and directions aimed at skilled people (“Add 1° of nose up for each 22,000 lbs above 111,000 lbs…”).
Coping with emergencies: a performance dilemma
In an emergency, one risk is tunnel vision: becoming so engrossed with certain aspects of the situation that routine ones get overlooked. Job aids are one way to address this–if the performers are trained to rely on the job and, and the work culture emphatically supports their use, then it makes sense to store information and guidance in the job aid.
Skills that are time-critical, like the actual flight maneuvers, are the ones that you spend time learning (storing in memory).
The NTSB report acknowledges this, and notes a performance dilemma:
Accidents and incidents have shown that pilots can become so fixated on an emergency or abnormal situation that routine items (for example, configuring for landing) are overlooked. For this reason, emergency and abnormal checklists often include reminders to pilots of items that may be forgotten. Additionally, pilots can lose their place in a checklist if they are required to alternate between various checklists or are distracted by other cockpit duties; however, as shown with the Engine Dual Failure checklist, combining checklists can result in lengthy procedures. [NTSB report, p. 92]
I’ve written about Flight 1549 on my other blog. Some aspects are relevant to the example of this quick reference. For example, the reference assumed a higher air speed and a higher altitude than Flight 1549 had.
Sullenberger said later that although there was an additional reference for ditching the aircraft, the crew never got to use it. “The higher priority procedure to follow was for the loss of both engines,” he said in an interview. In other words, in their professional judgment, it was much more important to try and restart the engines.
So: on the one hand, you can’t infallibly job-aid your way through every possible situation. But neither can you infallibly train (work at storing in memory) through them all, either.
Side note: passengers and safety
Talking isn’t training, and listening isn’t learning. Despite the inescapable safety briefing on every U.S. commercial flight, only half the passengers evacuated with their “can be used as a flotation device” seat cushions. 19 passengers also tried to retrieve life vests from under their seats; only 3 succeeded.
And of the 30 who tried to put on a vest once outside the plan, only 4 said they could do so properly.
Nevertheless, without taking anything away from the safe ditching of the aircraft, the evacuation training that the cabin crew regularly underwent (so as to be able to perform from memory) had a great impact, though one much less widely acknowledged, on the survival of every passenger from Flight 1549.
HTML Arrows is a multifaceted reference tool created by Zeppelin.io. The quick summary: it presents codes for displaying symbols in a number of different formats. In the screen shot above, on the left, you see the left-arrow symbol ( ← ). Beneath it are the formats for unicode, hex (or hexadecimal) code, and HTML code and entity.
At the top of the screen is a menu to take you to subsets of symbols: arrows, currency, letters, mathematical symbols, numbers, punctuation, and other symbols.
In the row just below that menu, there’s a search function and controls to switch from grid style (what you see above) to table style (below).
What’s the accomplishment?
References job aids don’t guide a specific task; they’re not a procedure like a recipe, and they’re not helping you make a particular decision. The goal of a reference job aid is to organize information that the intended audience can use in a number of ways.
I see two main categories of reference job aids:
Recall: these references present clusters of information (like the Articulate keyboard shortcuts), or indexes (like dictionaries or tables of codes).
Callout: these references either decode information (the fields on a form, the parts of an engine) or organize information spatially (like a you-are-here diagram or a geographic map)
I’d put HTML Arrows in the recall camp. In fact, though, calling it a list is like calling a 777 a vehicle.
Who’s the performer?
Someone needing to know the code for a particular format (“What’s the HTML for the capital cedilla [ Ç ] ?”). And, likely, someone browsing a category to see whether there’s a symbol (like for the Thai bhat).
Alexander Dixon, one of the creators HTML Arrows kindly shared some background. He and his friend, in their web design roles, often needed some of these codes. “We thought it would be a fun design challenge to quickly build our own version; the highly typographic nature of the content was exciting — which surprisingly none of the sites we had found really embraced.”
The table layout, he says, delivers a conventional list that might be faster for advanced users; the grid is very easy to navigate visually.
The feedback so far has been really positive, most suggestions are for additional symbol sets on the homepage or main sub-pages.
The value we believe the site brings is in the focus on typography and color to create clear visual hierarchies for both navigation and page elements, the structure of which we derived from the HTML character sets and symbols themselves.
…We’re excited people have found the site helpful, and it’s very cool to see that it can be useful in ways other than simply as a character reference.
As I told Dixon, this is an stellar example of a job aid. I’m especially glad to talk about it here since it dispells the job-aids-must-be-small myth.
Beyond that, it shows how powerful and appropriate a digital job aid can be. I’m not opposed to paper (you should see my workspace as I write this). 50 years ago, in fact, if you’d wanted an index of symbols (so you’d know what § was called, say), you’d have needed a pretty heft manual and been happy to find it.
Zeppelin has harnessed the power of code to deliver lots of functionality, almost effortlessly:
Swap between grid format and table format.
Choose subcategories via the main menu (arrows, currency, letters, and so on)
A search function (“…a final element we wished existed on more of the sites we used…”)
In addition, you can click an individual symbol for a close-up that includes (in this case) an HTML example and a CSS example.
FEMA and the American Red Cross produce a wealth of safety- and hazard-related documents. I’ve found Your Family Disaster Supplies Kit in multiple locations; the one here is from the University of North Carolina Wilmington’s emergency and safety information page.
The brochure’s purpose is to organize information to help with advance planning (“…one way to prepare is by assembling a Disaster Supplies Kit…”). There are two main parts:
A supplies checklist covering items like food, water, clothing, and tools (pages 2 and 3).
A guide to creating a family disaster plan (page 4).
Who’s the performer?
An individual would use this checklist to choose and organize supplies for a disaster such as a storm, an earthquake, or a spill of hazardous material. While the information is useful in many situations, the job aid is concerned with individuals and their personal safety, rather than with, say, a company’s employees at the workplace.
What’s the accomplishment?
Unlike procedures or decision tables, checklists don’t have a specific outcome. However, a good checklist helps a person to assess whether his planning or preparation is complete compared with the checklist’s elements.
Checks and chunks
Pages 2 and 3 of the brochure provide a checklist of possible supplies to stock. In all, there are more than 80 items set off with squares. I can hardly resist calling them checkboxes, and particularly for a planning guide like this, I think blank boxes are a better choice than, say, filled-in circles.
At the same time, the checklist is not particularly cluttered, as you can see from this cropped image. (I’ve removed the gutter space between the two pages. You can click to enlarge the image.)
The designers have chunked information into six categories: water, food, first aid, tools and supplies, clothing and bedding, and special items. Some sections begin with general advice (“Water: avoid containers that will decompose or break”); there are a few logical subsections, like the four under special items.
In addition to the chunking, the checklist is remarkably detailed for something that measures 6 by 7 inches. For example, I’ve lived in areas with severe weather, and so I always have a radio and a flashlight that I can charge with a hand crank. Not until I moved to an earthquake zone, though, had I considered the value of a whistle. (If you’re trapped by debris, you can signal your presence with much less effort and over a greater distance with a whistle than with your voice.)
One size – fits most?
I found many different forms of disaster-preparation guides, even when I limited my search to earthquake preparation. The topic is so big that you could fill dozens of pager with detailed information.
To me, that’s a reminder: there’s no one right way to create this sort of guide. FEMA and the American Red Cross have done well to label it a disaster supplies kit. Page 4, Create a family disaster plan, is pretty sketchy — but FEMA has many other resources for planning.
Cisco has an online guide to troubleshooting its uBR10012 Universal Broadband Router. Downloaded in PDF form, the guide comes to 86 pages. Chapter 1, which is six pages long, deals with basic troubleshooting tasks, and one tool in that chapter is this flowchart:
What’s the accomplishment?
As with any troubleshooting, there can be a couple of accomplishments. Using the flowchart may enable a technician to fix a simple situation that prevents the router from working properly. It may lead to a more detailed set of actions to diagnose and possibly resolve a more complicated problem. Or it may confirm that resolution requires a greater level of technical support.
Who’s the performer?
Cisco says that to benefit from the troubleshooting guide, “you must be experienced using Cisco IOS” and have “some responsibility for installing, configuring, or operating” their router.
That’s not me, and I’m unqualified to discuss the technical accuracy of the Cisco troubleshooting guide. I’m featuring the flowchart here because it’s an effective use of the format, and because with the rest of the guide it demonstrates multiple levels of on-the-job support.
Flowchart – a good choice for the task and the audience
A flowchart like this represents a series of decisions. You could represent the same information in a table. One argument against using a single table is that there are multiple conditions here, and each condition would be an additional column in a decision table. A decision table with five columns (four for conditions, one for the actions) gets wide and thus unwieldy.
You can get around that by creating multiple tables. For Cisco’s intended audience, though, the flowchart format probably works well. They’re presumably skilled technicians, accustomed to the flow of such diagrams.
The flowchart is concise to the point of terseness. You can’t use this job aid if you don’t know what a PEM is or what the ICC+ status is — but if that’s the case, you probably shouldn’t be messing around with the uBR10012 router, which can provide broadband for up to 64,000 subscribers.
In context, for someone who does mess around with these routers, the flowchart’s likely an effective and methodical starting point. After the first decision (is the miswire light off?), the remaining eight come in pairs of decisions like this:
Is the PEM Power OK LED on?
If not, troubleshoot the PEM.
When that’s done, see if the PEM Power OK LED is on now.
If not, see the section (chapter) on PEM faults.
Sounds obvious, but one point of a job aid is to reduce the need for memorization. Follow these steps, and you’ll cover everything you should cover.
Another point, perhaps less obvious, is that a technical job aid aims to overcome tunnel vision. Notice the four round-corner boxes running down the center: Sometimes you reseat a device; sometimes you reseat and restart. I have no idea why, but I’m pretty sure there’s a difference that matters. In the process of troubleshooting, the technical who follows the guide doesn’t waste time restarting when that’s not required.
Troubleshooting: lots more where this came from
Despite a lack of visual appeal, the flowchart and the guide it comes from represent an effective way to guide troubleshooting performance.
The flowchart itself is a summary aimed at a performer who understands its laconic style. It’s a memory jogger.
But: if the PRE status LED won’t come on, the flowchart send you to chapter 3, with its 19 pages of PRE-specific troubleshooting. Those pages include what I call procedures (sets of numbered steps, like the one for resolving console port connection problems); mini-procedures (short sets, with bullets instead of numbers); decision tables (“fault indications and recommended actions”); and different types of references (like a diagram of the PRE-1 faceplate and its indicator lights).
In other words, the Cisco uBR10012 Universal Broadband Router Troubleshooting Guide is at one level a single job aid (the job: troubleshooting the router), and at another level a collection of dozens of specialized job aids. None of this fit-it-all-onto-one-laminated-sheet silliness: if you need two pages to guide a technician through TCC+ card faults, that’s what you use.
Mike Taylor (@tmiket) recently shared a link to a collection of shortcuts for Articulate Storyline. (You can register as a member of the Articulate community at no charge and then download the shortcuts.)
I liked the look of the guide to keyboard shortcuts and asked Mike if I could include it in the collection here.
About this job aid
I see this as a reference job aid — one intended to organize information rather than to guide someone through a particular task.
What’s the accomplishment?
Since it’s not designed with a specific task in mind, a reference job aid’s accomplishment is aiding recall. In my opinion, that recall is contextual: I’m trying to remember how to work with text in Storyline–or even more specifically, how to right-align text. Or I want to work with the slide master.
The challenge in creating a reference job aid is to figure out the most useful contexts and group the individual elements accordingly.
Who’s the performer?
Given the general nature of a reference job aid, this collection of keyboard shortcuts is useful for anyone already familiar with Storyline. It might also be useful for someone who’d used similar products like Captivate or Lectora: if I know how to preview my project in Captivate, can I do something like that with Storyline, and if so, how?
Comments / critique
I talked with Mike Taylor a bit via Twitter and email. He said his inspiration “was basically a make over of list of shortcuts that didn’t have any type or logical organization. I tried to group them into categories based on what type of tasks they were related to.”
Notice that the colored groupings don’t depend solely on color for their meaning. Each grouping has a title and a separate icon.
A small but helpful detail: the alternating colored background in each group of shortcuts. Within a group, the individual elements are all single-line items: a description of a function, followed by its key combination. The line-by-line change in shading helps to emphasize individual items, and I think does so less obtrusively than black dividing lines (borders) would.
See if you agree:
I use a lot of keyboard shortcuts. When I first saw the Storyline job aid, I immediately thought of a somewhat older example that’s been in my collection for years: a quick-reference guide for Borland Sidekick (and probably a lot of other Borland products as well).
In the upper portion of this example, the designer is using what was once called the WordStar diamond. On a QWERTY keyboard, the letters E, D, X, and S form a slightly slanted diamond. Back before people used mice, some power users preferred to keep their fingers on the typing keys rather than the cursor arrows, and so the Ctrl-xx combinations were a way to change the cursor position.
The “outer diamond” was like a turbo boost: Ctrl-D shifted you one character to the right; Ctrl-F shifted you one word.
Notice also the block commands in the lower right, which harken back to MicroPro’s WordStar and probably to programs before that. It seems clear to me that Ctrl-K-C (“copy the currently marked block”) and Ctrl-K-V (“move the currently marked block to where the cursor is”) are direct ancestors of Ctrl-C and Ctrl-V today, though Ctrl-K-Y (“delete”) became Ctrl-X.
I’m grateful to Mike for sharing this job aid. He’s generous with his time and his ideas, as you’ll see at his blog and at Work Smarter, Not Harder, his collection of tips.
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.