Documents and other tools that the public interacts with are a kind of performance support; the goal is to help people accomplish things they want or need to do. Job aids are one form of performance support, and I see a ballot as a kind of collector worksheet (as opposed to one that helps calculate): information on the ballot form is organized, typically by office or issue, and the voter has a way to indicate her selection.
The Center for Civic Design has for its goal making “every interaction between government and citizens easy, effective, and pleasant.” I’ve just come across a post of theirs from 2008 that discusses in depth a usability test for state ballots in New Hampshire.
The test looked at a single question: is it better to left-align the names of candidates, or to right-align them so each name is as close as possible to the circle that the voter would fill in?
From a performance improvement viewpoint, and as someone who’s worked as an election judge several times, I found the discussion in the full report enlightening. As for the conclusions, participants in the test who used Ballot B:
Took slightly less time to vote.
Made fewer errors.
Preferred Ballot B to Ballot A.
From CCD’s conclusions:
Although the difference in the number of errors made by participants when voting on Ballot A and Ballot B is not statistically significant, the data indicate that there is a trend toward fewer errors when voting on Ballot B. For this reason, we recommend the use of Ballot B (right-aligned names) for the general election in November.
A strong proximity relationship between candidate names and fill-in ovals is more important than the alignment of names on the ballot.
With most of the job aids I’ve discussed on the Ensampler, I’ve focused on a main purpose–the job aid as primarily a reference or primarily a decision-guiding flowchart, for instance.
Here, I’m analyzing a familiar type of job aid: IKEA instructions. I’ve chosen the guide for IKEA’s Galant desk. The goal of this guide is to help someone attach legs to a metal frame, and then attach the frame to a desktop.
Many people think of IKEA instructions as mainly procedural (step-by-step guides). The Galant instructions are more complex—they cover forty pages, so a single guide can help a consumer assemble any of the thirty-two different Galant configurations, based on size, shape, optional extensions, and so on. (You buy the frame, top, extensions, and legs separately; the instructions come with the frame.)
Beyond number of pages, though, what’s significant is how the Galant instructions support several types of accomplishment. I’ve split the discussion into two similar-sized chunks:
Part 1 (this post)
Background on the Galant desk
The decision guide section of the instructions, to help you find steps for the specific configuration of Galant desk you have,
The concise, detailed checklist that shows the quantity and type of each part needed for each combination of frame, top, extension, and legs
Part 2 (the next post)
The detailed procedural steps for your specific assembly.
Galant: the Background
While IKEA’s Galant series of office furniture has been replaced by the similar Bekant series, I’m deeply familiar with the Galant; I had the corner desk in my office for years.
That’s my old desk in the photo. IKEA calls it a left-hand desktop: one piece whose main, rectangular form curves into a smaller section on the left.
I didn’t join any extensions to mine, but as you’ll see, all the tops were designed to match up with various extensions.
The tops and extensions attach to a metal frame whose components depend on the configuration. And two types of legs — angled or T-shape — attach to the frame. For a clearer picture of how things come together, here’s a short video of two Galants being assembled. Both of these include a rectangular extension, so each desk is larger than mine was.)
Decisions, decisions
For the desk you have, see the page indicated.
Page 3 of the instructions is a wordless decision guide: based on the configuration you’ve chosen, turn to page X.
This page shows thirty-two different combinations of desk elements. Like a good reference, though, it organizes and categorizes.
Each row set off by a line contains combinations that follow the same basic assembly steps. The third row down, for example, shows ten different combinations of desk that all follow the steps on page 10.
You could find many approaches to organizing this decision. It’s not hard to imagine an product-centric one that started with the part number for each size of frame. What IKEA has done well here is to focus on the customer’s goal: a particular desk.
The customer likely compared several configurations and so is likely to recognize the one he chose. What’s especially helpful here is that IKEA relies on generalization: each row is a set of distinct items (the configurations) that leads to the same response (steps for assembly).
Checklist: which, where, and how many
Page 4 of the Galant guide has this chart:
It’s a checklist, dressed up like a reference.
A checklist, because you choose the type of leg, frame, or extension you’re working with, and then read across to see how many parts of each type you need. The focus of a checklist is coverage or completion: make sure you have all these parts.
Here too there’s an assumption that the consumer knows what’s going on. The last two rows of the page 4 chart are for different types of desk extensions. You wouldn’t have those if you didn’t have the main desk, and so IKEA is relying on you to chunk your part-identification:
Parts for the type of leg your desk will have (the first two rows)
Parts for the main portion of the frame you’re using (rows three through six)
Parts for the extension
In addition, IKEA steps outside strict rules when it comes to parts for the T-leg. There’s a special size of hex wrench for these legs; it’s used to adjust their height. That size isn’t used for any other part in the Galant family, and so that specific wrench (100092) appears in the right-hand column, where you’d expect either a blank or a 1 (which would indicate you needed wrench 108490.
I’m not sure I would have designed this chart that way, but I think it’s effective. Even if you hadn’t started assembling your desk, you’d be likely to say “I should have this particular wrench,” and it would have come in the package with the T-leg.
As I said, the parts chart is a checklist–but if you keep your IKEA instructions, as I do, it’s also a reference. Eight years after purchasing another piece of IKEA office furniture, I was able to get a replacement part because the original instructions told me what the part number was.
…there’s one foolproof method for turning IKEA rage into grudging respect: assembling almost any other brand of furniture…
To adapt Winston Churchill’s famous quip, IKEA may be the worst form of ready-to-assemble product design we have—except for all the others.
John Pavlus
As noted above, page 3 of the Galant instructions is a decision guide — it directs you to one of seven different sets of procedural steps, depending on the type of desk you’re putting together.
I had a left-handed desk with no extensions; that’s the fourth set of instructions, on pages 16 and 17.
You can see those are typical IKEA instructions. They demonstrate a careful, specialized approach to guiding performance:
No text (a single sentence would have to appear in dozens of languages)
Minimalist images (what detail you see matters)
Customer focus (the desk, the frame, the legs appear in standard positions and as the assembler would see the actual parts)
Call-outs, close-ups, and warnings
Implicit in IKEA instructions are two messages: “You can assemble this item,” and “Here are the details.” Those messages are related: if you don’t attend to the details, you’ll have trouble assembling the item.
You are here.
Here’s the top of page 16:
If you’re building one of these, you’re on the right page.
The diagram is meant to confirm that you want the instructions for a right-hand desk (top row) or a left-hand one (bottom row), whether you’re using five angled legs (left column) or three T-legs (right column).
Each configuration appears both upright (because that’s your goal) and upside down (because that’s how it’ll look as you work on it).
A complex two-step
If you study pages 16 and 17, you’ll see that there are two main steps: attach the legs to the frame, and attach the frame to the desk. IKEA marks those with a big 1 and 2.
The biggest drawback to IKEA’s wordless style is that there can be a lot of detail in a step. Here’s the main part of step 1 (page 16) to which I’ve added some callouts for commentary.
A: attaching legs to the frame
The diagram shows both kinds of legs so you’ll see how to position them: for the angle legs, one in the corner of the desk and two at each of the remaining ends. For the T-legs, orientation matters, with the two on the long side of the desk parallel to teach other.
B: details for attaching angle legs
A bolt goes through the frame into the angle leg. Note the closeup: there’s a small tab on the top of the leg that fits onto a hole on the frame. Also, the 5X is a reminder that you have five angle legs to attach.
(I’ll get to the details for T-legs later in this post.)
C: attaching the extension to the frame
Some Galant desks are ordinary rectangles, but the right- and left-handed desks need support for their extensions. The closeup at C shows where two hex-head bolts attach the frame extension to the main frame.
Details matter: if you look closely, you’ll see that the end of the extension that the legs attach to looks different from the end that attached to the main frame. (If you don’t look closely, eventually you’ll discover that the leg end doesn’t have any holes for you to attach it to the main frame.)
D: attaching angle legs to the extension
A pointing hand draws attention to the closeness of the legs for the extension. (Compare them with the two legs at the far end of the main section.) There’s even an X-ed out “not this way” diagram to reinforce the point.
The short version:
Position each angle leg and bolt it to the frame.
Position the frame extension and bolt it to the main frame.
At the bottom of page 16, you find two boxed items; each directs you elsewhere for a specific sub-procedure.
The left-hand diagram sends you to page 40 to see how to adjust the height of your desk, regardless of type of leg. Personally, I might have put this particular procedure on page 17, after you’ve attached the frame to the desk.
The right-hand diagram sends you to page 5. That has the steps for assembling the T-legs and for attaching them to the frame.
Attaching the frame
Attaching the frame to the desk is straightforward: eight screws, as indicated on the diagram.
The less-obvious part of this step involves putting plastic caps over the open ends of the metal frames: four on the main frame, two on the extension.
Here, too, callouts and a don’t-do-this diagram to show there’s a right way to attach the caps. (The small arrow, in the middle of the three circles, shows a little notch you can slip a screwdriver into to easily remove the cap.)
Desk work
Why spend so much time analyzing a set of IKEA instructions?
I think the Galant guide is a highly effective approach to supporting detailed accomplishments. IKEA’s worldwide market necessitates a wordless approach to such support. That has its drawbacks–I know I’ve misread IKEA instructions more than once. Almost always, though, I can back up, undo the error, and get things right.
What’s more, the IKEA format is kind of do-it-yourself cultural artifact, and once you’ve put together a couple of IKEA items, you’ve learned through experience to pay attention to details like hole size, spacing, and position of part.
By the way, there’s also a thriving culture of IKEA hacks–people going far beyond the instruction guide. Here are over a dozen hacks just for the Galant, including someone’s megadesk that’s 25 feet long, not including 12 extra feet of shelving made from yet more Galant parts.
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.
The original
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.
Weak points
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.
The makeover
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.
Language
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.
Title
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).
Accomplishment
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.
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.
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.
Page 1 of 3
Page 2 of 3
Page 3 of 3
Accomplishment
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).
Performer
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]
Comments
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).
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).
Background
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.
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.
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
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:
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.
