Lead Writer: Swapnil Ogale, Kieran Morgan | Reviewer/s: Castella Arthur | Expert Reviewer/s: John Sweller, Deirdre Wilson | Managing Editor: Kieran Morgan

This chapter outlines the importance of using visuals like screenshots and diagrams in technical documentation. It introduces two key theories—multimedia learning and cognitive load theory—to explain how the human brain processes visual and textual data. It provides practical tips on selecting and preparing visuals and includes a checklist for effective implementation. Overall, this chapter aims to equip technical writers with both the theoretical understanding and practical tools needed to enhance documentation through imagery.

Who Should Read This
• Aspiring Technical Writers • Beginner Technical Writers • Cross-Domain Professionals
Table of Contents: Technical Writing Process
Previous: Chapter 17: Write Draft	Next: Chapter 19: Edit Drafts

1. Introduction

This chapter explains the theory and practice of using visuals in technical documentation. Most tech writers are familiar with using screenshots and visuals, but there are techniques to follow to get it right. Beneath the apparent simplicity of a screenshot or diagram lie some powerful concepts in human psychology and how your brain processes information. You’ve no doubt seen lists of dos and don’ts in information design, but why are these considered best practices? This chapter will explain the theories behind the practice and give you strategies to apply in your documentation projects.

The first theory is multimedia learning, which is akin to saying your brain has two “processors,” similar to a computer. These work in parallel to process images and text more efficiently. The next theory is cognitive load theory, which explains how your brain’s processors convert sensory input into knowledge—and how that process can get bogged down by unnecessary, “extraneous” information. Finally, we talk about some extremely practical strategies you can use to put these theories into action.

2. [Theory] Multimedia Learning: Your Brain Has a Dual-Core Processor

Have you ever heard of a dual-core processor? Most of us have. If you’ve bought a computer anytime since the turn of the century, you’ve likely had dual-core advertising claims hurled at you like confetti. Thanks to the marketing folks, we now have a convenient metaphor to explain how multimedia learning works in your brain.

Let’s imagine that your brain is a computer you’re considering purchasing. The advertisement highlights its “dual-core processor.” What does this mean? One processor is dedicated to images, and the other to language (including verbal, text, and sign language). By employing both “processors” concurrently—in parallel—your “brain-computer” can process information almost twice as efficiently. This foundational concept in instructional design is known as “multimedia learning theory”.¹ According to this theory, using words and images in tandem makes learning, on average, 89 percent more effective than using words alone.²

Of course, you have many more inputs than that. Your senses also include taste, smell, movement, and so on. However, for the purposes of technical writing—even if you’re the Picasso of your craft—your technical documentation “palette” is usually limited to language and images.

For technical writers, the implications of this theory are clear and something that every experienced technical writer already intuitively knows. Using appropriately selected and well-captioned images alongside text will make your technical documentation much more effective for your audience.

3. [Theory] Cognitive Load Theory

Cognitive load theory explains how our brains process and manage new information. We’re going to dive into this theory in a little more detail in this section. If you want to go straight to the practical applications, feel free to skip this part. But if you want to learn how people process information and how this powerful concept is relevant to the visuals in technical documentation, then read on.

3.1. Limited Processing Capacity

We all know that feeling of information overload—that ache behind the eyeballs when we know we’ve hit our limit It’s often accompanied by the fear that if someone asks us what we’ve just learned, we’ll draw a complete blank. This isn’t just the result of a lack of caffeine or too many sleepless nights spent cramming for exams; it represents a fundamental limit on your brain’s ability to absorb information.

Why is this? It has to do with how your brain processes information. When you receive input from the outside world, it undergoes processing in your brain and is ultimately stored in your long-term memory, as shown in the diagram below.

So, what’s the problem? The issue lies in the working memory, which has a very limited capacity, compared with the world around you, which can offer an unlimited number of inputs. In fact, most people’s brains can only hold up to four chunks of information at once;³ possibly even as few as two or three.⁴

3.2. Good Processing vs Bad Processing

When was the last time you searched for information on how to carry out a task, only to find yourself filtering out irrelevant information or trying to decipher confusingly worded or ambiguous instructions?

It’s a headache, isn’t it? That’s because filtering and parsing different sources of information put a lot of strain on our limited working memory. This is the unnecessary extrinsic processing our brains have to do before we can focus on the vital intrinsic information.

If only we had perfectly tailored information, imagine how much easier our lives would be! Your job as a technical writer is to help eliminate extrinsic information for your audience so they can focus on the important, intrinsic information.

The types of processing load you need to be aware of as a technical writer are:

