Beauty Diagram
Use case

Cross-team process flows

Document handoffs between teams, systems, and roles using PlantUML swimlanes. Made for PRDs, approval chains, order fulfilment, and incident runbooks where who-owns-what matters as much as what-happens-next.

The goal is not to rewrite the diagram from scratch, but to make the source easier to present and reuse.

At a glance

A scenario page for product managers, business analysts, ops, and SREs whose process diagrams need an explicit owner per column.

Who this is forWhy a swimlane beats a flowchart hereCommon patternsWorkflow
Rendered proof
Reimbursement approval flow that branches by amount and routes through finance.
Theme · Memphis
Open this diagram in editor
REQUESTER DIRECT MANAGER DEPARTMENT HEAD FINANCE yes no yes no START SUBMITREIMBURSEMENT AMOUNT < 50K? MANAGER APPROVE FORWARD UPWARD HEAD REVIEW APPROVED? RELEASE RECEIVE REJECTION STOP DISBURSE PAYMENT FUNDS RECEIVED STOP
View PlantUML sourcePlain-text diagram syntax — copy or edit directly.
diagram.puml
1@startuml
2|#E6E6FA|Requester|
3start
4:Submit reimbursement;
5|#ADD8E6|Direct Manager|
6if (Amount < 50k?) then (yes)
7  :Manager approve;
8else (no)
9  :Forward upward;
10  |#FFFACD|Department Head|
11  :Head review;
12  if (Approved?) then (yes)
13    :Release;
14  else (no)
15    |Requester|
16    :Receive rejection;
17    stop
18  endif
19endif
20|#FFDAB9|Finance|
21:Disburse payment;
22|Requester|
23:Funds received;
24stop
25@enduml

Who this is for

Anyone whose work hits a responsibility boundary at every step. The default flowchart hides those boundaries — a swimlane diagram makes them the spine of the picture.

  • Product managers writing PRD user flows where Customer / Frontend / Backend each own a slice
  • Business analysts mapping AS-IS / TO-BE processes for compliance, finance, or HR reviews
  • Solution architects documenting cross-service flows in shared design docs
  • QA leads sketching end-to-end test scenarios that span App / API / DB / CI
  • SREs writing incident runbooks where Monitoring / On-call / SRE Lead / Customer Support each own a phase
  • Operations / customer success teams diagramming customer journeys with multiple handoffs

Why a swimlane beats a flowchart here

A flowchart can describe the same steps, but it puts every node on equal visual footing. A swimlane treats the lane — the team, the system, the role — as a first-class structural element. The reader sees the handoffs without reading any labels. That's especially valuable for PRDs and runbooks where the audience is mixed: engineering, product, support, legal, customer-facing.

  • Lanes anchor each step to its owner — no ambiguity about responsibility
  • Cross-lane edges become the literal handoffs you want the reader to notice
  • Per-lane colour gives the diagram a quick visual key without a legend

Common patterns

Most cross-team process diagrams fall into one of four shapes. Beauty Diagram ships templates for each so you can start from a working example and adjust the labels rather than draft from scratch.

  • Linear pipeline — one path through every lane (order fulfilment, onboarding)
  • Conditional branch — a decision in one lane sends the flow down different lanes (approval by amount)
  • Escalation — most cases stay in one lane; exceptions pull in a higher-tier lane (incident response)
  • Closed loop — the flow ends back in the lane that started it (PRD user flows where the customer signs off)

Workflow

Write the source as PlantUML so it lives next to the spec, runbook, or RFC it describes. Beauty Diagram renders it with horizontal lane columns, theme-matched palette, and orthogonal cross-lane edges. Export SVG into the doc or save the diagram in Diagram Hub for follow-up edits.