How to take screenshots correctly: some practical tips

If you have ever made a help file or user manual for your app, you’re sure to have noticed the unexpected amount of time and effort producing screenshots takes.

You’d think a screenshot was “a second’s work, Alt+PrintScreen and Ctrl+V!”.

Some clients are surprised to hear that a screenshot in a user manual can cost $2 or even $5.

In this article, I’ll advise you on how to take screenshots correctly, why they’re not just “two clicks” and what pitfalls an inexperienced screenshotter may meet. See it as a checklist or a list of practical tips for those who write software documentation. I hope it will help you avoid disappointments, and delight your users with beautiful, easy-to-understand images.

What Needs a Screenshot?

Needs a screenshot:

• Layout of the main elements and areas of the interface with captions. For example, the toolbar, status bar, main menu, pop-up menu. This avoids needing to explain in words: “On the bar on the left, click on the second button from the top”.
• One main screenshot for each chapter of the manual. This is in case the user has not read the previous chapters and used search instead.
• A screenshot for each action that significantly changes the state of the system, interface or data.
• Pop-up (modal) windows.

Does NOT need a screenshot:

• Install and uninstall wizards (unless there is something really unusual about a lot of the settings).
• Login pages.
• Standard dialog windows (open, save).
• Endless drop-down lists (select language or country).
• Individual buttons (use text).
• Anything that is already described in detail or included on other screenshots – better to provide a link.
• Screens containing details about version, rights, etc. If a new version comes out, you may need to change numbers or letters on every single screenshot.
• Pieces of code, configs, etc. Better to insert these as formatted text – it looks better, and users can easily copy them.

Main principle: the user should know where to find the current page (dialog, menu), and understand the end result of their actions. Text should be divided logically into paragraphs, and headings should reflect the main actions. Screenshots are required to make it easier to search for elements and give the user reassurance they are on the “right track”, i.e. everything looks the same on their screen as on the screenshot.

Process of Creating Screenshots

1. Setting up the environment. Select a single style for the windows and fonts in your operating system. If the interface is resizeable, set the width and height of the browser or program window and do not change them while you’re capturing your screenshots.

Life-hack: If you accidentally close the window, the window size may be reset and you probably won’t be able to restore it precisely. To avoid “losing” these measurements, take a screenshot of the window and the whole screen together and mark the corners of the window in red, then set this image as your desktop background. Perhaps someone knows an even simpler or neater method?

2. Preparing data. Fill the app with examples that are realistic and solve specific user problems. You can think through several situations: ones as simple as “Hello, World!” as well as more complex ones for advanced users.

Preferably, object names and settings should not change within a single section. For example, in Chapter 1, user Hippolytus created a note on “How to cook fish”. And in Chapter 2, you need to explain how to customize notes. Of course, it’s best to explain how Hippolytus applies a red fill to the note he has already created. This simple approach reminds the user of their previous actions and gives them the full picture.

Don’t forget to include “real”, readable data in your system, create presets, prepare templates, make backups, etc.

If you are producing screenshots for documentation in a foreign language, make sure that any names are appropriate to the target market, or common English names (“Andrew” is okay, whereas “Vanja Babushkin” might not be), and make sure all text is in the appropriate language.

3. Capturing screenshots. Everything here depends upon your tools, but these are my main recommendations:

• If possible, only capture the relevant areas of the interface and make the screenshot as compact as possible. This way, it will fit on an A4 sheet of paper and have a small file size.
• Like taking a photograph, take care over the composition, do not chop off parts of elements at the edges of the screen. Try to make the screenshots identical in terms of width and height within each example.
• To save time, take a whole series of screenshots together. You can capture extra screenshots you hadn’t planned, just in case – they may come in handy later when you are making revisions or editing.

4. Editing. You won’t always manage to prepare neat, varied data, avoid typos or model a specific situation (error, failure, large cash balance). In these cases, there are at least two solutions:

• Edit the code and page style in your browser (right click > Inspect element and away you go…), if you’re dealing with a web application.
• Change captions and combine elements from different screenshots in an image editor.

It’s best to know how to do both of these, and combine approaches depending on the situation.

I want to stress that while it’s possible to add borders, cropped edges and shadows to the screen in the editing process, it’s better to do this with styles in your help editor.

5. Saving. Give the screenshots unique, meaningful names, obeying a specific format, such as general_settings_privacy. It’s best to avoid spaces, uppercase letters, and excessively long names. This approach ensures universality and correct functionality when your online help is made available on different servers.

It’s best to save your screenshots to the cloud using sharing, tags and version control. For search convenience, it’s best to divide folders containing screenshots into subfolders, according to the structure of the program interface.

6. Inserting into the text. See the “Formatting” section.

7. Checking. Put completed sections aside and check them the next day. Or, even better, get a tester and designer to read the text and look over the screenshots.

Tools

Desktop Tools

• Snagit (Win, Mac). One of the most popular programs for taking screenshots. It’s made up of two modules:

— Capturing Tool. Features: enlarge selection, automatically define interface areas, capture full-screen shots, time-delay for pop-up elements, video recording.

— Editor. Features: arrows, annotations, effects, borders, sharing.

The only negative point I’ve found is that the editor could include more settings and effects.

