How do you write a standard operating procedure for a process done on a phone?

The parts, and what each one is for

An SOP is a short document with a fixed shape. The shape is not bureaucracy; each part answers a question the reader has before they will act on it.

• Title — the task, named as a task. Refunding an order in the field app, not Refund procedure v2.
• Purpose — one sentence on why this exists. It is what tells a reader they are in the right document.
• Scope — who this applies to and what it covers. Also what it does not: this covers full refunds only; partial refunds are a separate procedure.
• Prerequisites — access, permissions, app version, anything the reader needs before step one. A procedure that fails at step four because of a missing permission has wasted the reader’s time and their trust.
• Steps — numbered, imperative, one action each.
• Owner, version, review date — in the footer of every page. This is the part that decides whether the document is still believed in a year.

What changes on a phone

Screenshots stop being optional. On a desktop, a reader has a window title, a menu bar and a sidebar to orient by, and one screenshot can often cover several clicks because the controls are all visible at once. A phone shows one screen at a time with no persistent landmarks, and each tap replaces the whole view. A step without a screenshot is a step the reader has to guess at.

The tap target needs marking. “Tap the button in the top right” makes the reader scan and decode. A marker on the screenshot does not.

Screens are taller and narrower, which means a screenshot at full width on a Letter page is enormous and one at readable size wastes most of the width. Either the layout earns that space, or the guide reads as an accident.

Sensitive data is everywhere. Phone apps are personal. Real screens carry names, balances, addresses and account numbers, and a mobile SOP made from real screens will leak them unless every screenshot is checked. This is the failure that actually happens — not a wrong caption, a shared PDF with a customer’s details in step seven.

Writing the steps

• Imperative mood. “Tap Refund.” Not “The user taps Refund”, and not “The Refund screen will appear” — the reader needs an instruction, not a narration.
• One action per step. A step containing “and then” is two steps.
• Name controls exactly as the screen labels them, with the same capitalisation. If the reader has to translate your wording into what they see, the step has failed.
• State what confirms success where the outcome isn’t obvious. “The status changes to Refunded” tells a reader they are on track.
• Put warnings before the step, not after. A caution below the instruction is read after the irreversible thing has been done.

Producing one without the screenshot marathon

The reason mobile procedures go undocumented is not that anyone disputes their value. It is that capturing twenty screenshots by hand, transferring them, cropping them, importing them, captioning them and redacting them takes most of an hour, and it all has to be redone when the app updates.

Walkthru removes the capture and assembly half. Record the flow once, on the phone; it cuts the recording where the screen changed and gives you a step per cut with a full-resolution screenshot already in place. You write the captions — the part that needed a human anyway — place markers, accept the redactions it offers for anything sensitive it spots, and export.

For an SOP folder, the PDF export is the deliverable: three layouts including a checklist, US Letter or A4, with an optional cover page and outline bookmarks. For a procedure that lives beside the code or on a docs site, the Markdown bundle exports step text with relative image references, so the diff shows exactly which steps changed when you re-record after a UI update.