Guide decisions with a flowchart? Yes. No. It depends.

A lot of people in organizations who plan or guide the work of others are big fans of flowcharts. My experience is that a lot of those being guided are not. In this post I’m looking at two interrelated points:

Not every flowchart is a decision-making guide.
Not every decision-making guide should be a flowchart.

Purpose first, format later

Information in a flowchart isn’t necessarily a guide to making decisions, any more than items bought at the supermarket are necessarily groceries.

The main characteristic of a flowchart is flow: it’s a diagram that shows relationships and sequence. SmartDraw, whose software helps people draw flowcharts and other diagrams, suggests a number of purposes here, including modeling a business process, managing workflow, and mapping computer algorithms.

Each of these is likely to involve decisions or alternate paths. If you map your sales process, you might have one path for online orders and one for phone orders. Most formats are not primarily meant to guide individuals making decisions. They’re a reference–hence the name “process map.”

Before deciding “Task A should have a flowchart,” consider whether performing Task A requires a person to make a number of decisions.

Clear about purpose? Who’s the performer?

Once you’ve determined that a major part of your job aid is guiding individuals who need to make decisions, you want to know who those individuals are.

As I said earlier, a lot of planners love flowcharts. So do a lot of programmers, engineers, and other technical people. Just as they use specialized terms for efficiency, so too they move easily through the symbols, directions, and conventions of flowcharts.

credit card processing

Credit card processing (from Click to enlarge.

But most people don’t.

Most people in the English-speaking workplace process textual information the way they read: first left to right, and then top to bottom.

Even a relatively brief chart, like this credit card process diagram from SmartDraw, could pose a challenge if it were guiding specific steps in a task* .

I’m mainly reading downward, I have a loop that moves upward, and if I’m not skilled in reading flowchart symbols I might be confused by the four different shapes that flow from “Transaction completed” near the bottom.

* I want to make clear SmartDraw didn’t intend this particular chart as a step-by-step guide; I’m just using its format to highlight how the overall layout can pose challenges when used in that context.

As a general principle, if someone doesn’t frequently work with flowcharts, he’ll have a harder time using one to achieve the desired result. So for most workplace audiences who need a job aid, avoid using a flowchart unless the task demands it.

Outcomes versus sets of conditions

How do you know what a decision task is demanding? Each decision has two parts: one or more conditions to consider, and an outcome for a given set of conditions.

Take a look at the decision table below. It’s a less-than-ideally designed guide for calculating how much of a rebate someone can get if she trades in her old hyperspace teleporter for a newer model. (Yes, it’s fictional, but the layout is exactly the same as a real-world job aid.)

Take a moment to consider how many outcomes there are, how many sets of conditions, and what categories those conditions fall into. (In the chart, MSRP refers to the original manufacture’s suggested retail price,)

acme techship before

Done? See how your analysis compares to this one:

  • Outcomes: there are only five. They are the different amounts of trade-in value, ranging from “none” to “50% of MSRP.”
  • Conditions: there are 24 sets of conditions that each lead to one of those outcomes. By “set” I mean one specific combination that leads to a particular outcome. On this chart, there are nine different sets that lead to the “50% of MSRP” outcome. (Example A: you’re trading in a 2009 Parsec whose MSRP was $10,000 or more.  Example B: you trade in a 2012 Nebula 1200 whose MSPR was $7,000. Two sets, each leading to the same outcome.)
  • Categories: Although this might look like a huge amount of decision-making, there are only three categories of conditions: the model year of your teleporter, the original MSRP, and the specific model.

It’s important to realize that the number of categories is the main factor in gauging complexity, even if not every category necessarily applies to every outcome. Take a look at this table for figuring out what price to offer a customer:

dt 10


There are four categories of conditions: type of customer, price, credit code, and item code. For most outcomes, only two categories matter, but overall there are four.

Category: another word for “when”

When I’m analyzing a decision task, when/then is my shorthand for conditions and outcomes. In the example of the teleporter rebate, each category of condition is a WHEN:

  • WHEN the model year is XXXX, and
  • WHEN the original MSRP is YYYY, and
  • WHEN the model purchased is ZZZZ,
  • THEN the trade-in value is AAAA.

A rule-of-thumb for decision tables is to try and keep them down to three WHENs. Depending on the particular task and the number of sets of conditions, you might manage four. After that, flowcharts can often be easier to follow, mostly because they keep the performer’s attention away from condition sets that don’t apply to the current step.

You can circumvent that: break a complex table in two or more. Let’s say you’re working on income tax information. The categories might be marital status, filing status, income, and age. If the decision table would be too complicated with four WHENs, you could create separate tables based on (say) marital status, and each would then have only three WHENs.

Deciding via flowcharts: the bottom line

Here’s how to think about whether a flowchart makes sense for your job aid:

Does the task involve on-the-job decisions made by individuals?

If it does, are those individuals good with flowcharts?

If they’re not, do the decisions involve four or more categories of conditions–four or more WHENs?

Even if they do, could you simplify things and use multiple decision tables?

Should I use a flowchart to guide decisions? in flowchart form:

decision flowchart

Rahul Samuel’s Tech Rider

About the Tech Rider

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.

From the SonicBids blog

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

rahul tech rider 1

  • 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)