• Shutter (Linux). Basically, this is Snagit for Linux – open source, naturally.
• Adobe Photoshop (Win, Mac). I recommend using this for hardcore editing and complex effects. Screens from one section can be saved as PSD-file layers, and you can use macros and scripts to work miracles with large numbers of files.
• GIMP (Win, Mac, Linux). Free Photoshop substitute. You can find an excellent article on automated screenshot processing in GIMP here.
• ImageMagic (Win, Linux). Set of programs (console tools) for reading and editing image files in a huge range of formats. Ideally suited for batch-processing screenshots.
• Visio (Win). Well, why not? Ideal as an editor for highlights and annotations, especially if you have already bought the whole MS Office package.
• Dropbox (Win, Mac, Linux). This desktop client can automatically save all your screenshots to disk and to the cloud, and copy the link to the clipboard.
• Joxi (Win, Mac, Linux, Chrome plugin). The same functionality as Dropbox, plus the ability to add captions and effects on the fly.
• LightShot (Win, Mac, Chrome, Firefox plugin). The same functionality as Joxi, plus the ability to edit screenshots in free online editor Pixlr.

Browser Plugins

• Awesome Screenshot
• Fireshot

HATs (Help Authoring Tools)

Many HATs have built-in modules for capturing screenshots:

• Dr.Explain. “Intelligent” capturing and annotation of screenshots is this program’s main selling point. It identifies the structure of the window, and can automatically detect and annotate all elements of the interface. The editor itself includes numerous styles for arrows, numbers, etc.
• Help+Manual. More expensive than Dr.Explain, and the screenshot capturing module isn’t as good. But can be useful, especially since annotations are stored in a separate XML file, which can be translated during localization.
• MadCap Flare. Fairly expensive editor, the screenshot capturing module is nothing special, but all the main functions are there. The fact that you can assign your own styles for images is appealing.

Tools for Creating Animated GIFs

To show dynamic actions (e.g., tagging text, autocomplete, menus), screenshots and text are not enough. You can create a video tutorial, but this can be quite pricey, and has a bigger file size than images. It’s better to record a GIF animation (example). These tools will help you:

• GifCam (Win) — free.
• ScreenFlow (Mac) — paid, can also capture and edit video.
• LICEcap (Win, Mac) — free.

Image Compression Tools

• ImageOptim (Mac) — free.
• RIOT (Win) — free.

Formatting

Work out the optimal format for your screenshots. Basically, these are:

• png – for interfaces.
• jpg – for photos.
• gif – for animations and icons.
• ico – icons.

Each screenshot should have an id, alt, title, number within a section or chapter.

Selectwidth, height, and resolution:

• for print (width no bigger than A4, remember the page divisions and insert page breaks where necessary).
• on-screen (how the screenshot will look on tablets and mobile phones, taking into account the issues of taking screenshots on Retina displays);
• combined approach – Conditional Output (Help+Manual, Confluence — Scroll Versions plugin, Flare). Using this approach, you can take several versions of each screenshot.

Remember, text on screenshots must be legible without zooming in.

Think through the position of screenshots in relation to the text, and alignment. If the width of the screenshot is small, you need to make sensible use of the empty space and set text wrapping to left or right.

To show movement, you can use a combined screenshot:

If you have cut away part of the window, you can show the cropped edge using a wavy line or transparency:

Important elements or small details can be enlarged to highlight them:

For emphasis, you can also use colored highlights – leave the target element (or panel) colored and make the rest monochrome:

Add borders, shadows, arrows, captions, blurs at your discretion. The main thing is to keep it uniform and adhere to your style guide:

Use interactive elements (for HTML):

• Lightbox with an image gallery, like in Confluence.
• Zoom (like eBay goods).
• Slider.
• Image map with tooltips (Example 1, Example 2).

And a few more tips…

Try to avoid inserting icons and images of buttons into the text, as the line spacing may change, making the layout look unprofessional. It’s better to label buttons and icons with numbers on the large screenshot, or insert icons and buttons in a separate column of a table.

Reuse standard components (icons, toolbars, dialog boxes).

Include a list of the main illustrations (ideally with links to the images themselves) after the contents or at the end of the manual.

If a screenshot contains too much data, try replacing it with a prototype, diagram or table.

If you are creating a manual for a mobile app, you’ll probably have a large number of screenshots. Show the navigation between screens. This way, it’s easier for the user to understand the interactions and transitions without even reading the text.

Take screenshots for all language versions of the software at the same time. Then when you come to localize the help pages, you won’t need to ask the translator about additional services, and the technical writers won’t have to learn Cibara, for example.

I also recommend reading this article, which contains some obvious but useful tips.

Conclusion

Well-taken screenshots improve any help file or user manual, and make them elegant and easy to understand. But creating effective screenshots requires careful preparation and for you to devote quite a lot of time, attention and energy. For example, in our work, we have come across complex products for which the screenshots cost not the usual $1-2 each, but rather $5 or even $10.

And, generally speaking, the ideal screenshot (and user manual as a whole) is one you don’t need. With the right approach to UX and UI, you can use navigation and activity patterns that are already familiar and obvious to users and don’t need a description or explanation.

It would be great if you could share your experiences of creating screenshots in the comments. Tools, process, measurements, labels, styles, saving, automation – any practical tips are welcome!