Tips and Insights

Even though what something is called doesn't change what something is (you remember Shakespeare's "a rose by any other name . . ."), when semantics creep into an industry, it can cause problems. I generated this list of possible terms for identifying work instructions in just a couple of minutes (and missed how many more?):

• work instructions
  
• standard operating procedures
• job aids
• standardized work instructions
• job planning
• product design documents
• technical manuals
• user instructions
• procedure manuals
• policy manuals
• job skills
• training tools
• detailed process sheets

Isn't communication hard enough, without having different words mean the same thing? I'm laughing, of course, because we are talking about the English language here, where multiple meanings, multiple pronunciations, multiple spellings is the bane of meaningful conversation.

I don't think using different terms for an object or a process is necessarily a Lean or quality issue when it happens between different companies, but it could be an issue if it's happening within the company and hindering communication between departments. Take, for instance, the engineering department and the shop floor. If engineering is in charge of writing instructions-and they often are-they may use terms for parts that don't match what the shop floor technicians and mechanics call them. And if the engineer and the user don't agree (or confer ahead of time) before naming the parts, the potential for confusion when reading the instruction rises; i.e., if a worker wants to find out how to fix the thingamajig on the hoosit, she's in trouble if the engineer has named it the wallabaloo on the cratshis. She won't find what she needs unless she looks through the entire manual.

We were exposed to this issue when we worked with the United States Postal Services maintenance department. Barcode label printers at bulk mail centers are high-speed, high-volume machines that can disrupt an entire station if they go down. USPS maintenance, which handles dozens of machines and infrequently works on these printers, needed to diagnose and fix them quickly. Not only did they have to read through the columns of text in the table of contents to figure out what procedure they might need, they also had to figure out which term matched the part they needed to repair.

We solved this problem with a visual table of contents that allowed maintenance to identify the part based on what it looked like and/or where it was located on the machine. The user could then turn to the page of the operation that applied to it.

It was always our plan to have other Explainers pitch in and participate in the blog once Renee got us off the starting line. It's all about teamwork, right? So here I am, lending a hand, and hopefully adding some value to what Renee has so carefully developed over the previous year.

My name is Parker, and I've been working at Explainers for about 8 years, although my association with this company can be traced back to the earliest days of my career. I started out as a technical illustrator, and along the way I've worked as a graphic designer, technical writer and project manager. My current position-Explainer-allows me to use all of my skills at once.

I'm writing to tell you about VizThink '08, an interesting conference that's being held in San Francisco in January. This would be a great opportunity for you to learn more about visual communication. Our schedule may prevent us from making the trip this year, but that doesn't mean you can't go! Sign up, and let us know what you think. We'd like to hear from you.

Parker

Labels: conferences, visual thinker