Managing Screenshots for Documentation

Preparing Your Workspace for Screenshot Capture

Before you take any screenshot in Atloria, make sure you are working in the right place. If you are updating an existing documentation version, open that version first and confirm you are not editing a different project or release. If your screenshot is meant for an admin guide, open the matching admin area such as Admin, Analytics & Insights, or Security & Audit. If it belongs to a project guide, open the exact project workspace, page, or setup screen that the instructions describe. This avoids publishing an image from the wrong area of Atloria.

Next, open the exact screen state you want readers to see. For example, if your instructions mention the Login page, show the page with the Email and Password fields visible. If you are documenting account creation, open the registration screen with the Name, Email, and Password fields on display. If the page should show a result after signing in, capture the destination screen only after the correct page has loaded.

Keep your browser view consistent across related images. Use the same zoom level, similar window width, and the same visible navigation whenever possible. If one screenshot shows the left navigation and another hides it, the page can feel inconsistent to readers. Try to keep page titles, section headers, and active menu items visible so the reader can tell where they are in Atloria.

Before capturing, clean up anything that should not appear in published documentation:

• Close unrelated browser tabs
• Hide pop-up notifications
• Remove personal bookmarks from view if possible
• Avoid showing temporary test names that do not belong in documentation
• Check for environment markers that could confuse readers

Capturing Screenshots That Match the Documented Workflow

When you capture a screenshot, show the exact moment the written step describes. If the instruction tells the reader to open Analytics & Insights, the image should show that page header and its visible content. If the instruction tells the reader to review Security & Audit, the screenshot should show that screen, not a different admin card or a later result. The closer the image matches the sentence beside it, the easier the page is to follow.

1. Open the screen the step refers to and wait until the page is fully loaded.
2. Make sure the key visual cues are visible, such as the page title, active menu item, form fields, dialog box, or status message.
3. Capture the whole area the reader needs to understand the step. In many cases, that means including the page heading and the section where the action happens.
4. If one image cannot show the full action clearly, take more than one screenshot for the sequence.

Use focused images for important actions. A full-page image works well when readers need orientation, such as seeing the Admin area or a project workspace. A tighter image works better when the reader needs to notice a specific control, such as the Email field on the sign-in page, the Password field on the registration page, or a “coming soon” notice on a feature page.

Re-capture screenshots whenever Atloria’s labels, buttons, or layout change. If a page title has been renamed, a card moved, or a section redesigned, do not keep an older image just because it is available. Readers compare the screenshot to the live screen, and even small differences can make them hesitate.

For longer procedures, use sequential captures:

1. The starting screen
2. The action in progress
3. The result after the action

Saving and Naming Screenshot Files for Versioned Documentation

A clear file-saving routine makes screenshot updates much easier, especially when the same page is revised across multiple documentation versions. Save each screenshot in the asset location your team already uses for that page or version. Keep screenshots close to the documentation they support so reviewers can tell which image belongs to which topic. If your team separates assets by project, version, or document section, follow that structure consistently instead of creating one-off folders.

Use file names that describe what the image shows. Good names help reviewers understand the screenshot before opening it and make replacement work faster later. Include three pieces of information in the name:

A name such as login-form-visible-v2 is much easier to manage than a generic name like image1 or screenshot-final-final.

Keep new screenshots separate from replacement screenshots when you are preparing a review. If one image updates an existing step and another adds a brand-new step, reviewers should be able to tell the difference quickly. This is especially helpful when a page update includes both rewritten text and refreshed visuals.

It also helps to keep two copies when your team uses cropping or annotations:

• The original full capture
• The publication-ready image used on the page

The original capture is useful when you need to adjust the crop later without taking the screenshot again. This saves time when the text changes but the screen itself is still current.

Reviewing Screenshots Before Adding Them to a Page

Before you place a screenshot into a documentation page, compare it directly with the wording on the page. The labels in the image should match the labels in the instructions. If the page says readers should click Analytics & Insights, the screenshot should show that exact title. If the instructions mention Security & Audit, the image should not show a different heading or an older label. This quick comparison catches many common problems before review.

1. Read the instruction beside the screenshot location.
2. Open the image and confirm the visible page title, menu name, field labels, and buttons match the text.
3. Check that the screenshot shows the correct point in the workflow.
4. Review the image at the size readers will likely see on the page.

Timing matters as much as labels. A screenshot taken too early or too late can confuse the reader. For example, if the text explains what appears after a successful sign-in, the image should show the destination workspace, not the login form. If the text explains a page before the user takes action, the image should not show a later result.

Look carefully for information that should not be published. Remove or obscure anything that does not belong in shared documentation, including:

• Personal names if they are not intended for documentation
• Temporary records created only for testing
• Internal environment markers
• Private project details
• Data that does not match the example workflow

