Swimlane Diagram: Definition, Step-by-Step Guide & Practical Example

A swimlane diagram (also called a cross-functional flowchart, Rummler-Brache diagram, or deployment flowchart) is a process visualization technique that arranges work steps in horizontal or vertical lanes. Each lane represents a department, role, or system. The result: you see not only which steps a process involves, but also who is responsible for each step — and where handoffs between participants occur.

The method traces back to Geary Rummler and Alan Brache, who introduced it in their seminal work Improving Performance: How to Manage the White Space on the Organization Chart (1990) [1]. Their central insight: most process failures occur not within a department, but at the handoff points between departments — in the so-called “white space” of the organization chart. Rummler estimated that up to 80% of all process problems can be traced back to these interfaces [1]. The swimlane diagram makes precisely these interfaces visible.

Search for “swimlane diagram” online, and you will find primarily tool tutorials (Lucidchart, Creately, draw.io) with generic workflow examples. None explains Rummler’s “white space” insight, which provides the actual value proposition of the method. None systematically compares swimlane diagrams with service blueprints or BPMN. And none shows a concrete practical example from the service sector — such as a claims process spanning four departments.

This guide fills those gaps.

Definition and Origin

What Is a Swimlane Diagram?

A swimlane diagram is an enhanced flowchart that arranges process steps in parallel lanes. The lanes can run horizontally or vertically — the choice is purely conventional, though horizontal lanes are more common in European practice.

The core idea: A standard flowchart shows you the sequence of process steps — but not who performs them. If you want to understand why a process stalls, sequence alone is not enough. You need to see where responsibility passes from one person to the next. That is exactly what the swimlane diagram delivers.

Rummler and Brache: The White Space

Geary Rummler was an organizational consultant and performance expert who spent his entire career on one question: Why do organizations deliver worse results than the sum of their parts would suggest? His answer, formulated together with Alan Brache in Improving Performance (1990): Because nobody manages the “white space” between the boxes on the organization chart [1].

Organization charts show departments as boxes and hierarchies as lines. But actual value creation flows horizontally — across the boxes, from department to department. A customer order passes through sales, order entry, production, logistics, and billing. At each transition — each “white space” — information can be lost, priorities can shift, and responsibilities can become unclear.

Rummler and Brache developed the swimlane diagram as a tool to make these horizontal processes visible. Their insight: If you want to improve a process, optimize the handoffs first — not the individual steps. A perfectly executed step in claims processing is worthless if the handoff to quality review takes three days because nobody has defined how, when, and in what format information is passed along.

Evolution and Standards

The concept has been integrated into several formal notations:

• BPMN 2.0 (Business Process Model and Notation, OMG 2011): Uses pools and lanes as core elements for representing responsibilities [2].
• UML Activity Diagrams: Use activity partitions as a swimlane equivalent [3].
• Sharp & McDermott (2009): Formalized the notation in Workflow Modeling with clear rules for symbology and handoff representation [4].

Today the swimlane diagram is the most widely used form of cross-functional process visualization — supported by virtually every diagramming tool (Visio, Lucidchart, Miro, draw.io) and anchored in ISO and BPMN standards.

The 6 Core Elements

A swimlane diagram consists of six core elements. Once you understand these, you can map any process.

Element	Symbol	Function
Lane	Horizontal or vertical stripe	Represents a department, role, or system
Pool	Frame around multiple lanes	Groups lanes into an organization or process area
Activity	Rounded rectangle	A single process step
Decision	Diamond	Branch point with yes/no or multiple options
Handoff	Arrow crossing a lane boundary	Information or responsibility transfer between participants
Start/End	Circle (start) / Double circle (end)	Marks process beginning and conclusion

The most important insight: The most valuable element is the handoff — the arrow that crosses a lane boundary. Every such arrow is a potential failure point. Rummler’s rule of thumb: Count the lane boundary crossings in your diagram — the number correlates with the process’s error-proneness [1].

When to Use a Swimlane Diagram — and When Not

Ideal Use Cases

Use a swimlane diagram when:

• You want to visualize a cross-functional process — involving 2 to 8 roles or departments
• You want to diagnose handoff problems — delays, information loss, unclear responsibilities
• You are conducting an as-is analysis before redesigning a process
• You want to document a to-be process that needs to be understandable for all stakeholders — swimlane diagrams are readable by non-technical audiences
• You are creating onboarding materials for new employees who need to understand how a process flows through multiple departments
• You need to document compliance requirements — who is responsible for which step?

