The fine line between not enough and too many images in user-docs
Technical Communication like any other field keeps pace with the times and adopts new approaches and trends, especially when it comes to the visual aspects. Even more those trends were influenced by the pandemic and the new reality that made us move to the online universe almost completely. Thus, such phenomena as printed documentation became even more rare.
So, if a technical writer doesn’t need to adapt documentation for both types of output — printed and online, we’ve got a new push for the development of motion graphics and digital visuals for our user documentation. Now, you’re more likely to stumble upon user docs enriched with GIFs, animated videos, or interactive diagrams.
But the more visual types we develop, the more urgently the question arises: “How many visual pieces do we need to help users understand the idea without annoying them with image overflow?”
This question is controversial, as many specialists tend to think that the number of screenshots depends on the personal preference of the author and can be considered as a part of their own brand style. Like, yeah, Simon adds a detailed screenshot after each tiny step, it’s a killer feature of his own “author’s style”. Is Simon a good specialist? Hmmm, this is a tough question. 🙂
Nonetheless, the TechComm community can be divided into two camps — the first, who are afraid of making their guide too long, and thus, avoiding visuals at all, and the second — as our Simon, who adores visuals and deadly overuses them. The first side defends the opinion that screenshots may be overwhelming, increase the content volume and make a 5-stepped guideline long as a fairytale and as intimidating as a chapter of a rocket science book. Meanwhile, the opponents believe that an image speaks a thousand words and weighs more than text, as it enables the reader to quickly scan the needed parts. Both of those statements are true to some extent.
Hence, there are two key moments to consider when thinking of a well-balanced proportion of images to text:
1. Your target audience
2. The guide’s purpose
Target audience
The key and the first moment in creating a handy documentation is knowing your target audience. Look at your product once again, imagine its average user, define how computer literate they are, and then try looking at your documentation from their perspective.
To illustrate, you’re writing step-by-step guidelines to teach how to sign up for the WhatsApp mobile application. Probably, the audience that needs this guideline is low-skilled. Imagine the core of your target audience — the most typical person who uses it. Who is that? How old are they? How do they usually interact with technology?
So, let’s imagine our target person: 60-years old Claire, who got her first smartphone as a birthday gift from her daughter. She had never interacted with something similar as she had feature phones before. She doesn’t know what “the three-dots button in the upper-right corner” means. Would Claire like to see screenshots after each step? Definitely yes. But what if we omit the visuals and just write a 15-stepped numbered list? Probably, our Claire would be scared of the wall of text, then think that this is above her head and close the page.
In contrast, imagine you write the user assistance for the Adobe Photoshop desktop application. Once again, who is the typical user? What are their age and skills level? Off the top of my head, it might be a student, who has been using computer since his early age and doesn’t need extra visuals to find the File tab. Our student just wants to grab some precise and tiny chunk of information and go on sailing through the app.
For that case, we’ll end up with a simple numbered list and may add screenshots of the buttons incorporated right into the sentences, just to keep the guideline short and to the point, but at the same time, the buttons’ screenshots will make it easy for quick scanning. Another suitable approach here is to add one screenshot at the beginning or at the end of the guideline just as a summary.
The purpose
Sometimes, when we talk about illustrating the guidelines, we should determine not only the skill level of our users but also the complexity of the topic we teach them. Let’s take Adobe Photoshop as an example once again.
So, imagine you write a set of topics to introduce your user to some basic functionality of the app. You show how to change a shape’s color, how to combine several layers into one, or how to draw curves with the pen tool. Undoubtedly, such procedures are going to be short and will include up to five steps, thus, don’t need to be accompanied by screenshots after each step. In such cases, you can omit the visuals at all or use only one screenshot with numbered callouts for the whole procedure.
On the other hand, let’s think of more complex procedures in Adobe Photoshop. Let’s imagine writing a topic on how to restore the old black and white snapshot from a family album. Firstly, the user should scan the photo and paste it to the app, then use the stamp tool to cover scratches and bends abrasions, and then, use a patch tool to draw the background on a torn corner.
So, your user needs to apply a bunch of tools and features and the whole procedure will consist of 20+ steps, where each step requires alignment on the current result. Each step, therefore, should include a screenshot just for your user to be on the same page with the steps and not get lost in the middle. Moreover, in this case, the screenshots enable the reader to realize whether further guidelines will bring him to the desired destination.
Sum-ups
In a nutshell, the cornerstone of any indeed handy guide is an author’s empathy — the ability to walk in the reader’s shoes. Just imagine WHO and HOW will use your user guide and if you clearly see the portrait of your target audience — congratulations! Consider that you’ve got a solid ground.
