Process Modeling Reference
A practitioner’s checklist for evaluating grammar, style, shapes, connectors, swimlanes, and layout in boxes-and-arrows process flows and UML Activity Diagrams.
How to use this reference. Each rule carries a severity rating:
MUST (structural or semantic correctness) ·
SHOULD (strong convention; occasional exceptions allowed) ·
NICE (polish and professionalism).
Rules marked UML are drawn from the UML Activity Diagram specification and its associated style guidelines.
Section 1
Scope & Setup
These rules apply to general boxes-and-arrows process flow diagrams and UML Activity Diagrams. The same principles govern both: a process has a start, a sequence of activities, decisions, and an end. The notation may vary; the quality standards do not.
SC-01
Include a title that names the process, its scope, and whether it depicts the current or future state.
A diagram without a title forces every reader to infer context. The title should answer: What process? At what boundary? As-is or to-be?
✓Employee Onboarding Process — As-Is (IT provisioning excluded)
✗Process Flow v3
SC-02
Place the start point in the top-left corner.
Readers scan top-left first. Anchoring the start point there aligns the diagram with natural reading direction and eliminates ambiguity about where the process begins.
SC-03
Decompose diagrams with more than ~30–50 elements into a hierarchy of sub-process diagrams.
Large diagrams become cognitively unreadable. Use sub-process references, page connectors, or a numbered diagram hierarchy. Break down complex processes rather than cramming everything onto one canvas.
SC-04
Include a legend when using non-standard symbols, color-coding, or custom line styles.
Any symbol a reader might not immediately recognize needs a definition. Even standard diagrams benefit from a legend when color encodes meaning.
SC-05
Simplify operations that would otherwise require a complex internal flowchart by using a sub-process reference.
When an activity’s internal logic is complex enough to warrant its own diagram, represent it as a single collapsed step at the parent level and provide a drill-down. Embedding complex sub-flows in-line obscures the high-level process story.
SC-06
Include version, date, and author in a metadata block or diagram footer.
Particularly important for diagrams used in audits, compliance reviews, or cross-team handoffs.
Section 2
Grammar & Language
The verb-noun convention is the single highest-value language rule in process modeling. It encodes precisely what action is performed on what object, eliminating the ambiguity of noun-only labels or vague task names. Apply it universally — to activities, decisions, and events alike.
GL-01
Name every activity using a Verb + Object (Noun) phrase in present tense.
The verb names the action; the noun names the business object being acted upon. Avoid gerunds (-ing forms) as the primary verb. Drop articles and pronouns for conciseness.
✓Review Invoice · Submit Claim · Approve Purchase Order
✗Reviewing · Invoice Processing · Handle the PO
GL-02
Label every element. No shape in the diagram should be left unnamed.
An unnamed shape is a question mark for every reader. Activities, decisions, start and end points, and swimlanes all require labels. The only acceptable exception is a connector line on a self-evident linear path with no branching.
GL-03
No two activities in the same diagram should share identical names.
Duplicate activity names create traceability errors and reader confusion. If the same action genuinely recurs, differentiate it by its object: Review Vendor Invoice vs. Review Customer Invoice.
GL-04
Apply a consistent verb vocabulary. Use the same verb for the same class of action throughout the diagram.
Inconsistent synonyms break traceability and signal careless modeling. Establish a short verb list and apply it uniformly — always Submit, never Send / Forward / Transmit for the same action class.
✗Send Report · Transmit Form · Forward Invoice (three verbs for one action class)
GL-05
Avoid abbreviations and acronyms unless defined in a legend or universally understood in the domain.
Organization- or department-specific acronyms exclude any reader outside that group and create maintenance debt as terminology evolves.
GL-06
Keep activity labels concise — ideally 2–5 words. Move additional context to a text annotation.
A label longer than one line is a warning sign: either the activity scope is too broad (split it) or the label is over-documenting (move the detail to a note or annotation shape).
GL-07
Spell-check all labels before publication. Typos in a diagram undermine its credibility as a professional artifact.
Section 3
Shapes & Symbols
Each shape carries a specific semantic meaning. Misusing a shape is not a style choice — it is a correctness error that misleads readers who know the notation. The table below covers the core shapes for general flowcharts and UML Activity Diagrams.
| Shape | Common Name | UML Activity Term | Correct Use |
|---|---|---|---|
| ● Filled circle | Start | Initial Node | Marks where the process begins. One per diagram (or per concurrent region). |
| ◎ Circle-in-circle | End | Activity Final Node | Marks a terminal state. Every flow path must resolve to one. |
| ⊗ Circled X | Flow End | Flow Final Node | UML only. Ends one flow thread without terminating the whole process. |
| ▭ Rectangle | Activity / Task | Action / Activity | An atomic unit of work. Requires a Verb + Noun label. |
| ▭+ Sub-process | Sub-process | Call Behavior Action | A collapsed group of activities. Should expand to a child diagram. |
| ◇ Diamond | Decision / Merge | Decision Node | Decision: one input, multiple labeled outputs. Never used for activities. |
| ━ Thick bar | Fork / Join | Fork / Join Node | Fork: splits one flow into parallel threads. Join: synchronizes parallel threads back to one. |
| [ ] Pin | Object / Data | Object Node / Pin | Represents an artifact or data object passed between activities. Should be smaller than activity shapes. |
| ⊙ Circle ref | Off-page connector | — | Continues flow across pages. Paired connectors must share the same label. |
SH-01
Every diagram must have exactly one start point per flow path, with no ambiguous or implied entry.
In UML Activity Diagrams this is the Initial Node (filled circle). In general flowcharts it is an oval or rounded shape labeled “Start.” No reader should have to guess where the process begins.
SH-02
Every flow path must terminate at an explicit end point. No dangling arrows or dead ends.
A process with multiple decision branches may have multiple end points — one per terminal state. Every branch, including exception paths, must connect to either the next step or a clearly marked end.
SH-03
Use diamonds exclusively for decisions and merge points — never for activities or descriptive labels.
A diamond labeled with a verb (e.g., Review Request) is a semantic error. That action belongs in a rectangle. Diamonds ask questions and route flow; rectangles perform work.
SH-04
All instances of the same element type must use the same shape and consistent size throughout.
Size variation between activities implies a difference in importance or scope that probably doesn’t exist. Use snap-to-grid or shape styles to enforce uniformity.
SH-05
Use off-page connector symbols when a flow continues across diagram pages. Paired connectors must share the same label.
An arrow that simply stops at a page edge with no connector shape is a readability defect. The reader has no way to know where the flow resumes.
SH-06
Depict action objects (data objects, artifacts) as visually smaller than activity shapes.
Object nodes are inputs and outputs of activities — they support the process, they do not perform it. Making them smaller than the activities they serve reinforces this visual hierarchy.
SH-07
Do not create custom symbols without defining them in a legend.
Custom shapes break portability and comprehension for any reader outside your team. If a standard shape exists for your purpose, use it.
SH-08
Show only critical inputs and outputs as object nodes. Do not model every data artifact that flows through the process.
Object nodes add value when they clarify handoffs, highlight dependencies, or show state changes. Modeling every document and field creates visual noise that obscures the process flow itself.
Section 4
Connectors & Arrows
CA-01
Every connector must carry a visible arrowhead indicating the direction of flow.
Lines without arrowheads are associations or annotations, not flow transitions. Every step in the process needs a directional cue so readers can trace the sequence without hesitation.
CA-02
Every shape (except the start) must have at least one incoming connection. Every shape (except end points) must have at least one outgoing connection.
A floating shape with no connections is a structural error. A shape with only outgoing connections and no incoming flow (other than the start node) implies an undeclared entry point.
CA-03
Avoid crossing connector lines. Reorganize the layout when crossings occur.
Crossing lines are among the most common readability defects in process diagrams. If a crossing is truly unavoidable, use a bridge or hop symbol to show that the lines do not intersect.
CA-04
Use orthogonal (right-angle) connectors as the default. Use diagonal connectors only when orthogonal routing is not feasible.
Orthogonal routing produces a cleaner, grid-aligned layout that is easier to scan. Diagonal lines fragment visual structure and make consistent alignment harder to maintain.
CA-05
Do not label connector lines on self-evident linear sequences. Reserve labels for decision branches and non-obvious transitions.
Over-labeling connectors creates visual noise without adding information. Labels add the most value where the flow could be ambiguous — at branches and exception paths.
Section 5
Decision Points
Decision points are where process logic lives. Getting them right matters more than almost any other element — an ambiguous or incomplete decision diamond is a defect that can cause the process to be misunderstood or incorrectly implemented.
DP-01
Label every decision gateway with a clear question. The question should be answerable by the conditions on its outgoing paths.
The question format makes the decision criteria explicit for every reader. A decision diamond is not an activity — it routes flow, it does not perform work.
✓“Credit approved?” with outgoing paths “Yes” and “No”
✗“Check Credit” (a verb — this is an activity, not a decision)
DP-02
Every transition leaving a decision point must carry a guard condition (label). Label all outgoing paths — not just the exception branch.
An unlabeled outgoing path makes the branch condition invisible. Even Yes / No or True / False is infinitely better than no label. In UML Activity Diagrams these are called guard conditions and are written in square brackets:
[approved] / [rejected].DP-03
Guard conditions on a decision point must not overlap — only one condition should be true at any given time.
Overlapping guards mean the process has two valid paths simultaneously, making behavior unpredictable. For example, [amount > 100] and [amount > 50] on the same diamond overlap for values between 51 and 100.
DP-04
Guard conditions on a decision point must form a complete set — every possible input scenario must be handled by exactly one outgoing path.
Incomplete guards leave the process undefined for certain inputs. If guards don’t cover all cases, add an [otherwise] or default path to catch anything not handled explicitly.
DP-05
Apply an
[otherwise] guard on the default or fall-through path when not all conditions can be enumerated.When the set of possible input values is open-ended, it is impossible to list every condition explicitly. The
[otherwise] guard acts as a catch-all that makes the diagram logically complete without requiring exhaustive enumeration.DP-06
Reflect the preceding activity’s outcome in the decision question. The decision should test the result of what just happened.
A decision point that has no logical connection to the activity immediately before it is a modeling red flag. Decision questions should naturally flow from the result of the preceding step.
✓Activity: “Review Application” → Decision: “Application complete?”
✗Activity: “Review Application” → Decision: “Is it Tuesday?”
DP-07
Avoid superfluous decision points — do not add a decision if the flow could be expressed more clearly as a direct transition or branching from the activity itself.
Every decision diamond adds cognitive load. If a diamond has only one meaningful outgoing path (the other being trivial or always false), the decision adds no value and should be removed.
DP-08
Question any “black-hole” activity — an activity with no outgoing transition or one whose outputs never connect to anything meaningful.
A black-hole activity consumes flow and produces nothing the diagram can trace. It usually signals a modeling error: either the process was cut off prematurely or an end event was forgotten.
DP-09
Question any “miracle” activity — an activity with no incoming transition that appears mid-process without explanation.
A miracle activity generates results from nowhere. It usually indicates that the triggering input — a message, a timer, a prior step — was not modeled. Every mid-process activity needs a traceable incoming flow.
DP-10
Model guard conditions only when they add genuine clarity. Omit guards that restate the obvious or add no decision logic.
Labeling every transition with a guard, including trivially obvious ones like [flow continues] on a straight-line path, clutters the diagram. Guards earn their place only when they convey a real condition the reader needs to understand.
Section 6
Forks, Joins & Parallel Flow
Forks and joins model concurrent activity — things that happen in parallel rather than in sequence. In UML Activity Diagrams they are represented by thick horizontal or vertical bars. The rules governing them are strict because unbalanced parallel flows produce diagrams that are logically incorrect, not merely unclear.
FJ-01
Every fork must have a corresponding join. Parallel threads opened by a fork must be explicitly synchronized before the process continues.
An unmatched fork means the diagram never shows when the parallel threads converge — or if they do at all. This leaves the process logically open-ended.
FJ-02
A fork must have exactly one incoming transition.
Multiple incoming flows into a fork conflates a merge (decision logic) with a split (parallel launch), producing ambiguous semantics. If you need to merge first and then fork, model them as separate elements.
FJ-03
A join must have exactly one outgoing transition.
Multiple outgoing flows from a join conflates synchronization (join logic) with decision logic, again producing ambiguous semantics. If a decision follows a join, model them as separate elements.
FJ-04
Avoid superfluous forks — do not model activities as parallel if they are simply sequential steps that happen to occur around the same time.
Forks carry a specific semantic: the forked threads run concurrently and the join waits for all of them. If there is no genuine concurrency requirement, a fork adds complexity without value. Prefer a simple sequence unless true parallelism must be conveyed.
Section 7
Swimlanes
Swimlanes (introduced by Rummler & Brache, 1990, and formalized in UML Activity Diagrams as partitions) are the primary mechanism for showing who does what. Their placement and naming carry as much semantic weight as the activities they contain.
SW-01
Every activity must be placed fully inside the swimlane of the role, system, or department responsible for it. No activity should straddle lane boundaries.
An activity sitting on a lane boundary signals unresolved ownership — one of the most common process modeling defects. If an activity genuinely involves multiple roles, model the handoff explicitly as separate activities in their respective lanes.
SW-02
Name lanes using role or function names, not individual person names.
Process models document repeatable operations, not individual assignments. Named individuals make the model obsolete as soon as people change roles.
✓Claims Adjuster · Finance System · Customer
✗John · Sarah in Accounting · The Team
SW-03
Have fewer than five swimlanes per diagram.
Beyond five lanes, a diagram becomes difficult to follow — connectors span large distances, lane labels compete for space, and the overall layout grows unwieldy. If more roles are involved, split the process into sub-process diagrams each with their own swimlane view.
SW-04
Order swimlanes in a logical sequence. The primary actor or initiating role should appear first (top for horizontal, left for vertical layouts).
Optimal lane ordering minimizes connector travel distance and visual crossings. Place the role that starts and drives the most activity in the first lane, then arrange subsequent lanes in the order that flows connect most naturally.
SW-05
Apply swimlanes to linear processes. Avoid swimlanes when all activities belong to a single actor — a simple flow diagram will be cleaner.
Swimlanes add value when there are multiple actors with distinct responsibilities and meaningful handoffs. Adding lanes to a single-actor process creates visual overhead with no informational benefit.
SW-06
Model the key activities in the primary swimlane. Minor or supporting activities should live in secondary lanes.
The primary lane should tell the main story of the process. Readers scan the primary lane first — if the critical path is buried across multiple lanes, the diagram loses its narrative clarity.
SW-07
Consider horizontal swimlanes for business processes. Vertical lanes work well for system interaction diagrams.
Horizontal lanes (roles stacked top to bottom, process flowing left to right) align with business process convention and left-to-right reading. Vertical lanes (roles side by side, process flowing top to bottom) suit technical or system interaction diagrams.
SW-08
Place shared action objects (data artifacts passed between roles) on swimlane separators to visually represent the handoff.
Positioning an object node on the boundary line between two lanes clearly shows that it is the output of one role and the input of another — without requiring additional connector routing across lanes.
SW-09
For complex diagrams with many concurrent responsibilities, consider using swimareas (two-dimensional partitions) rather than simple one-dimensional swimlanes.
Swimareas allow partitioning by two axes simultaneously — for example, by business unit on one axis and by system on the other. This avoids the combinatorial explosion of lanes needed to express the same information in a single-dimension layout.
SW-10
If a swimarea contains several activities, consider breaking it into separate, smaller activity diagrams.
A dense swimarea that packs many activities into one region defeats the purpose of the two-dimensional partition. Sub-diagrams with focused scope are easier to read and maintain.
Section 8
Layout & Style
LS-01
Establish and maintain a single reading direction: left-to-right for most business processes; top-to-bottom for simple linear flows. Never mix directions within a diagram.
LS-02
Align shapes to a grid. All shapes of the same type should be horizontally or vertically consistent.
Misaligned shapes signal a carelessly assembled diagram. Alignment is a proxy for quality — if shapes aren’t aligned, readers suspect the process logic isn’t either. Use snap-to-grid in your diagramming tool.
LS-03
Apply consistent, uniform spacing between shapes. Do not cluster some steps and spread others without reason.
Inconsistent spacing implies grouping relationships that don’t exist. Tightly clustered steps appear related; widely spaced steps appear independent. Make proximity intentional.
LS-04
Make the “happy path” visually dominant — straight, uninterrupted, and positioned along the primary reading axis.
Exceptions, rework loops, and alternative branches should visually deviate from the main spine. Readers scan the main path first; exceptions branch off it. This mirrors how the process is expected to run most of the time.
LS-05
Clearly label any back-flows (loops returning leftward or upward). Route them so they do not obscure forward flows.
Rework and retry loops are necessary but inherently disruptive to reading direction. Label them with their trigger condition and route them along the outer edge of the diagram to keep the main path readable.
LS-06
Use a single font family throughout. Use weight or size — not multiple typefaces — to distinguish element types.
Font mixing adds visual noise without informational value. Two weights of one font are sufficient for all typographic hierarchy in a process diagram.
LS-07
Use color intentionally and sparingly. Encode only one variable per color.
Color should add information — not decoration. Use it to encode one thing (e.g., actor lane, or exception path) and apply it consistently. Limit the palette to 3–4 colors per diagram to avoid overwhelming readers.
LS-08
Ensure sufficient contrast between text and shape backgrounds.
Low contrast is a quality defect whenever the diagram will be printed, projected, or viewed by someone with a visual impairment. WCAG 2.1 AA recommends a 4.5:1 contrast ratio for normal text as a practical benchmark.
LS-09
Avoid drop shadows, 3D shape styles, and decorative fill patterns. Flat, clean shapes communicate more clearly.
Decorative styling adds visual weight without informational value and degrades when printed in grayscale or at small sizes. Keep the visual treatment as minimal as the content allows.
LS-10
Peer-review every diagram before publication. Walk through it with someone who was not involved in creating it.
A reviewer unfamiliar with the process is the best test of whether a diagram is self-explanatory. If they cannot trace the flow without asking questions, the diagram needs revision — not explanation.
LS-11
Establish and document an organizational style guide for process diagrams and apply it to every diagram produced.
Even when teams agree on best practices informally, interpretation drift occurs over time. A written style guide prevents it. It should specify: font, shape palette, color meanings, connector styles, verb taxonomy, and naming format.
Sources & Further Reading
- Ambler, Scott W. — Elements of UML 2.0 Style (Cambridge University Press, 2005)
- Object Management Group — UML 2.5.1 Specification, Activity Diagrams chapter (OMG, 2017)
- Rummler & Brache — Improving Performance: How to Manage the White Space on the Organization Chart (1990) — swimlane origin
- American Society for Quality (ASQ) — What is a Flowchart? (asq.org)
- ISO 5807:1985 — Information Processing: Documentation Symbols and Conventions for Data, Program, and System Flowcharts
- Creately — Essential Flowchart Rules and Flowchart Symbols Reference (creately.com)
- ConceptDraw — Flowchart Design: Principles, Symbols, Layout and Best Practices (conceptdraw.com)
- Visual Paradigm — BPMN & UML Modeling Best Practices (visual-paradigm.com)
- WCAG 2.1 — Web Content Accessibility Guidelines, Contrast Criterion 1.4.3 (w3.org)