1. Intrinsic Load: The effort involved in learning relevant, or “intrinsic,” information. This is “good” processing. For example, learning a concise sequence of well-written instructions on how to crop an image using an image editing tool should involve a fairly low intrinsic load, as it’s a straightforward procedure.
2. Extrinsic Load: The effort involved in filtering out irrelevant, or “extrinsic,” information. This is “bad” processing. For example, searching and filtering multiple hits in a knowledge base for the best information on how to crop an image, or trying to decipher poorly written, text-heavy instructions that go on and on and don’t include images of key functions.

What Does That Mean?

Intrinsic Load The effort involved in learning relevant, or “intrinsic,” information, as derived from the field of cognitive psychology. Extrinsic Load The effort involved in filtering out irrelevant, or “extrinsic,” information, as per the field of cognitive psychology.

4. [Theory] Bringing It All Together: Cognitive Load and Technical Documentation

So, now you understand that your brain operates much like a dual-core processor—a capability you can leverage as a technical writer. You’re also aware that your audience’s working memory can easily become overloaded with information, hindering their ability to process essential intrinsic details. This problem is further exacerbated when your instructions are cluttered with unnecessary extraneous load. As a technical writer, it’s your responsibility to use this knowledge to make your instructions more effective.

The most common visuals you’ll find in technical documentation include:

• Screenshots of a software system’s user interface, such as for a user guide. Also known as screen captures.
• Diagrams of the components of a physical device, as in a hardware user manual.
• Images, such as diagrams, charts, and infographics, for documents like reports.
• Photographs of equipment in the field, such as for a procedure.

In this chapter, we’ll discuss general principles for incorporating images into technical documentation, as well as specific strategies for dealing with these different image types.

5. [Practice] Crop, Capture, and Caption Images

In technical documentation, images are essential tools for conveying information effectively. The right visual can demystify complex ideas, guide users through detailed procedures, and boost overall comprehension. This section draws upon the theories outlined previously to offer practical strategies that enhance understanding of technical content, aiding users in efficiently completing tasks.

Tip

Check Your Style Guide Before Including Visuals Style guides often contain specific guidance on the use of visuals in documentation, ensuring alignment with your organization’s branding. Uniformity in screenshots and other visuals, regardless of who creates them, is crucial for consistency. Before integrating visuals into your technical documents, review your style guide. It may have stringent rules about their use. If your style guide lacks specific guidelines on screenshots, consider tailoring the items from our Checklist for Using Images in Technical Documentation as a foundation for your own style guide. Ensure your style guide details stylistic elements such as preferred line colors, thicknesses, and callout fonts for screenshots. Establishing these elements clearly in writing promotes consistency and assists others in adhering to standard guidelines.

5.1. Five Rules for Using Images in Technical Documentation

The power of visuals lies not just in their use, but in their thoughtful implementation. We’ve distilled a set of best practices from industry that you can use to maximize the usefulness of visuals in your documents, regardless of their format.

Example

Here’s a simple example of a captioned image, using typical best-practice elements such as outlined boxes and contrasting colors and font sizes. This is from Chapter 24: Translation Theory.

Note

Ensure Copyright Compliance Always be vigilant about copyright when sourcing visuals. Remember, citing a source does not necessarily equate to having permission for use.

5.2. Screenshots

If you’re a technical writer working on software documentation, you will be involved in taking screenshots and adding them to your documentation. If you’re thinking to yourself, “How many screenshots do I include?”, the answer may range from “None” to “As many as possible.” The quantity of screenshots you use is determined by many factors. While screenshots can improve the quality of your technical writing and provide a visual medium for users to complete their tasks, they may be a hindrance if not used properly.

To ensure high-quality screenshots for technical documentation, it’s crucial to have a well-organized process in place. The sequence below outlines how you can systematically source and capture screenshots.

1. Prepare: Verify that you have access to the relevant software or user interface you wish to document. Determine if you’ll need administrator-level access to explore all the software’s functionalities. For more information, see Chapter 9: Collect Information > 3.2. Secure Access to Hardware and Systems.
2. Consult the Software Team: The software team is often busy with development tasks. Ensure that taking screenshots won’t disrupt their workflow.
3. Check the Style Guide: Look for specific guidelines for taking screenshots. This helps in maintaining a consistent quality across all captures. If your style guide doesn’t have any guidelines, use the Checklist for Using Images in Technical Documentation. You should also look for templates or best-practice examples that you can easily turn into guidelines.
4. Select Tools: Identify the screen capture tool you’ll be using. Most operating systems, including Windows, Linux, and Mac, have built-in tools for basic screen capturing. For more efficient image editing, capturing, and captioning, many technical writers use software like SnagIt.
5. Capture: Start capturing the screenshots, adhering to the guidelines you’ve set. Make sure the images are clear, focused, and relevant to the topic by following our Checklist for Using Images in Technical Documentation.
6. Enhance Images: After capturing, use image editing tools to crop, enhance, and manipulate the screenshots as needed.
7. Store and Organize: Store the screenshots in an organized manner, making it easier for future updates or revisions.

