Your work instructions aren’t working anymore. Let’s fix that—with visuals first.
A technician is asked to write instructions for his company’s most frequently performed processes. Pulling out his laptop, he starts to document a procedure as he does it. He spends hours going back and forth between the procedure and his computer, writing down every step. Occasionally, he’ll stop to take a photo or sketch a diagram of the more complicated steps. But even though all the directions are correct, our technician made a critical error—before he even started writing down the steps.
Technical documentation—whether work instructions, training manuals, or product guides—is essential to any workforce. Technical documentation aims to standardize procedures, ensure efficiency, and outline safety information. Despite these good intentions, technical documentation—as written in scenarios like the one above—just can’t meet the needs of today’s multimedia user. Whether experienced technicians or novice customers are using your technical documentation, a “text-first” approach is overused and outdated. It’s not engaging and it’s not effective.
It’s time to rethink how we create technical documentation. It’s time to begin where most of us end: with visuals.
You haven’t prioritized visuals, and that’s understandable
Companies traditionally create technical documents with a text-first approach—writing a couple chunky paragraphs, adding handfuls of bullet points, and (if it’s convenient) throwing in a few visuals, like photographs or diagrams. Yes, for years the text-first approach made sense. For one, technical documentation was commonly built in applications that encouraged prioritizing text, like Microsoft Word or PowerPoint. (When you open up a Word Document, you get a blinking cursor—not a media uploader.) And before the advent of dSLR cameras and sophisticated camera phones, photographs weren’t easy to incorporate into technical documentation. (It certainly isn’t cost-effective to print pages filled with colorful images.) So it’s not that authors can't put visuals in technical documentation—they have just been conditioned not to.
But times have changed, and so should the documentation. Now, there are visual-first applications available, like Dozuki—the visual, online documentation platform for innovative companies. Now, good cameras are affordable to own and easy to use. Now, mobile electronics—like smart phones, tablets, and laptops—are on every desk and in every pocket. And those devices can replace the bulky, disorganized documentation binders we’ve all grown accustomed to. Indeed, mobile devices are ushering in the age of paperless documentation, cutting printing costs, and making documentation more accessible.
We simply can’t ignore visuals anymore. Because a visuals-first approach isn’t just a more viable option, it’s the only option. To make documentation for the modern user, we’ve got to take into account how they learn. Today’s technical documentation users process information far better when it’s communicated visually. 90% of all information processed in the brain is visual—which means users will always gravitate to photographs and diagrams. Visuals are processed 60,000x faster than text—which means users will understand your content much more efficiently. Of course, as a professional writer, I appreciate the written word. But I know that people “read” differently these days. When visiting a website, the average person only reads 20% of the copy, hunting and skimming for key information and visuals. Prioritizing text just doesn’t cut it for the modern reader.
Visuals first, text second
So simply adding more visuals will improve your technical documentation? Not quite. You have to create your visuals first. Why? The processes in technical documentation are rarely simple—and you don’t want the success of your documents to be threatened by text with problematic jargon or contextual misinterpretations. Stop relying on text as the sole vehicle of meaning. Instead, make your visuals powerful enough to stand on their own. But to do that, the visuals need to come first.Photographs, for example, bring necessary context to a step and literally show users what they should be doing. But even with photos, if you write your text first, you’re more likely to rely on that text to make up for any deficiencies in your photos—in effect, treating the visuals as an afterthought.
When it comes to technical communication, your photos should do the heavy lifting. By taking your photos first, the pressure is on for them to be so good that you could communicate your entire procedure with just those visuals. It’s a strategy that will eliminate concerns for even novice or ESL users.
Miro Djuric, Chief Information Architect of iFixit—which creates online repair manual for everything—and recent Dozuki Workshop expert, has been creating technical documentation for audiences all over the world for nearly ten years. He explains visual-first approaches by saying:
“We found the best approach to creating documentation—one that is quick and easy—is to begin with pictures. In doing so, we eliminate the guesswork from which component needs to be removed and where that component is on a machine or device. And another happy side-effect of visuals-first is that we also have a documented record of what components were removed, and in what order. Our tech writers can instantly refer to images if there are ever discrepancies with a document.”
Not all visuals are created equal
There is one hitch with visuals: they aren’t created equal. Some companies take on the visual-first approach, but fall into several common pitfalls. For instance, many of us are familiar with Ikea’s notoriously frustrating visual instructions. This Ikea diagram, for example, is certainly visual—but it’s not helpful. The context isn’t clear, the parts aren’t labeled effectively, and it suggests nearly ten tasks at once. Users aren’t even sure what the object is—not a great sign. This diagram is just as bad, if not worse, than confusing blocks of paragraphs.
Photo 2, an image used for a homemade guide on the Canon PowerShot G3, is also unhelpful. The shot is out of focus and doesn’t have a clean background. Worse, even with the purple markup—intended to highlight the action—users can’t see what the technician is actually doing. And working inside an electronic device isn’t a task to be undertaken lightly.
So what kind of visuals should you aim for? Ones that are clean, clear, and comprehensive. Your visuals need to answer questions, not draw more out.
Likewise, in Photo 3, a technician is detaching a delicate cable inside of a 2014 MacBook Pro. In this photo, the computer is in focus, the white background is clean, and the details of the hardware are so crisp that the image doesn’t even require markup. It’s clear what the technician is doing.
Start visualizing better technical documentation
Visuals are more than just pictures and sketches—they are the foundation that today’s technical documentation should be built upon. From CAD files to pictures to videos, there is a multitude of visuals that you can start incorporating into your technical documentation. But to incorporate visuals successfully, you need to make them your first priority. So what do you do now? Start researching solutions for visual-first documentation, like Dozuki. Read media-friendly resources, like The Tech Writing Handbook. And help your technical documentation help you—one visual at time.
This article was originally published in Context, the Australian Society for Technical Communication Magazine.