Screenshots and diagrams
This page provides guidance for capturing and publishing screenshots, inline images, animated .gif files, and diagrams (process workflows) on Experience League.
On this page:
About screenshots screenshot
Screenshots are visual representations of Adobe product interfaces. They can help convey important information to readers. However, screenshots are expensive to localize and maintain. Carefully consider the value of each screen that you publish, and be consistent in how you present them.
When to use a screenshot
Use screenshots:
- To show a specific feature you’re documenting
- To show meaningful demo data, results, or the goal described in a procedure
- To orient readers when navigation is unintuitive
A screenshot should immediately follow the numbered step or action that causes the screen to display, indented on a new line.
Example
Here is a step and its resulting screenshot for a Day filter:
-
On Page view reports, click Weekday/Weekend.
Pro tips:
-
Include surrounding interface elements as reference points.
-
Avoid doctoring screenshots with boxes and arrows unless necessary to prevent confusion. Where possible, use the interface’s built-in selection and navigation elements (cursor, focus shading in menus, etc.) to guide readers.
-
Limit full-page screenshots to broad, concept topics like overviews, introductions, and tutorial videos (example).
-
Click-to-zoom: This syntax lets you use markdown syntax to reduce the size of an image, which expands to its original size when clicked. Use click-to-zoom strategically, such as when you have a large screenshot on a long page, and you want to reduce scrolling.
When not to use screenshots
Do not use a screenshot:
- If the screen shows customer data.
- When bold UICONTROL is sufficient for navigation in a step.
- When the screenshot adds no information, only repeats what is documented.
- When it clutters the procedure with distracting elements and features (typical of full-page captures).
- In table cells. Small icons or thumbnails are acceptable in cells.
- Of a third-party interface. (See Third-party interfaces on this page.)
Run Snagit
You can use any screen capture tool you want, but Snagit is recommended and documented for writers. You can download Adobe’s discounted version (with manager approval). Your cost center is billed about $10 annually per employee.
-
Open the System Tray in Windows
Configure Snagit for screenshots themes
Import the Experience League Theme
-
Download and unzip the Experience League Theme locally.
-
In Snagit, open the Editor.
-
Click the Arrow tool to display the Quick Styles panel, which shows the Themes menu.
(Any tool that uses a theme displays the Theme menu in Quick Styles.)
-
In the Theme field, click Import….
-
Locate the uncompressed Experience League Theme file (locally), then import it.
The Experience League Theme uses the color settings described in Callouts.
To capture a screenshot
-
Open the Capture window (either from the Snagit Editor, or the widget, or the taskbar).
-
On the Capture window, configure capture settings (Image, Video, Steps, Border, etc.).
Settings defined in the Capture window are saved until you change them.
-
Click Capture.
-
After the Capture window disappears, make your selection.
-
The Snagit Editor dispays after you create the capture.
The Snagit Editor works like a standard image editor.
Alternatively, you can:
-
Open any existing image for editing.
-
Use File > New > New capture from clipboard.
-
-
In the Editor, use the Arrow tool to see the Quick Styles panel with the ExL theme.
-
Use the Experience League Theme to add callout elements (if needed).
-
To resize an image, click Image > Resize Image.
-
Saved the file as a PNG to your repo’s assets folder.
Callouts, colors, and pixels callouts
Use the Light theme (not the Dark theme) in the Experience Cloud UI preferences. Dark-mode screenshots contrast too much with the rest of the ExL content displayed.
If you need to add callout elements, following the UX requirements shown here:
- HEX Color: #EB1000 (Red, RGB 235, 16, 0)
- Line weight: 3px
- Rectangle corner: 8px corner radius
- Arrow style: Rounded end caps, rounded arrowhead corner
- Border (optional): #E8E8E8 (Unicorn Silver, RGB 232, 232, 232), 1px line width
- Typeface/font: Adobe Clean
Shadow settings in Snagit for white drop-shadows on red arrows (over dark backgrounds)
- Shadow: white, bottom right
- Width 10
- Opacity 80
- Distance 7
- End size 3
Examples
Borders and width
File size recommendations (in pixels) requirements
- 2000px max for large screenshots
- 672px for medium screenshots
- 300px for small screenshots
- 30 or 35px for icons
Inline images and icons inline
For inline images (icons):
-
In most cases, refer to an icon’s label instead of using an image.
The icon’s name should appear as a tooltip. If any UI element does not have a label, suggest one to your product team.
-
Find product icons in Spectrum.
-
Do not add extra space below the object you’re capturing. Our tools align the bottom of an image with the text baseline.
-
Keep inline images dimension sizes small (around 30 or 35 pixels high, as a guideline).
Steps to capture a screenshot create-screenshot
Screenshots in product documentation should be placed on a separate line, indented. Place it after the step that causes the screen to display.
Occasionally, a standalone screenshot in an overview (concept) might be helpful, but ensure that readers know how to find any page you are showing.
-
Install an available tool like Snagit, and learn how to use it.
-
Maximize the browser.
-
Save the image as PNG, using lowercase characters and hyphens.
-
Follow the image size guidance described in Callouts, colors, and pixels.
Text in screenshots should be readable but not oversized. Where possible, reduce screenshots to an equal width to maintain a consistent layout.
-
Place the screenshot after a navigation step, indented, left-justified with the step’s text.
-
Add meaningful alt-text to help with SEO.
Markdown syntax example: 
The alt-text can be the feature name, page name, or task heading name.
For more on syntax, see Images (Markdown Syntax Guide).
Example screenshots
Here are a few example scenarios and ways to handle them with screenshots.
Show don’t tell - user-defined interface elements
In some situations, a screen can be better than words. This advice applies when you want the reader to perform an action, but their interface contains custom elements created during implementation.
For example, the following Organization screenshot shows how to perform step 5:
The screenshot also conveys several tasks that a customer can perform (verifying, viewing, and searching for organizations).
Rather than altering the image with an arrow or box, that screen uses the cursor to point to the interface element.
Screenshots in an overview
In an overview screenshot, the screen’s purpose is to show the product rather than describe how to use it. There’s no need to place this kind of screen in a procedure (or even document how to get to the screen) because the goal of the page is conceptual.
Diagrams and animated GIFs diagrams
Diagrams are process workflows that visually convey complex information.
Animated GIF files are supported but can be a problem for localization.
The guidance for these files is similar:
-
Provide explanatory text for the diagram or image. If an image cannot be localized, the accompanying text is important for readers. (Don’t rely only on the image to convey information.)
-
Preserve your source file for localization. For example, if you used Illustrator for a diagram, save the
.aifile in the assets folder along with the.pngoutput file.Saving your source file enables a translator to localize the graphic natively. The translator can create the output file.
-
Place text outside of bordered boxes. When text is localized, the size of the text changes, which affects the size of the bordered box. Keeping text outside of boxes facilitates localization.
-
Consider using icons rather than (or in addition to) text. Icons are universal. Adobe Spectrum provides good information on design standards.
Third-party interfaces third-party
Do not document third-party interfaces. Doing so can create:
-
Difficulty localizing content
-
Content quality and maintenance problems
-
Legal risks (if the UI is not in our partner program)
If you need to walk customers through a third party’s interface, document only the name of the task being performed (as officially documented by the third party), then link to outside help. You can integrate that action into your steps.
Remember, add DNL to third-party company and product names. If you need to describe their features, that’s okay, but do so generally.