When Another Tool Is a Better Fit

Situation	Better Alternative	Why
You want to map the customer perspective (touchpoints, emotions, pain points)	Customer Journey Map	Swimlane diagrams are process-centric, not customer-centric
You want to distinguish frontstage and backstage of a service	Service Blueprint	Service blueprints have a “line of visibility” that swimlanes lack
You need a machine-readable process definition for workflow engines	BPMN 2.0	BPMN has formal semantics that software can interpret
You want to identify waste and cycle times in a manufacturing process	Value Stream Analysis	Value stream maps quantify times and inventory per step
Your process has more than 8 lanes	Process hierarchy (sub-processes)	Beyond 8 lanes, the diagram becomes unreadable — split the process
You want to analyze process data, not visualize it	Process Mining	Process mining reconstructs actual process flows from log data

Step by Step: Creating a Swimlane Diagram

Step 1: Define the Process Scope

Before you draw, clarify three questions:

1. Where does the process begin? (Triggering event, e.g., “Customer submits claim”)
2. Where does the process end? (Closing event, e.g., “Payment issued or rejection delivered”)
3. What level? (End-to-end process or sub-process?)

Tip: Formulate the process scope as a “from X to Y” sentence. If the sentence exceeds one line, the scope is probably too broad.

Step 2: Identify Participants

List all roles, departments, or systems involved in the process. Each participant gets its own lane.

Three rules for good lane definitions:

1. Role, not person: “Claims handler,” not “Ms. Smith”
2. Consistent granularity: Either all lanes at department level (Sales, Claims, Finance) or all at role level — don’t mix
3. Maximum 6-8 lanes: More becomes unreadable. If you have 12 participants, group related roles

Step 3: Collect Process Steps

Use one of the following techniques:

• Process walk (Gemba Walk): Physically follow the process and document every step
• Stakeholder interviews: Ask representatives from each lane what they do, from whom they receive input, and to whom they pass output
• Workshop: Bring all participants together and collect steps on sticky notes — one colour per lane

Tip: Formulate each step as verb + object: “Review claim,” “Commission surveyor,” “Approve payment.” Avoid nominalizations like “Review of the claim” — they obscure who acts.

Step 4: Assign Steps to Lanes

Place each step in the responsible lane. The timeline runs from left to right (for horizontal lanes) or from top to bottom (for vertical lanes).

Critical question for each step: “Who performs this step — and is that the same person who should be responsible for it?” If execution and accountability diverge, you have identified a potential weak point.

Step 5: Draw Handoffs and Decisions

Connect the steps with arrows. Pay particular attention to:

• Lane boundary crossings: Every arrow that crosses a lane boundary is a handoff. Label it: What is being handed off? In what format? Within what timeframe?
• Decision diamonds: Every branch needs a clear condition. Not: “Review OK?” Rather: “Claim amount > €5,000?”
• Parallel paths: If two steps can occur simultaneously, draw them side by side, not sequentially

Step 6: Validate

Walk through the finished diagram with representatives from each lane. Ask three questions:

1. “Is there a step you regularly perform that is missing?”
2. “Are there steps that work differently in practice than shown here?”
3. “Where do you most frequently wait for input from another department?”

The third question identifies the critical handoffs — the points where the process most often stalls in reality.

Step 7: Mark Weak Points

In the finished diagram, highlight:

• Red handoffs: Handoffs with known problems (delays, information loss, callbacks)
• Redundant steps: Activities duplicated across multiple lanes
• Decisions without clear criteria: Diamonds where the condition is ambiguous

These markings are the direct input for process improvement.

Practical Example: Motor Insurance Claims Processing

A mid-sized motor insurer discovers that the average processing time for claims is 14 days — the industry average is 8. The process manager creates a swimlane diagram with four lanes.

The Four Lanes

Lane	Role	Responsibility
1	Customer	Reports claim, submits documents, receives outcome
2	Intake Processing	Receives notification, checks completeness, assigns
3	Claims Processing	Assesses damage, commissions surveyor, decides
4	Finance	Approves payment, initiates transfer

The As-Is Process (Simplified)