tech rider stage plot

  • 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 foh

Other comments

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.


Airbus Quick Reference: Engine Dual Failure

About the QRH for Engine Dual Failure

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

About HTML Arrows

html arrows home page

Click to enlarge; grid view from

HTML Arrows is a multifaceted reference tool created by 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).

html arrows table style

Click to enlarge; table view from

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.

My comments

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.

html arrows euro sign

FEMA Family Disaster Supplies Kit

About this job aid

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.

fema L189 p1

This is page one of four, each about 5 x 7 (click to view at full size). The idea seems to be to print them on both sides of an 8.5 x 11 sheet, then cut and fold into a brochure.

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.)

Disaster supplies arranged in six categories

Disaster supplies arranged in six categories

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 router – troubleshooting flowchart

About this job aid

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:

cisco router troubleshooting flowchart v2

PDF version of Chapter 1, Basic Troubleshooting Tasks

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.

Articulate Storyline keyboard shortcuts

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.

Keyboard shortcuts for Articulate Storyline

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:

Watching the border

Other stuff

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).

Borland quick reference

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.

How to decide whether to build a job aid

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.

Should you, or shouldn't you (part 1)?

“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 speed or rate is a critical factor in performing the task.  The short answer is that if speed matters, a job aid isn’t going to work.

Wing tips up, feet down, watch for that wave...

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:

Part 2: ask the task

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.

Part 3: what obstacles does your job aid need to overcome?

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.

Amarillo by morning

Amarillo by morning…

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.

In a quarter mile, turn left

Deep in the heart of Oslo

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.

Don't go off on the wrong track.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.

CC-licensed photos:
Seabirds by Paul Scott.
1936 Texas highway map by Justin Cozart.
Norwegian GPS by Stig Andersen.
1879 Michigan Central RR timetable from the David Rumsey Map Collection.

The job-aid diagrams are mine. This post is based on material that I originally posted on Dave’s Whiteboard.

Income-based repayment calculator for student loans

About this job aid

The Office of Federal Student Aid is part of the U.S. Office of Education. Part of its mission is to inform students and families about federal student aid programs.

Students with certain federal loans who are experiencing financial hardships may be eligible for the Income-Based Repayment plan. An IBR can lower the required monthly payment, though it can extend the payment period and thus increase the total interest paid.

As part of its information about load replayment, the Office of Federal Student Aid has an online calculator to determine the likely monthly payment under an IBR.

The IBR calculator

The IBR calculator

This is a calculator job aid–based on information entered, it performs calculations and produces an answer. In this case, the answer is an estimated loan payment.

What’s the accomplishment?

Determining the monthly payment for a student load under an Income-Based Repayment plan.

Who uses this job aid?

Anyone trying to determine this figure; most likely someone with a student loan who’s having trouble making the payments.

Using the calculator

Preliminary information:

There are many kinds of student loans, and not all are eligible for an IBR plan. On the same page as the calculator, Federal Student Aid states:

Your loan servicer will determine your eligibility for IBR, but check this calculator to see whether you might qualify and what your estimated payment could be.

In addition, there’s a link to the National Student Loan Data System so that a person with a student loan can determine which type of loans he has, along with the current amount of principle and interest.

Finally, the page suggests having on hand income information like your most recent federal income tax return.

The calculations:

As the first step, I entered marital status, family size, and location, using an example in the FSA FAQs (single, living alone, in Maryland).

Single, living alone, not in AL or HI

Single, living alone, not in AL or HI

Next, I enter details about my current loans:

Current loans

Current loans

After that, I enter income data based on my (hypothetical) tax return.

Income data

Income data

Based on the data I provided, the calculator says I may qualify for a monthly payment of $309.

The calculator then provides information about the next part of the process:

Next steps

Next steps


Comments / critique

Adaptive approach

When you see the calculator, it looks like the first image in this post: just the space for marital status, family size, and location. Only after you enter that data does it expand to ask for income data, and only after you enter that data does information appear for the estimated monthly payment and for the next steps to take.

Considering the complexity of the subject, that’s a good approach for the calculator to take. It’s less intimidating at the outset.

Embedded help–less than helpful?

I did find it a little confusing to read “I owe [amount] in federal student loans” and “I originally borrowed [amount] in federal student loans.” When I clicked the icon for more information, at first I thought I had a problem with my browser. It took me a while to realize the information appeared further down the screen than I expected:

Help's down there

Help’s down there

That image is 570 pixels high, and on some computers might not be obvious.

Other resources

How to build a decision table

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:

Decision table for flood insurance coverage

Just an example, not an actual rate quote.

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.

The goal

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.

dt 01

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.

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.

dt 02

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.

dt 03The 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.

dt 04

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.

dt 07

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.

dt 08


Step 6: Simplify the table.

dt 08

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:

dt 10

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.