Hey, look at that! I’m posting in my other blog for once. Careful…the apocalypse might happen before you finish reading this post.
So, this is something that I’ve been meaning to write about for a while: screenshots and images in manuals – do we need them? In my opinion, yes and no: It all depends on the situation. I know that seems like a copout answer, but hear me out on this. Like anything, there is a time and a place for it. Also, being just a technical writing team member might leave the decision out of your hands anyway.
Screenshots and images should enhance the manual and make the steps or text clearer. It’s fair to reason that nearly all users are going to be using the item or software while using the manual, so clear text instructions will usually be sufficient. For this reason, when I’m writing a software manual, I will always include at least 1 screenshot in the beginning chapter outlining the parts of the user interface. This is so users will know where I’m talking about on the screen if I write “In the left pane” or “Select Job Accounting from the main menu.” You’ll notice that nearly all embedded help files in software will be primarily text based, and user manuals seem to be heading that way, too. Since I write software manuals, this is where my personal writing experience lies. For hardware manuals or instructions on putting something together, starting with what is included and labeling them so the users will know to what’s being referred is usually the first step.
I’ve recently had a project manager than I work with quite frequently tell me that he wants all screenshots removed from user manuals for his projects. What purpose could this serve? I believe his reason for this is simply “laziness,” really. I use that term loosely since he’s not the one doing the work, but he doesn’t want any images because that means one of his engineers will have to capture the foreign language screenshots for me when it comes time for translation. This comes down to each screenshot for 7 or 8 languages typically and can add up if you have 10+ screenshots. Honestly, in my opinion, this particular PM has no idea what goes into writing a manual and doesn’t know what one needs to make it usable, but I digress. I had to argue with this particular PM for several weeks to include a few screenshots where I thought they were necessary to explain difficult parts of the UI when different sections dropped down or different areas had the same sub-menu names (this was a very complex piece of software and gave me multiple headaches on a daily basis). He didn’t expect me to be so adamant about it because, quite frankly, in Korean culture, subordinates don’t question their superiors and are supposed to do what they're told without question. Poor guy didn’t know what hit him when he had to work with the only American tech writer on the team that has no problem giving opinions, but that’s for a different topic. The point that I tried to make to him was no matter how intelligent or knowledgeable about the network the users of the software are, they’re learning a new piece of software and will need to know where what I’m telling them to do is located.
Since I’m usually learning the software as I’m writing the manual, I think I have a pretty good idea of where things could get confusing for the user since I’m essentially a new user when I start writing the manual. However, in some situations, your audience might require more than you think they do. I write primarily for enterprise software, so I don’t typically have to worry about general home users trying to use something I’ve written. However, once in a while, I do write a manual for some software included with our SOHO (small office home office) printers. For these, more screenshots might be required since I really need to write for the most software illiterate user that I can imagine. To do this, I try to imagine explaining using the software to my mother, who, poor woman, was one of the most technologically impaired people I’ve ever known and never even owned a computer or a cell phone let alone a printer *fondly remembers many frustrating phone conversations explaining how to use the DVD player or program the VCR*.
With most manuals being provided online or on installation CDs as PDFs, the argument of printing costs doesn’t really hold up anymore. However, if manuals are provided in hard copy, this could very well be a factor – especially outside of the software realm. For hardware, in my division (printers and computers) we also provide hard copy manuals. If you’re across the office trying to use the multi-function printer (MFP) and need to know how to do some tricky copying task, running back and forth between your workstation to consult a PDF and the MFP just isn’t practical. There should, of course, be a manual tucked away somewhere by the machine for quick reference. We also tend to provide installation guides for software as hard copies. Funny story about that really quick for y’all: I had finished writing a manual for some software and it was released. A few weeks later, one of the engineers contacts me and says they need a separate installation and setup guide ASAP since customers have requested it. I asked him why since that information was provided in the first chapter of the user manual. He tells me that users can’t access the manual until the software is installed and set up. O_o Forehead, meet Desk. I didn’t know whether to laugh or cry so I just looked at my teammate and said, “They have got to be kidding me,” and explained the situation to her. She was as confused as I was. Anywho…screenshots and images.
Speaking of hardware manuals or instructions on building something, what about drawings vs. pictures? Drawings. Always. Unless there is absolutely no way to provide drawings, always try to include drawings instead of pictures. You might think that a picture would provide more detail, that isn’t the case. Remember back in your college days when you’re putting together that cheap furniture from IKEA or a bookshelf from Wal-Mart? What did the directions look like? Yup. Drawings. Pictures introduce too much distraction away from what you’re trying to draw attention to. With drawings, you can provide as little or as much detail as necessary and make things sharper than with a picture. If you have to include pictures instead of drawings, try to use as crisp of an image as possible and have them be in color. If you need to provide arrows or markings on the picture, use a color that will contrast well and make things clear instead of more confusing.
So, to sum it up, use screenshots only where they’re needed and sparingly. Using too many will just increase the visual length of the steps and frustrate users: I doubt users will need a screenshot for “Click OK.” You’ll have to really put yourself in your users’ shoes to do this. For pictures vs. drawings for physical items, always go with drawings when possible to make things clearer for your users.