1. Customer → submits claim online
2. Intake → checks completeness (result: 34% of claims incomplete → query back to customer)
3. Handoff to Claims → via email with attached PDF
4. Claims → assesses claim amount
5. Claims → Decision: surveyor needed? (if > €3,000: yes)
6. Claims → commissions external surveyor (wait time: avg. 5 days)
7. Handoff to Finance → via internal ticketing system
8. Finance → checks budget coverage, approves
9. Handoff to Customer → notification by post

What the Diagram Reveals

The swimlane diagram makes three problems visible that were hidden in the previous process description (a text-only manual):

1. Media break at Handoff 3: The handoff from Intake to Claims happens via email with a PDF. There is no defined format, no checklist, no automatic assignment. Consequence: claims handlers must manually create the case file — an avoidable step costing an average of 45 minutes per case.

2. Information loop for incomplete claims: 34% of claims go back to the customer as incomplete. The diagram shows this loop adds 3-5 days — because the customer does not respond immediately and Intake “parks” the case in the meantime.

3. Surveyor wait time: The 5-day waiting block appears as empty space in the “Claims” lane — a visual signal that remains invisible in a text description.

The To-Be Process

After the analysis, the insurer implements three measures:

• Online form with mandatory fields → incompleteness rate drops from 34% to 8%
• Automatic case handoff via core system instead of email → handoff time from 45 min to 0
• Surveyor network with SLA → wait time from 5 to 2 days

Result: average processing time drops from 14 to 7 days.

5 Common Mistakes

Mistake 1: Too Many Lanes

Beyond 8 lanes, a swimlane diagram becomes unreadable. If your process involves 12 participants, that is not a sign of a complex diagram — it is a sign that you should split the process into sub-processes. Sharp and McDermott recommend a maximum of 5-7 lanes per diagram [4].

Mistake 2: Unlabeled Handoffs

An arrow crossing a lane boundary without a label is worthless. It shows that a handoff occurs, but not what is being handed off, in what format, or within what timeframe. Unlabeled handoffs are the most common reason swimlane diagrams end up in a drawer.

Mistake 3: Mixing As-Is and To-Be

Always create the as-is process first, then the to-be process — in separate diagrams. Teams that draw both simultaneously produce an idealized process that bears little resemblance to reality. The discrepancy between as-is and to-be is the actual analytical value.

Mistake 4: Inconsistent Granularity

If Lane 1 contains a single step (“Submit application”) and Lane 2 has ten steps, the granularity is off. Every lane should have a comparable level of detail. Rule of thumb: if a step represents more than one working day, it is too coarse and should be broken into sub-steps.

Mistake 5: No Validation Step

A swimlane diagram created by one person alone and never validated with the process participants is a hypothesis — not process documentation. The validation round (Step 6 in the guide) is not an optional add-on; it is the step that transforms the diagram from an assumption into a shared reality.

Comparison with Related Methods

Criterion	Swimlane Diagram	Service Blueprint	BPMN 2.0	Value Stream Analysis
Perspective	Process (cross-functional)	Service (customer + provider)	Process (formal)	Value flow (Lean)
Lanes	Departments/roles	Frontstage, backstage, support	Pools + lanes	None (linear flow)
Line of visibility	No	Yes (core concept)	No	No
Time data	Optional	Optional	Optional	Core component (takt, cycle time)
Machine-readable	No	No	Yes (XML-based)	No
Target audience	Process managers, business analysts	Service designers, UX teams	IT, process automation	Lean/operations teams
Learning curve	Low (30 min)	Medium (1-2 hrs)	High (days)	Medium (half day)
Strength	Making handoffs visible	Connecting customer experience + internal processes	Automatable, standardized	Quantifying waste
Weakness	No customer perspective, no time data	Not for IT automation	Too complex for non-technical stakeholders	Only for manufacturing/logistics

When to Use Which Tool?

• Swimlane diagram: You want to understand who does what and where handoffs stall — without specialized software, without training, understandable for everyone involved
• Service blueprint: You want to show the connection between customer experience and internal processes — frontstage and backstage
• BPMN: You want to automate the process or model it in a workflow engine
• Value stream analysis: You want to quantify cycle times, inventory, and waste

Our Perspective

The swimlane diagram is not an innovation tool — it is a diagnostic tool. Its value lies not in inventing new processes but in representing existing processes in a way that makes their weaknesses visible. And the weaknesses are almost always in the same places: at the handoffs.

