How to create an SOP with screenshots
Reviewed .
A standard operating procedure should help someone complete a task correctly when its usual owner is unavailable. Screenshots help readers identify the right screen or control, but a stack of images is not an SOP. The document also needs a starting point, the reason for each decision, and a way to recognize success.
You can create an SOP with screenshots using tools you already have. Begin with one repeatable task rather than trying to document an entire role. A procedure such as creating a draft invoice is easier to review than a broad document called "Finance operations." Keep approval and publishing steps explicit.
Build the first version manually
- Define the procedure's audience, starting state, prerequisites and expected result.
- Perform the task with sample data and capture screenshots at meaningful decision points.
- Write numbered instructions beside the images, including expected results and stop conditions.
- Remove private information and check every screenshot against its instruction.
- Ask a colleague to follow the draft, correct any gaps and save a dated master.
Use a screenshot tool and a document editor. Keep the original captures together until review is finished, with simple filenames such as step-01 and step-02. Add images in execution order. If the procedure contains desktop applications as well as browser pages, the manual method can cover both in one document.
Already have the screenshots? The free screenshot guide maker puts them in order with a line of text each and downloads a numbered Word document or PDF, in your browser.
Define what the SOP covers
Give the SOP a title that names an action and outcome: "Create a draft invoice for review." State who can use it, which application it applies to, and what permissions are required. Explain what is outside its scope, such as approving the invoice or sending it to a customer.
List the information a reader must obtain before starting. For the invoice example, that might be an approved customer record and an agreed amount. Do not embed live customer data or access credentials merely to make the instructions concrete. Use clearly labeled examples and explain where legitimate values come from.
Record the expected final state in observable terms. "The invoice is correct" is vague. "A draft appears in the invoice list with the intended customer and amount, and has not been sent" gives the reader something to check. The outcome should match the permissions and scope you described.
Choose screenshots that answer a question
Capture the screen that lets a reader find the next action. A menu before selection is useful when its option disappears after clicking. A separate image of the result is useful when the reader must confirm a save or status change. Do not use the pre-click image as proof that the action succeeded.
Keep enough context to identify the application area. A tight crop of an unlabeled icon can be confusing; a full desktop with unrelated windows can be distracting. If you annotate an image, ensure the marker points to the intended control and does not cover its label.
For form entry, the written instruction must explain what to enter. A screenshot of an empty field does not supply a business rule. Say where the value comes from, whether a particular format is required, and what to do if the expected choice is missing. Avoid using only visual directions such as "the blue button."
Write actions, checks and exceptions
Start each numbered instruction with a verb: open, select, enter, save, or check. Name the control as it appears on screen. Replace "Click here" with "Select New invoice in the invoice list." Put any warning before the action it affects, especially for deleting, sending or changing access.
Keep one main action per step unless two small actions are inseparable. Explain the result underneath: "The draft form opens." A step can also include a condition: "If the customer is missing, stop and request a customer record; do not create a duplicate." This is more useful than adding every possible error screenshot.
Separate different routes when they require different decisions. A new customer procedure and an existing customer procedure may deserve linked documents. Do not force both into a long sequence where half the steps apply only sometimes. Keep the main path readable and make exceptions easy to find.
A small SOP outline you can copy
- Purpose: create a draft invoice ready for review, without sending it.
- Audience and access: staff with permission to create drafts in the invoice application.
- Before starting: obtain the correct customer record and approved invoice details.
- Procedure: open invoices, start a draft, select the customer, enter details, and save.
- Verification: compare the saved draft with the approved details and check its status.
- Exceptions: stop for missing records, unexpected permissions or inconsistent totals.
- Maintenance: identify the responsible role, review date and location of the master.
This outline is an example, not a rule for your organization. Replace it with the actual controls and approval requirements of the application. A screenshot recorder cannot decide whether an amount is authorized or a task is ready for release.
Use a recorder for repeated browser procedures
Ownsteps is a Chrome extension that records clicks and turns them into editable steps with screenshots. When available, start recording on the intended website, perform the task with sample data, and stop recording. Open the guide editor to turn the captured sequence into the procedure you intend to teach.
Edit the titles and notes, delete exploratory clicks, and reorder steps where appropriate. Replace any image that does not show the right screen. Add the prerequisites, business rules and outcome checks yourself. The recorder captures actions; your review supplies the meaning and confirms that the sequence is safe to follow.
Ownsteps does not save typed values as step metadata and blacks out input fields in captures. That helps with privacy, but it means your instructions must explain required values. Page content outside fields can still contain names, account details or internal information. Inspect and redact the images before exporting.
Test and maintain the finished SOP
Ask someone who did not write the document to perform the task in an appropriate test environment. Observe where they hesitate and what they infer without written guidance. If they need a verbal explanation, add that information at the point where it is needed instead of expanding the introduction.
Keep a dated master and make its location clear. Review affected steps when a label, permission or business rule changes. Exported copies need replacement when the master changes; a document on someone's computer will not update itself. For delivery details, see how to make an editable Word guide. For a new colleague's first task, see process documentation for new hires.