Screenshot guidelines and process#

When your content references a user interface (UI), consider whether you need to include screenshots. Screenshots can be helpful when text alone cannot adequately convey instructions, and users like screenshots and find them useful. However, screenshots are difficult and time-consuming to maintain, and present translation problems. Therefore, you should minimize the use of screenshots within your content.

When to use screenshots#

You can use screenshots for the following purposes:

  • Orient users in a complicated or long procedure

  • Show complex windows or dialog boxes, such as those that contain multiple subsets of information, with free-form text fields and many options available for selection

  • Emphasize a new feature or change in the UI

However, do not create or use screenshots of the following items:

  • Code samples (instead, show code samples in code blocks)

  • Dialog boxes that are easy to understand, such as drop-down lists and option buttons with few or no free-form text fields

  • Confirmation boxes

  • License agreement boxes

  • Message text (instead show message text within regular text)

  • Progress bars

  • Welcome windows

  • Wizard pages, especially Welcome pages and other simple pages

  • Tables created in another authoring tool

  • A screen that is volatile and likely to chage frequently

Screenshot alternatives#

As an alternative to screenshots, use the correct names of the UI labels with which the user must interact and the values that they must choose or enter. Show the names of buttons, options, check boxes, menus, windows, dialog boxes, and so on as they appear on the UI. For example, for straightforward instructions like, “To open a file, select File > Open,” a screenshot is not required.

Before you create a screenshot#

Install Jing to capture and edit screenshots. Jing is available as a free download.

To learn how to take a screenshot and make a callout, use the Jing capture an image tutorial.


Jing does not support Linux distributions, but you can use other programs such as gscreendemp, GreenShot, and Shutter on Linux.

Screenshots in procedures#

If you include a screenshot in a procedure, place it directly under the step that it illustrates. Do not rely on the screenshot to show information or values that the user must enter. Instead, always provide that information in the text of the steps. However, ensure that the screenshot accurately reflects the directions and values in the step text.

Screenshot checklist#

Use the following standards when creating your screenshots:

  • Size: Make screenshots no larger than 600 pixels wide.

  • Scope: Limit the scope of a screenshot to just the portion of the UI that shows the action, plus enough surrounding detail to help the user locate the item.

  • Callouts: Use only arrows and boxes for callouts. Use Red (hexadecimal color FF0000) for all callout arrows and boxes.

  • File name: Create unique and meaningful file names to easily differentiate between screenshots.

  • Titles: Titles are not required, especially for screenshots in procedures and tutorials. If you want to add a title to a screenshot for clarity, follow the guidelines in Titles and headings.

  • Personal or private details: Make sure to mask, modify, or remove any personal identifiers, passwords, logins, or other information that could compromise security.

  • <alt> property: Use the <alt> property to briefly describe the screenshot for visually-impaired readers. The following list provides some guidance:

    • For decorative images: leave alt-text blank.

    • For images with text: use the text in the image.

    • For charts and graphs: summarize the trend or take-away point.

    • For other images: What does the image represent or add to the document?