Rummler’s “white space” insight is more relevant today than ever. In a world where organizations increasingly operate in silos — despite all agile frameworks — the ability to make horizontal processes visible remains a core competency.

In our practice, we observe three patterns:

1. Teams underestimate the number of handoffs. When we ask process participants how many handoffs their core process involves, they typically estimate 3-4. The swimlane diagram regularly reveals 8-12. The discrepancy between perception and reality is the analytical value of the method.

2. The most valuable insights come from Step 6 (Validation). It is not drawing the diagram that produces insights, but the conversation about the diagram. When claims processing and finance look at the same process together for the first time, assumptions that went unchallenged for years become visible.

3. The biggest danger is optimizing at the wrong level. Teams tend to optimize individual activities within a lane rather than improving the handoffs between lanes. A claims handler who works 20% faster does not compensate for a handoff that takes three days. The swimlane diagram helps direct focus to the right levers.

FAQ

What is a swimlane diagram in simple terms?

A swimlane diagram is a flowchart with parallel lanes. Each lane belongs to a department or role. The lanes show who performs each step and where tasks are handed from one department to the next.

Where does the name “swimlane” come from?

The parallel lanes resemble the lanes in a swimming pool — hence the name “swimlane.” The formal term is “cross-functional flowchart,” and in BPMN notation the equivalent elements are called “pools” and “lanes.”

How many swimlanes should a diagram have at most?

Sharp and McDermott (2009) recommend 5-7 lanes [4]. Beyond 8 lanes, the diagram becomes unwieldy. If you have more participants, split the process into sub-processes.

What is the difference between a swimlane diagram and a service blueprint?

A swimlane diagram shows who performs each process step. A service blueprint additionally divides the process into frontstage (visible to the customer) and backstage (internal) and includes a “line of visibility.” Service blueprints are customer-centric; swimlane diagrams are process-centric.

Which tool is best for swimlane diagrams?

For simple diagrams, sticky notes on a whiteboard suffice. For digital diagrams, Lucidchart, Miro, draw.io (free), Microsoft Visio, or Figma work well. For formal BPMN diagrams with swimlanes: Camunda Modeler or Signavio.

Can I convert a swimlane diagram to BPMN 2.0?

Yes. The BPMN 2.0 notation includes pools and lanes as core elements [2]. A swimlane diagram can be translated into BPMN by defining pools for organizations and lanes for roles. The reverse — BPMN to swimlane — simplifies the diagram for non-technical stakeholders.

Research Methodology

This article synthesizes findings from Rummler and Brache’s foundational work on process improvement (1990), the Object Management Group’s BPMN 2.0 standard (2011), Dumas et al.’s academic textbook on business process management (2018), Sharp and McDermott’s practice-oriented guide (2009), and Madison’s introduction to process mapping (2005). Sources cover theoretical foundations, formal standards, and practical application.

Limitations: The assertion that 80% of process failures occur at cross-departmental handoffs is based on Rummler’s consulting experience, not a controlled study. The worked example (auto insurance claims processing) is illustratively constructed. The effectiveness figures (reduction from 14 to 7 days) are typical magnitudes from process optimization, not documented individual case studies.

Disclosure

SI Labs provides consulting services in the area of service innovation and uses swimlane diagrams as analytical tools in the process analysis phase of the Integrated Service Development Process (iSEP). This practical experience informs the positioning of the method in this article. Readers should be aware of the potential for perspective bias.

Bibliography

1. Rummler, G. A. & Brache, A. P. (1990). Improving Performance: How to Manage the White Space on the Organization Chart. San Francisco: Jossey-Bass. — The foundational work that introduced swimlane diagrams. Essential reading for process managers.
2. Object Management Group (2011). Business Process Model and Notation (BPMN) Version 2.0. OMG Standard. — The formal standard defining swimlanes (pools/lanes) as a BPMN core element.
3. Dumas, M., La Rosa, M., Mendling, J. & Reijers, H. A. (2018). Fundamentals of Business Process Management. 2nd ed. Berlin: Springer. — Academic textbook with comprehensive treatment of process visualization.
4. Sharp, A. & McDermott, P. (2009). Workflow Modeling: Tools for Process Improvement and Application Development. 2nd ed. Boston: Artech House. — Practice-oriented notation and rules for swimlane diagrams.
5. Madison, D. (2005). Process Mapping, Process Improvement, and Process Management. Chico: Paton Professional. — Practical introduction with many diagram examples.