What Is a Swimlane Diagram? Putting Cross-Department Work on a Single Page

You draw a business process and someone asks, "so who actually does this?" Listing steps in order does not convey ownership. A swimlane diagram solves that. This article covers lane design — how to split them and how to order them — which is the judgment specific to this kind of diagram.

What a Swimlane Diagram Is

A flow diagram divided into bands by owner, with each step placed inside the relevant band. The name comes from the resemblance to lanes in a swimming pool.

The difference from an ordinary flow diagram is that position carries meaning. Which band a step sits in determines whose work it is. You no longer need to write the owner's name inside the shape.

What becomes visible

The greatest advantage is that arrows crossing lanes stand out. Each of those arrows is a handoff.

Work stalls at handoffs more than anywhere else. A request was sent but the recipient did not notice; things are waiting on a review; something came back for a missing detail. Splitting into lanes lets you locate where these occur on the diagram.

Conversely, if no arrows cross lanes, you did not need swimlanes in the first place. Work that one person completes alone is fine as an ordinary flow diagram.

What to Split the Lanes By

The first and most important judgment. How you split determines what the diagram reveals.

Splitting by department

Sales, production, finance. This suits work with a lot of interdepartmental coordination, and it reveals where the load concentrates organisationally.

The caveat is that role divisions within a department stay invisible. Five steps sitting in the sales lane tell you nothing about whether one person does them all, or whether they split between an account owner and a manager.

Splitting by role

Requester, approver, executor, acceptor. This suits work where authority divides within a single department, such as an approval flow.

Splitting by role also insulates the diagram from staff moves and reorganisations. Draw it with department names and you will be redrawing it every time the org chart changes.

Which to choose

Decide by what the diagram is for. To review interdepartmental coordination, split by department. To hand over a procedure, split by role.

When in doubt, use role. Handover and explaining things to new joiners are the most common uses, and what those need is "which position does what."

The Order of the Lanes

Easy to overlook, but it has a large effect on readability.

The default is to order lanes the way the work flows. Requester, manager, finance — the sequence in which documents and data get passed along.

This aligns the crossing arrows in one direction and reduces intersections. Put a department with many touchpoints at one end, and its arrows will keep traversing the whole diagram until it becomes unreadable.

When work goes back and forth

For work that shuttles repeatedly between the same two parties, arrows will cross however you order things. In that case, place the two lanes adjacent to each other.

If the arrows still get complicated, the number of round trips is itself the problem. That is a candidate for changing how the work runs, not how the diagram is drawn.

Horizontal or Vertical

Lanes can run as horizontal bands with the flow moving left to right, or as vertical columns with the flow moving top to bottom.

The guide is simple.

• Few lanes, many steps: horizontal (lanes as bands, flow left to right).
• Many lanes, few steps: vertical (lanes as columns, flow top to bottom).

Pages and slides are wider than they are tall, so horizontal usually fits better. Past six lanes, though, the vertical dimension gets tight in a horizontal layout.

Whether to Include External Parties

Whether to give customers, clients, and vendors their own lanes. Opinions divide here too.

Include them. Leave external parties out and the waiting time disappears from the diagram.

The period spent waiting on a client's review is not your own work, so it drops out easily. Yet it is common for the bulk of the lead time to be exactly that waiting.

Whether to give systems a lane

You can also give core systems or automated processing a lane of their own. The boundary between human work and automation becomes explicit, which helps when considering where automation could extend.

It does add a lane, so it depends on the purpose. For a handover document, folding the system into the human lanes is perfectly acceptable.

When Lanes Multiply

Past eight lanes, the diagram stops working. There are three remedies.

• Raise the granularity: consolidate individuals into teams, departments into divisions.
• Split the diagram by phase: up to winning the order, and from delivery onward.
• Merge rarely-appearing lanes: parties that show up once go into an "other" lane.

The second is the most reliable. Do not make fitting everything on one page the objective. Two readable diagrams beat one unreadable one.

Handling the Arrows That Cross Lanes

The most information-rich part of the diagram. Drawing a bare arrow wastes it — write what is being passed.

Specific names such as "quotation," "approved request form," or "revision request" make the substance of the handoff clear. Adding whether it goes by email or through a system makes it more useful still.

What to look at once it is mapped

When the diagram is finished, count the arrows crossing lanes. That number is how many handoffs the process contains.

Every handoff creates a wait and a risk of information being lost. If the count is high, it is worth asking whether some can be combined. Three handoffs to the same party raises the question of whether one would do.

Frequently Asked Questions

How does it differ from an ordinary flow diagram in use?

Split on whether several parties are involved. For work completed by one person or one department, lanes add no information. With three or more parties, you cannot track ownership without them.

What if several people share one step?

Put it in the primary owner's lane. If it genuinely cannot be assigned, consider whether the step itself can be broken down. Work described as "we do it together" often turns out to be work nobody owns.

Can waiting time at a handoff be shown?

Adding days to the arrow is the simplest way. Writing "waiting on approval: 2 days average" makes visible where the time is going. Sometimes it reveals that the waiting exceeds the actual work.

How do you use it once built?

Handover and improvement review are the two main uses. For cross-department work especially, gathering the parties and talking through the diagram surfaces differences in how people understood the process.

What the Diagram Will Not Solve

A swimlane diagram shows only the division of responsibility — who does what. It cannot show by when, or how far along things are now. Once ownership is settled, the remaining work is turning it into dates and progress.

Xtrategy manages campaign schedules alongside budget and KPIs on a single screen.

Summary

• A swimlane diagram expresses ownership through the position of each step.
• Its main value is making the lane-crossing arrows — the handoffs — visible.
• Splitting lanes by role rather than department makes the diagram robust to reorganisation.
• Order the lanes the way documents and data get passed along. Intersections drop.
• Give customers and vendors lanes too, so waiting time does not vanish from the diagram.
• Past eight lanes, split the diagram by phase rather than cramming one page.

The purpose of a swimlane diagram is to keep the division of responsibility under continuous review. When it is finished, count the arrows crossing lanes. That number is how many times this process can stall.