> ## Content Index > Fetch the complete content index at: https://snagitpro.com/llms.txt > Use this file to discover other available public pages before exploring further. # How to Create an SOP With Screenshots: 12 Steps - URL: https://snagitpro.com/create-sop-with-screenshots/ - Published: 2026-09-08T07:40:02.000Z - Updated: 2026-09-08T07:40:02.000Z - Description: Build a screenshot SOP your team can follow: start with a clear template, assemble it in Word or Google Docs, then check privacy, decisions and delivery. - Author: Adrian Foster - Tags: Guides, Software Documentation, Workflow To create a standard operating procedure (SOP) with screenshots, choose one task, write the actions and expected result, then capture the screen states that help the reader follow it. Add clear annotations, check private data, and test the draft with someone from the intended audience. Get the required approval before sharing the working version. You can assemble a simple guide in Word or Google Docs; a dedicated capture app is optional. Keep the instructions in real text and place each useful image beside its step. The account names, roles, menus and statuses below are fictional examples, not instructions for a specific application. Replace them with your approved process. ## SOP with screenshots template | Field | What to write | Example | | ------------- | -------------------------------------------------- | -------------------------------------------------------------------- | | Title | One specific outcome | Add a new support agent account | | Purpose | Why the procedure exists | Create the correct access without exposing customer data | | Trigger | When to use the SOP | After the access request is approved | | Scope | What is included and excluded | New agents only; role changes use a separate SOP | | Owner | Role accountable for accuracy | Support Operations Manager | | Prerequisites | Access, inputs, tools, and training | Admin role, approved email, assigned team | | Procedure | Numbered actions and expected results | Select Users, add the account, verify Pending status | | Exceptions | Stop, alternate path, and escalation rules | Stop if the email already exists; record its account ID and escalate | | Evidence | Record retained after the task | Ticket ID and account-created timestamp | | Control | Version, approval, review date, and update trigger | v1.3, approved by IT, review after an admin UI release | Copy the field names from this table into your document, replace the examples, and add a numbered procedure. Under each step, write the location, action, expected result and any warning; insert an image only if it clarifies that instruction. Your organization may keep work instructions separate from an SOP. Follow its document hierarchy instead of treating those names as interchangeable. In Word for Windows, put the cursor below the relevant step and use [Insert > Pictures > This Device](https://support.microsoft.com/en-us/word/training/insert-pictures?ref=snagitpro.com). Choose your saved capture, then Insert. For a straightforward single-column guide, use [In Line with Text](https://support.microsoft.com/en-us/word/wrap-text-and-move-pictures-in-word?ref=snagitpro.com) so the image stays at its insertion point in the text. Check page breaks instead of assuming the layout will stay perfect. In Google Docs on a computer, use [Insert > Image > Upload from computer](https://support.google.com/docs/answer/97447?hl=en-CA&ref=snagitpro.com) and choose the saved frame. Keep it directly with the instruction it supports. If you need text-wrapping or position controls, use Pages format; those controls are not available in Pageless. Preview your chosen layout before producing the whole guide. The [EPA’s 2007 SOP preparation guide](https://www.epa.gov/sites/default/files/2015-06/documents/g6-final.pdf?ref=snagitpro.com) is a historical example of purpose, scope, procedures and document control. It is not evidence that a software SOP meets current regulatory requirements. Use your organization’s current requirements for approval, records and retention. ![Visual SOP anatomy with purpose, scope, owner, prerequisites, steps, results, records, and review date](https://storage.ghost.io/c/32/ae/32ae67dc-03a1-4a24-abcb-b731d79fd904/content/images/2026/09/sop-anatomy.webp) Screenshots sit inside a controlled document. Purpose, scope, ownership, prerequisites, results, records, and review rules make the procedure usable after the author leaves. ## 1\. Define one task, trigger, and endpoint Choose one repeatable outcome and state its trigger and observable endpoint. “Manage users” leaves the reader guessing. “Create an approved support-agent invitation” gives you a narrower task to document. Name the event that permits the work to start, such as an approved access request. Then define completion precisely. In the fictional example, the endpoint is an account listed as Pending plus its ID recorded in the ticket. That status does not prove the invitation arrived or the person can sign in; those checks belong to a separate onboarding procedure. Use a decision table for short branches. Give substantially different tasks their own instructions and link them where the reader must choose. A picture can identify the visible status, but your text must explain which rule applies. ## 2\. Name the audience, owner, and prerequisites Define the reader, accountable owner and prerequisites before step 1\. List the necessary permissions, source records, approved values, tools and training. A new administrator needs different detail from the person who designed the system. Assign an owner who can confirm the process and handle corrections. Record the reviewer and approver required by your policy; they need not be the owner. The [NIH’s 2021 facilities bulletin](https://orf.od.nih.gov/TechnicalResources/Documents/Technical%20Bulletins/21TB/Standard%20Operating%20Procedures%20in%20Facilities%20Maintenance%20and%20Oversight%20of%20APFs-August%202021%20Technical%20Bulletin%5F508.pdf?ref=snagitpro.com) distinguishes responsibilities, training, review and management controls in its aseptic-facility context. Do not apply that specialized model as a universal software rule. Check the procedure using the reader’s role, workspace and relevant application version. Do not quietly grant extra access just to make the instructions work. If a second approver is required, name that prerequisite and the approved escalation route. ## 3\. Walk through the process before writing Observe the approved task with a subject-matter expert and note decisions, prerequisites and exceptions. Use an authorized test environment for risky actions. Ask what must already be true before each step and what would make the expert stop. Separate normal completion from error handling. A missing field, an administrator-only control or a delayed confirmation can change the next instruction. A click recorder does not tell you which business rule the author intended. Resolve disagreements about the process with its owner before preparing final screenshots. Record the approved route, then use your notes to outline the steps. Do not make an unapproved shortcut look official through polished formatting. ## 4\. Prepare a safe capture account Use an authorized test account with synthetic data. Confirm that staging does not contain copied production records. Hide notifications and close unrelated windows; check tabs, address bars, bookmarks and recent files before recording. Keep necessary security controls enabled. Keep customer records, employee details, credentials and private messages out of the capture. Check whether the recorder, cloud folder or optional AI feature uploads images automatically. Blurring a saved image does not undo an earlier upload or reliably remove sensitive text. Use the approved handling process when clean test data is unavailable. Before sharing, inspect the final files and any accessible originals, project history, thumbnails and share links. Our guide to [redacting personal information from screenshots](https://snagitpro.com/redact-personal-information-screenshot/) covers permanent removal and export checks. Keep private values out of filenames, alt text and captions too. ## 5\. Draft the numbered procedure before capture Write direct actions and expected results before taking the final screenshots. You may use a recorded walkthrough for notes, but edit its sequence into the approved procedure. This text outline is separate from the assembled visual draft shown later in the release diagram. The [Microsoft procedures checklist](https://learn.microsoft.com/en-us/style-guide/checklists/procedures-and-instructions-checklist?ref=snagitpro.com) recommends numbered steps, imperative verbs, location context and the actions that finish a task. Use input-neutral words such as “select” and “enter” where appropriate. Keep required confirmations instead of ending a procedure just before its Save or Apply action. Group simple actions on the same screen when they form one clear step. Split a new decision, risky action or substantial alternate path. Put short choices in bullets under the relevant step rather than forcing them into a long sentence. ## 6\. Capture only useful screen states Capture the state named in the step after the relevant content has loaded. Keep enough of the page to identify the workspace and control, but remove unrelated panels. Preview the image at the size your reader will actually see; a crisp full-screen capture can still become unreadable when reduced to a narrow column. Use these six roles to decide whether a screenshot earns its place: - **Orientation:** identifies the page, tab, workspace, or record where the action starts. - **Action:** identifies the control, field, menu, or region the reader must use. - **Before state:** shows the condition that must exist before the action. - **After state:** confirms the system accepted the action. - **Warning:** makes a destructive or irreversible choice visible before selection. - **Decision:** compares the visible states tied to two different paths. There is no fixed image count. For example, a seven-step procedure might need four frames, while a complicated setting needs both a before and an after view. These are illustrations, not a benchmark. Keep the smallest set that passes the reader test; add a short video when motion or timing cannot be explained clearly in stills. ![Screenshot evidence types for orientation, action, before state, after state, warning, and decision](https://storage.ghost.io/c/32/ae/32ae67dc-03a1-4a24-abcb-b731d79fd904/content/images/2026/09/screenshot-evidence-types.webp) Choose each screenshot for a reason: orientation, action, a required state, confirmation, a warning, or a decision. ## 7\. Annotate one action without hiding context Mark the next action with one dominant cue: an arrow, outline, number or short callout. Keep the target label visible. If readers must inspect several unrelated areas, split the frame or explain the order in the written step. Use consistent markers and a clear contrast against the interface. Pair a color cue with a label, number or shape. “Choose the red option” is not enough when the reader cannot distinguish the colors or prints in grayscale. Keep an original capture and an editable annotation source in an access-controlled project folder. Work from that source when changing a crop or size, then inspect the published copy for readable labels. Do not share the editable file when it contains concealed private data; prepare a clean export instead. If you already use Snagit, [Step Capture](https://www.techsmith.com/snagit/features/step-recorder/?ref=snagitpro.com) records actions into a numbered visual sequence that you can edit and reorder. Review the output for missing states and accidental clicks. The tool’s draft still needs your prerequisites, decisions, warnings and approval. ## 8\. Write each step as location, action, and result Use this pattern for the fictional account-invitation procedure: 1. Location: On the Users page, find Add user. Include its position only if that helps readers locate it. 2. Action: Select Add user, enter the approved work email, choose Support Agent, and select Send invite after the required checks. 3. Result: Confirm that the account appears with Pending status. Check invitation delivery separately if it is part of your actual task. Keep field values and instructions in normal text where readers can copy them. Put a warning before the risky action. If waiting is expected, identify the progress state and use the timeout or escalation rule approved for that system. Do not invent a universal waiting period. The diagram below lists the parts of a step, not their execution order: warnings belong before the action, even though the diagram lists them below the result. Replace vague wording such as “configure correctly” with the field, approved source value and checkpoint. ![SOP step anatomy combining location, action, expected result, warning, and useful screenshot cue](https://storage.ghost.io/c/32/ae/32ae67dc-03a1-4a24-abcb-b731d79fd904/content/images/2026/09/sop-step-anatomy.webp) A complete step names the location, action, and expected result. Add a warning before risk and use the screenshot to remove visual uncertainty. ## 9\. Document decisions, errors, and stop conditions Document the conditions that change what the reader should do. A small decision table can map a status or approval state to the next action. Use only rules confirmed by the process owner. For example: “If an account with the same email already exists, stop. Add its ID to the ticket and assign it to the access-management team.” In your real SOP, use the actual team and handling rule. Put the check before the action that would create a duplicate. For errors, record the message, any permitted retry, evidence to keep and the escalation owner. Do not prescribe repeated payment, deletion or access changes when the first result is uncertain. Capture an error screen only when it helps identify the documented condition. ## 10\. Add useful alt text and accessible alternatives Keep critical actions, values, warnings and results in readable text. Include the keyboard route or a link to the verified equivalent procedure, not just mouse-only directions. Follow [W3C guidance on color cues](https://www.w3.org/WAI/WCAG22/Understanding/use-of-color.html?ref=snagitpro.com): a label or shape must carry the meaning when color cannot. The [W3C Images Tutorial](https://www.w3.org/WAI/tutorials/images/?ref=snagitpro.com) says text alternatives should fit an image’s purpose and essential information. For an informative frame, “Users page with Add user outlined” is more useful than “Admin software.” Make sure the description matches what the image actually depicts; an outline is not proof a button was selected. Keep complex details in the surrounding text rather than a long alt attribute. Pure decoration can use an empty alternative when it adds no information; a necessary instruction cannot. Preview headings, reading order and images in the actual document or export. Alt text alone does not establish accessibility compliance. ## 11\. Test the SOP with an uncoached reader Ask a person in the intended audience who did not write the SOP to follow it from the documented starting point. Use an authorized safe environment and obtain any consent needed for observation or recording. Observe without hints, but stop immediately if there is a safety or privacy risk. Record each hesitation, incorrect choice or missing result. Use these categories to decide what to change: - **Missing prerequisite:** add it before step 1. - **Wrong starting state:** clarify the trigger and orientation. - **Unclear action:** name the control and simplify the screenshot cue. - **Hidden decision:** add a rule or decision table. - **No confirmation:** state the expected screen state or retained evidence. - **Access failure:** correct the role, permission, or escalation path. After material corrections, repeat the affected route and its downstream checks. Test meaningful branches as well as the normal path. One successful reader run can reveal useful evidence, but it does not prove every role or exception works. Let the owner set the acceptance criteria for the task’s risk. ## 12\. Approve, publish, and maintain the controlled version Get the required review and approval before making the SOP effective. Record its ID, owner, version, approver, effective date and next review date. Complete any required staff training before use. Keep one authoritative working copy; mark or withdraw obsolete working copies while retaining records required by policy. Open the guide as an ordinary reader, not only as its author. Check sign-in and link permissions, images, searchability, print layout and any phone or shared-device route the audience uses. Test the exported file too; an accessible source does not guarantee an accessible PDF. Set a review interval and event triggers with the owner. Recheck after relevant UI, role or policy changes, incidents, repeated reader errors and broken links or images. The release diagram summarizes safe capture, assembly, expert review, reader testing, approval, publication and maintenance; failed checks return the draft for correction. ![Visual SOP release gate from safe capture and expert review to reader test, approval, publication, and update](https://storage.ghost.io/c/32/ae/32ae67dc-03a1-4a24-abcb-b731d79fd904/content/images/2026/09/visual-sop-release-gate.webp) Safe capture creates evidence. Expert review, an uncoached reader test, approval, controlled publication, and event-based updates make the visual SOP dependable. ## Example: a six-step screenshot SOP This six-step example describes an invented account interface. It is a writing pattern, not a tested product workflow. The address taylor.lee@example.test uses a [reserved testing domain](https://www.rfc-editor.org/info/rfc2606/?ref=snagitpro.com); do not expect it to receive internet mail. For a real delivery test, use a mailbox and environment your organization controls and has approved. 1. Open the approved request. Confirm the employee name, work email, start date, manager and Support Agent role. Stop and return the request if approval or a required field is missing. 2. Open the Users page. In this fictional administration workspace, select Settings > Users and confirm the Users heading. An orientation image is useful if readers could start on several settings pages. 3. Check for an existing account. Search for taylor.lee@example.test in the safe demonstration environment. If a match appears, stop and record its ID in the request rather than creating a duplicate. 4. Enter the approved details. Select Add user, enter the demonstration address and choose Support Agent. Mark the role field in the training image because the choice affects the permissions being requested. 5. Demonstrate the invitation action in the authorized test environment. Select Send invite and check for Pending status. Use this frame to explain the expected state, not as proof that an email was delivered or a person signed in. 6. Record the result. Add the account ID and creation time to the test ticket and assign the separate onboarding check. Apply your team’s ticket-completion rule; an invitation does not automatically finish onboarding. Keep the illustrative screenshot in the SOP and execution evidence in the approved ticket or audit system. Replacing the SOP image with a real employee’s record after each run would mix instructions with private operational data. For repeated capture work, compare the [screen capture documentation tools](https://snagitpro.com/screen-capture-documentation-tools/). If you need to choose where approved procedures live, the [process documentation software guide](https://snagitpro.com/process-documentation-software/) covers that separate decision. ## Create an SOP with screenshots FAQ ### What should an SOP with screenshots include? Include a task title, purpose, trigger, scope, audience, owner, prerequisites, numbered actions, expected results, decisions, warnings and exceptions. Record the required execution evidence, approval, version and review rules. Add images only where they help the reader follow the procedure. ### How many screenshots should an SOP have? There is no fixed number. Use enough images for readers to identify the location, action, important state or result. Some steps need none; a difficult step may need a before and after view. Check the count through reader testing rather than a per-step quota. ### Should every SOP step have a screenshot? No. Add a screenshot when visual recognition helps the reader choose a control or confirm a state. Skip decoration and redundant frames. Keep the required action in text even when an image accompanies it. ### What is the best format for a screenshot SOP? Start with searchable text and numbered steps, with each image beside its instruction. Word or Google Docs can suit a simple guide. Choose a managed system when your approval, access or revision requirements need it, and check every format you distribute, including PDF. ### How should I annotate SOP screenshots? Use a clear arrow, outline, number or short callout without hiding the target label. Keep markers consistent and pair color with a meaningful label or shape. Confirm that the annotated copy stays readable at the size readers receive. ### How do I protect private data in SOP screenshots? Use authorized test accounts with synthetic data and check automatic uploads before recording. Inspect source copies, project history, share links and final exports. Do not rely on blur to remove sensitive text or assume editing one image removes copies already shared. ### How often should screenshot SOPs be updated? Set a risk-based review interval with the owner and recheck after relevant software, role or policy changes, incidents and repeated reader errors. Verify the decisions and permissions as well as the screenshots. Retain or archive old versions according to policy. ### Can an automatic capture tool write the complete SOP? A recorder can create a draft from supported captured actions; some tools can also process recordings. That output does not verify hidden prerequisites, policy decisions, exceptions or approval. Have a qualified reviewer check the procedure and test the routes that matter to your readers.