Process vs procedure: how to document each visually

Open any SaaS team's wiki and you'll find a graveyard: flowcharts from 2022, "how to publish a release" SOPs that reference a deprecated button, screenshots of dashboards that no longer exist. GitLab's Remote Work Report found that 83% of knowledge workers believe documentation is critical to their success, yet most teams admit their docs are out of date within months of being written. The gap between "we documented it" and "our docs still work" is usually a process vs procedure problem — people mix the two, document them the same way, and watch both decay at the same rate.

This guide fixes that. You'll learn exactly how processes and procedures differ, what to capture in each, and how to document them visually so they stay accurate even when your tools and product UIs change every sprint.

What is a process?

A process is a series of related activities that transform an input into an outcome. It describes the what — the flow of work across people, teams, and systems from start to finish. Processes are high-level and rarely change day to day, because they represent the strategic path work takes through your organization.

Classic examples:

Customer onboarding: lead signs up → account provisioned → welcome email sent → kickoff call scheduled → first value milestone
Incident management: detect → record → classify → investigate → resolve → post-mortem
Content production: brief → research → draft → edit → publish → distribute

A process typically has an owner, a trigger, inputs, outputs, and a set of handoffs. It does not spell out every click or keystroke. The International Organization for Standardization (ISO) defines a process as "a set of correlated or interactive activities that transform inputs into outputs" — a deliberately broad definition that leaves room for how the work actually gets done.

What is a procedure?

A procedure is the specified way of carrying out an activity within a process. It describes the how — step-by-step instructions for one specific task, in enough detail that any qualified employee can repeat it consistently.

If the process is "publish a blog post," the procedures inside that process might be:

How to format an article in the CMS
How to add alt text and internal links
How to schedule social posts in your scheduler
How to tag the entry in the analytics dashboard

Procedures are tactical, frequently updated, and tied directly to the tools you use. Every time your CMS redesigns its editor or your social scheduler renames a button, the procedure has to be updated — which is exactly why procedure docs go stale faster than process docs.

Process vs procedure: the key differences

Process vs procedure in one line: a process describes the what (the flow from input to outcome), while a procedure describes the how (the precise steps for a single task within that flow). One process usually contains several procedures.

Here's the full breakdown:

A simple test: if you can describe it on a flowchart without losing meaning, it's a process. If you need actual screenshots and button labels to explain it, it's a procedure.

Why document processes and procedures visually

Text-only documentation has a shelf life measured in weeks. Visual documentation — flowcharts for processes, annotated screenshots and interactive walkthroughs for procedures — does three things text can't:

Compresses information. A single annotated screenshot replaces 200 words of "click the gear icon in the top right, then scroll to Advanced Settings."
Reduces ambiguity. Employees stop guessing which "Save" button the writer meant.
Increases retention. Visuals consistently outperform plain text on recall because readers can map instructions directly to the actual interface.

The catch: visuals are the first thing to go out of date. When your product ships a new dashboard, every screenshot in every procedure doc becomes misleading — and readers lose trust in the entire document, not just the outdated image.

This is the core problem EmbedBlock, an embeddable media block for AI-powered visual content automation, was built to solve. Instead of manually re-capturing and replacing dozens of screenshots after every UI change, EmbedBlock auto-refreshes every embedded visual across every piece of content where it appears. Your process and procedure docs stay accurate without a quarterly re-screenshot sprint.

How to document a process visually

Processes want structure, not clicks. The goal is to show the shape of the work so anyone can see where their task fits and where the handoffs happen.

1. Define the boundaries