By following this sequence, you not only facilitate the process of capturing screenshots but also improve the overall quality of your technical documentation.

Tip

Tailoring Your Captures to the User’s Device Keep in mind how users will interact with the software. Will they be using a desktop computer or a mobile phone? This distinction is crucial, as screenshots will appear differently in these varied environments. Tailoring your captures to the user’s device improves the clarity of your documentation.

5.3. Diagrams and Photographs

If you’re a technical writer working on hardware or procedural documentation, you’ll need to understand how to source, capture, and caption diagrams (such as flowcharts, hardware component diagrams, and infographics) and photographs (for example, of equipment in the field). Hardware and procedural documentation may even involve a combination of screenshots and visuals, for instance if a task involves an element of interaction between software and a physical device.

The steps below describe how to source and create high-quality diagrams and photographs for technical documentation.

1. Prepare: Define the purpose and context where the diagram or photograph will be used. For equipment photographs, make sure you have access to the hardware or field location.
2. Consult the Team: Discuss with relevant teams (hardware engineers, field operators, and others) to ensure that capturing visuals won’t disrupt workflows.
3. Check the Style Guide: Consult your style guide for visual elements other than screenshots. If it’s lacking, develop guidelines by referring to the Checklist for Using Images in Technical Documentation. You should also look for templates or best-practice examples that you can easily turn into guidelines.
4. Select Tools: Choose appropriate software for diagram creation, such as Visio, Lucidchart, or specialized engineering software. For photographs, ensure you have a high-quality camera.
5. Capture or Create: Either capture the photograph or create the diagram according to the established guidelines. Ensure clarity, focus, and relevance.
6. Enhance Images: Use image editing tools for cropping, color correction, or adding labels and callouts to photographs. For diagrams, ensure that lines are clear and text is legible.
7. Store and Organize: Store these visuals in an organized manner to facilitate future updates or revisions.

6. [Practice] Working with Graphic Designers

If you’re collaborating with a graphic designer—perhaps on a project where your copy and visuals will be transformed into a designed or printed manual or report—there are key considerations to keep in mind for a smooth process. By adhering to these practices, you can enhance the visual consistency of your technical documentation when collaborating with graphic designers and reduce the likelihood of rework.

7. [Practice] Translation Considerations

If your technical documentation will be translated, there are some considerations you should take into account when you’re including visuals:

• Sourcing Visuals in Different Languages: If you’re creating visuals that include user interface text (like software), you’ll need to consider where you’ll source visuals for foreign-language translations. You may not be able to take them yourself, as the use of another language will make it complicated for you to navigate the software. If this is the case, talk to the software development team early to make sure they can arrange for someone to provide the screenshots in the languages required when needed.
• Use of Numbered Callouts: If the software is in a single language—or you’re documenting hardware or field equipment—then it is better to use numbered callouts with an explanatory table below the visual. This will reduce translation costs, because only the text in the table needs translating. The translation partner won’t have to edit graphics, which will result in additional costs.

For more information about translating technical documentation, see Chapter 24: Translation Theory and Chapter 25: Translation Practice.

8. [Template] Checklist for Using Images in Technical Documentation

Checklist for Using Images in Technical Documentation

1. Clark, R. C., & Mayer, R. E. (2016). E-learning and the science of instruction: Proven guidelines for consumers and designers of multimedia learning. John Wiley & Sons. ↩︎
2. Clark, R. C., & Mayer, R. E. (2016). E-learning and the science of instruction: Proven guidelines for consumers and designers of multimedia learning. John Wiley & Sons, Fig 4.8. ↩︎
3. Mayer, R., & Fiorella, L. (Eds.). (2021). The Cambridge Handbook of Multimedia Learning (3rd ed., Cambridge Handbooks in Psychology). Cambridge: Cambridge University Press. doi:10.1017/9781108894333, Chapter 5. ↩︎
4. Sweller, J., Ayres, P., and Kalyuga, S. (2011) Cognitive Load Theory: Explorations in the Learning Sciences, Instructional Systems and Performance Technologies (1st ed). Springer. DOI 10.1007/978-1-4419-8126-4, p. 43. ↩︎