Finally, check readability. After cropping or resizing, text in menus, cards, dialogs, and table headers should still be easy to read. If readers must zoom in heavily to understand the image, capture it again with better framing.

Adding Screenshots to Documentation and Change Workflows

Place each screenshot as close as possible to the step it supports. Readers should not need to scroll far to match the written instruction with the image. If a screenshot explains how to sign in, place it beside the step that mentions the Email and Password fields. If it supports an admin task, place it near the step where the reader opens Admin, chooses a card such as Users & Permissions, or reviews a page like Analytics & Insights.

1. Open the documentation page you are updating.
2. Find the step where the screenshot adds clarity.
3. Insert the image immediately before or after that step.
4. Preview the page to confirm the image size and placement make sense in the flow.
5. Save the page and include the screenshot in the same update as the related text changes.

Add a useful caption or alt text when your team’s page format supports it. Describe the exact screen or action shown, not a vague phrase. For example, identify the image as the Login page with Email and Password fields visible, or the Analytics & Insights page showing its current notice. This helps both reviewers and readers understand why the image is there.

When you revise an existing page, make sure the new screenshot replaces the old one in the current documentation version. Do not leave older image references in place if the page text has already been updated. A page with current wording and outdated visuals is harder to trust than a page with no screenshot at all.

Keep screenshot changes inside the same review or version workflow as the text update. That way, approvers can check the wording and the visual evidence together. This is especially important when a release changes navigation, page names, or workflow order. For related guidance on version work, see Managing Documentation Versions Across the Release Cycle.

Fixing Common Screenshot Problems

The most common screenshot problem is an image that no longer matches the current Atloria interface. This often happens after a release changes navigation labels, page headers, or card names. If a screenshot shows an older layout than the one readers now see, replace it rather than trying to explain the difference in the text. A fresh image is usually clearer than a note about a past design.

Another frequent issue is poor image quality. If the screenshot looks blurry, too small, or cropped so tightly that readers cannot see where they are, take it again. A good screenshot should make field labels, headings, and action areas readable without guesswork. This matters most on pages with multiple cards, side navigation, or notices that depend on visible context.

Use this table to match the problem to the likely fix:

If an image does not appear in the page preview or version review, check whether the file was renamed, moved, or left out of the same update as the page content. Broken references are often caused by a mismatch between the image name used in the page and the actual saved file name.

If screenshots are missing across versions or shared workflows, the next guide goes deeper into library-level organization: Managing Enterprise Screenshot Libraries.

Overview

Managing screenshots in Atloria means more than taking a picture of a screen. You are creating visual proof that a page, button, form, or workflow looks the way your documentation says it does. Good screenshots help readers confirm they are on the right page, especially in areas such as Login, Register, Admin, Analytics & Insights, and Security & Audit. Poor screenshots do the opposite: they make current instructions look outdated even when the text is correct.

This guide focuses on the full screenshot workflow inside documentation work: preparing the right Atloria workspace, capturing the correct screen state, saving files in a way that supports versioned documentation, reviewing images for accuracy, and adding them to the same change process as the text update. It also covers common problems such as outdated navigation, unreadable crops, and broken image references.

Use this guide when you are:

• Updating a documentation page after an Atloria interface change
• Adding screenshots to a new how-to page
• Refreshing visuals for a new documentation version
• Reviewing whether screenshots still match the current release
• Fixing image issues before approval or publishing

If you need help with the basics of signing in or creating an account before working in Atloria, see Accessing and Registering Your Atloria Account. If you need broader project context before updating documentation pages, Working with Project Lists and Dashboards is a useful companion.

Prerequisites

Before you start updating screenshots for a documentation page in Atloria, make sure you have access to the workspace and content area where the change belongs. You do not need advanced setup knowledge, but you do need to be able to open the correct project, documentation version, or admin area that the screenshot will represent. If you cannot reach the right page, your screenshot may show the wrong context or an incomplete workflow.

Have the following ready before you begin:

• Access to the correct Atloria account and workspace
• Permission to open the page or area you are documenting
• The documentation page or draft that will receive the screenshot
• A clear understanding of which workflow moment needs to be shown
• A browser window prepared for clean, consistent captures

It also helps to know whether you are documenting a public-facing workflow or an internal workspace view. For example, a screenshot of the Login page, Register page, or a project workspace should be captured differently from an admin-only view such as Analytics & Insights or Security & Audit. Open the exact destination before you capture anything.

If you are working as part of a version update, confirm which release or draft is active so your images match the same review cycle as the text. For guidance on related page editing work, see Creating and Editing Documentation Pages. If you are troubleshooting sign-in before you can reach the right screen, use Signing In to Atloria and Solving Access Problems.