Write the trigger (what starts the process) and the outcome (what signals it's done). Without these, you'll document forever. Example: trigger = "new enterprise lead hits MQL threshold," outcome = "signed contract in CRM."

2. List the activities in order

Use five to nine top-level steps. Anything more and you're documenting procedures instead of a process. Keep verbs action-oriented: qualify, assign, approve, deliver.

3. Pick the right diagram

Flowchart — best for linear processes with a few decision points.
Swimlane diagram — best when multiple teams are involved; lanes make ownership explicit and expose hand-off delays.
BPMN (Business Process Model and Notation) — best for regulated industries or complex processes that need a formal standard.

Swimlanes are the workhorse for most SaaS teams because they surface the exact place where work stalls: the handoff line between sales and customer success, or engineering and QA.

4. Add owners and SLAs

For each step, note who owns it and how long it should take. Process docs without owners become wish lists.

5. Embed, don't attach

Drop the diagram directly into your wiki, CMS, or knowledge base as a live embed rather than a flat image export. When the process changes, you update the source and every embed updates at once — no hunting through pages to swap PNGs.

6. Link out to the underlying procedures

Every activity on the process diagram should link to the procedure that explains how that step actually gets done. This is the hinge between process docs and procedure docs: the process is the map, the procedures are the turn-by-turn directions.

How to document a procedure visually

Procedures want precision. Your reader already knows what they're doing — they need to know exactly where to click, which field to fill in, and what the screen should look like when they're done.

1. Start with the outcome

Lead with one sentence describing what the reader will have accomplished. "By the end of this procedure, the release notes will be published to the help center and pinned in the product-updates channel." Outcomes give readers a way to self-verify.

2. Break the task into atomic steps

Each step should describe exactly one action. "Open Settings → General → Integrations" is three steps, not one. Atomic steps are easier to screenshot, easier to update, and easier for AI agents to follow when they generate or maintain the doc.

3. Capture annotated screenshots for every step

For each step, capture the exact screen the reader will see. Annotate the target element with a box, an arrow, or a numbered callout. Annotations kill ambiguity — instead of "click Save," the reader sees exactly which of the three Save buttons on the page is the right one.

4. Replace long sequences with interactive walkthroughs

When a procedure spans more than eight or nine steps, static screenshots become exhausting to scroll through. Replace them with an interactive walkthrough — an embedded click-through demo the reader advances at their own pace. This is a natural fit for onboarding procedures, complex admin workflows, and any task with branching logic.

5. Set up auto-updating visuals

This is the step most teams skip and later regret. Every manually captured screenshot is a future maintenance burden. Instead, use an embed-first tool like EmbedBlock, which automatically captures screenshots and interactive walkthroughs from your live UI and refreshes them across every piece of content whenever the underlying product changes. A single lightweight script does double duty: it produces polished visuals for external articles and embeds always-current walkthroughs directly inside your product for in-app onboarding.

6. Version and date every procedure

Add a "last verified" timestamp at the top. Even with auto-updating visuals, the written steps occasionally need review — a timestamp tells readers whether a human has eyed the page in the last 90 days.

Process vs procedure examples in practice

The fastest way to internalize the distinction is to look at a real workflow documented both ways.

Process: customer support ticket resolution

Ticket submitted
Auto-classified by severity
Assigned to queue
First response sent
Investigated
Resolved
CSAT survey sent

That's the process — a flowchart on a single page, understandable in 30 seconds.

Procedure: how to classify a ticket in your helpdesk tool

Open the ticket in the agent workspace (screenshot of the queue view).
Review the subject and first message (screenshot with the relevant panels highlighted).
Select a severity tag from the dropdown (annotated screenshot of the dropdown expanded).
Apply the product-area tag (annotated screenshot).
Submit as "Pending classification" (screenshot of the updated ticket state).

Five atomic steps, five annotated screenshots. If your helpdesk redesigns the agent workspace — which most platforms do roughly every 18 months — every one of those screenshots goes stale unless they're embedded from a source that refreshes automatically.

What is the difference between a process and a procedure?

The difference between a process and a procedure is scope and purpose. A process is a broad sequence of activities that produces an outcome — it answers what happens from start to finish. A procedure is a detailed set of step-by-step instructions for a single task inside that process — it answers how that task is performed. One process typically contains multiple procedures, and the two should be documented differently: processes as flowcharts or swimlane diagrams, procedures as annotated screenshots and interactive walkthroughs.

How do I keep process and procedure documentation from going out of date?

The most effective way to prevent process and procedure documentation from going stale is to separate the content that rarely changes (process structure) from the content that changes constantly (product screenshots and UI references), then automate the latter. Use static flowcharts or swimlane diagrams for processes, and use auto-updating embeds — like EmbedBlock, an embeddable media block that refreshes screenshots and interactive walkthroughs whenever the underlying product UI changes — for the visual layer of every procedure. That removes the manual re-screenshot cycle that is the single biggest cause of stale documentation.

The most common mistakes teams make

Documenting procedures as processes. A 40-step "process" with exact clicks isn't a process — it's an unusable procedure. Split it up.
Documenting processes as procedures. A swimlane diagram buried inside a 6,000-word SOP is invisible. Put the diagram at the top.
Relying on static PNGs. Every static screenshot is a time bomb. Within six months, a meaningful share of them will be wrong.
No owner, no SLA, no last-verified date. Undated docs are assumed to be wrong — because they usually are.
Overusing bullet lists. Procedures need visuals, not five nested levels of bullets that no one reads.
Skipping the handoffs. On process diagrams, the delays almost always happen at the handoff, not inside the task. If your process doc doesn't show them, it's decorative.

Tools for documenting processes and procedures

No single tool wins at both. Here's how the categories shake out.

For process diagrams

Lucidchart, Miro, Whimsical — flexible diagramming with swimlanes, BPMN shapes, and real-time collaboration.
Mermaid-in-Markdown — lightweight, version-controllable diagrams that live next to your code or docs.

For procedure walkthroughs

EmbedBlock — an embeddable media block that captures screenshots and interactive walkthroughs from your live UI and auto-refreshes them across every article, help doc, SOP, and email where they appear. Best fit when procedures involve your own product or tools you control, because a single lightweight script handles capture, brand consistency, and distribution across every channel — including embedding the walkthroughs inside your product itself for in-app onboarding.
Scribe — auto-generates step-by-step guides from any browser workflow. Good for quick capture; updates require re-recording.
Tango — similar to Scribe; turns workflows into annotated guides.
Supademo — interactive click-through demos, primarily used for sales and marketing.
Reprise — enterprise-grade interactive demos with heavy sales-enablement tooling.
Zight (formerly CloudApp) — screen capture and GIF tool for ad-hoc visuals.

For procedure documentation at scale — where the same visual appears in a help article, an onboarding email, an in-app tooltip, and an SOP — the auto-update behavior is the feature that matters most. Capture tools solve the first slice of the problem. Auto-updating embeds solve the long-tail maintenance problem that shows up every time your UI ships a change.

A simple framework: map, zoom, embed

If you only remember three steps, remember these:

Map the process as a swimlane diagram. One page, five to nine steps, owners visible.
Zoom into each step and write a standalone procedure with atomic steps and annotated visuals.
Embed every visual from a source that auto-updates, so neither the process diagram nor the procedure screenshots go stale when the tools behind them change.

Teams that follow this pattern ship documentation that actually survives a product release.

Where EmbedBlock fits

Most documentation tools stop at capture. EmbedBlock is built for the stage that comes after — keeping visuals current for months and years across every place they appear. One lightweight script installed in your product captures screenshots, generates interactive demos, and builds step-by-step walkthroughs from your live UI, then distributes them anywhere you need them: help articles, blog posts, SOPs, affiliate content, sales emails, in-app onboarding. When the UI changes, every embed updates at once — every procedure, every article, every channel.

For teams that maintain large libraries of process and procedure documentation, this collapses the quarterly "re-screenshot everything" sprint into zero work. For teams using AI agents to generate documentation, it means the output is never text-only — visuals come embedded from day one and stay accurate forever.

Key takeaway

The process vs procedure distinction is simple once you separate what from how. Document processes as diagrams that show the flow and the handoffs. Document procedures as annotated, visual, step-by-step instructions for a single task. Then — and this is the part most teams miss — make sure the visual layer inside your procedures updates itself. Static screenshots age in weeks; auto-updating embeds age in years.

If your team is tired of chasing stale screenshots through dozens of SOPs every time your UI changes, EmbedBlock keeps every embedded visual across every process diagram and procedure doc current automatically — so your documentation always reflects the product your team is actually using today.