This swimlane diagram template follows a fictional exhibit-caption process across Author, Editor, and Layout roles. Name the packet crossing each lane and the receiving step, including the return path. The worked example compares an incomplete correction loop with a usable one.
Set a start and an end before drawing the lanes
The original process starts when the author sends a caption draft with a source reference. It ends when a matching layout proof is ready for a separate publication review.
The three lanes show who performs each step:
| Step | Role | Action and next step |
|---|---|---|
| A1 | Author | Send caption draft and source reference to E1. |
| E1 | Editor | Check that the exact source reference is present. If missing, request it from A2; if present, continue to E2. |
| A2 | Author | Receive the reference request, add the reference, and resend to E1. |
| E2 | Editor | Review wording. Send a wording-change request to A3, or pass accepted wording to L1. |
| A3 | Author | Receive the wording request, revise, and return the draft to E2. |
| L1 | Layout | Prepare or correct the proof and send it to E3. |
| E3 | Editor | Compare the proof with the accepted wording. Return a mismatch to L1; a matching proof reaches the stated end. |
The source-reference loop returns to E1 because that is the check still needed. The wording loop returns to E2. Keeping those return points distinct makes the route easier to follow.
The AHRQ swim-lane flowchart guidance describes arranging process steps by responsible participant and showing cross-role actions from both sender and receiver viewpoints. It also recommends checking the map with people involved in the work. The caption process here is an original nonclinical example.
Repair the missing receiving step
Choose Compare return loop in the example. The incomplete map says that the editor sends a correction request, then resumes with editor review. The author has no receiving or revision step in between.
The corrected map adds A2 and names the handoffs:
| From | Packet crossing the lane | To |
|---|---|---|
| E1 | Request for the exact source reference. | A2 receives and completes the reference. |
| A2 | Revised caption plus source reference. | E1 checks the returned packet. |
Both maps have the same start and end. The corrected version exposes the work the step list skipped; it does not claim that the process has become faster.
Follow both outcomes of the first check
Select Reference missing to highlight A1 → E1 → A2 → E1. Read the reference request and returned packet beside the route.
Select Reference present to continue from E1 to E2. That branch reaches wording review, not the final publication step. A caption with a source reference can still need a wording revision.
Inspect the proof handoff in the same way. E3 compares the proof with the accepted draft. A mismatch goes back to Layout at L1; it should not appear to end simply because someone produced a proof.
Make the handoff readable outside the diagram
For each lane crossing, record sender, packet, receiver, and next step. A small-screen version can show those labeled records in sequence rather than shrinking the full map until its text is unreadable.
The example's mobile view keeps the same step IDs and routes. You can inspect the reference and wording loops without relying on arrow color alone.
Before adopting your own map, ask each role to trace a normal case and a returned case. If someone cannot identify what they receive or what they send back, revise that handoff while everyone can examine it.
Prepare a map for your own process
Create one complete, self-contained HTML swimlane process map.
Process start and end: [PASTE]
Roles or teams: [LIST]
Steps with stable IDs, responsible role, and action: [PASTE]
Decisions and their branch conditions: [PASTE]
For every handoff: sender, packet/information, receiver, next step: [PASTE]
Correction and return loops: [PASTE]
Unresolved role or process questions: [PASTE]
Draw steps in their actual responsible lanes and connect the sequence.
For a cross-role action, show both sending and receiving work. Give
every return branch a receiving/revision step and an explicit recheck.
Keep the same start and end when comparing incomplete/corrected maps.
Let readers select a decision path and inspect each named handoff.
Use text labels as well as highlighting. At 360px, provide equivalent
readable role/step/handoff records instead of a tiny unreadable diagram.
Do not imply a route performs work, approves content, or publishes it.
Include temporary mapping notes and missing role/receiver/return-step
feedback. Preserve notes across path changes and ask before resetting.
Keep input local, with no workflow execution or claimed saved records.
Use text of at least 16px and labeled keyboard-accessible controls.
Put CSS and JavaScript inline with no external dependencies. Return
the complete HTML with no horizontal page scrolling at 360px.
Walk the return path with the receiving person
Ask the author whether “add the reference” identifies the information the editor actually needs. Then ask the editor whether the returned packet reaches the right check.
An HTML map in NOS lets you correct the visible handoff wording during that conversation. Replacing “fix caption” with “supply the exact source reference, then return to E1” gives the receiving person a specific task and destination. Use the agreed wording in the team's maintained process map.