A Mental Model for “Good” vs “Bad” BPMN

“Make your BPMN diagrams simple and easy to read.” This advice appears everywhere — in blogs, training videos, even tool tooltips. But in my 20 years of auditing and refining process models, I’ve seen how such vague guidance often leads to a false sense of clarity. Simplicity without structure breeds ambiguity. A diagram may look clean, but if it misrepresents flow, hides responsibilities, or misuses notation, it becomes a liability.

Good BPMN is not about aesthetics. It’s about trust. It’s about being clear in intent, correct in structure, consistent in style, and purposeful in audience. Bad BPMN hides flaws behind clean lines and color schemes. It may look professional but fails to communicate, misleads implementers, or collapses under scrutiny.

This chapter gives you a repeatable mental model to assess any BPMN diagram. Use it to decide when a model is “good enough” — not just for the sake of completion, but for execution. You’ll learn how to evaluate BPMN models with confidence and avoid the hidden traps that make even well-intentioned diagrams harmful.

What Makes a BPMN Diagram “Good”?

Clarity: Is the intent obvious?

A good BPMN diagram makes the process easy to follow, even for someone unfamiliar with the domain. Clarity isn’t about minimalism. It’s about intentional design.

Ask: Could a stakeholder understand the process from the diagram alone? If not, clarity is missing.

Clarity manifests in:

• Unbroken flow from start to end event, with no orphaned or unreachable elements.
• Logical layout — consistent flow direction, minimal crossing flows, and visual grouping of related activities.
• Clear handoffs between roles, departments, or systems, especially in collaboration diagrams.

When a modeler says, “It’s obvious,” but the reader has to guess, the diagram lacks clarity.

Correctness: Does it follow BPMN syntax and semantics?

Correctness means the model uses BPMN notation properly and reflects the intended behavior. A diagram can be visually clean but still wrong — and that’s worse than a messy one that’s accurate.

Correctness requires:

• Correct event types: Start events must be either Start or Intermediate (e.g., Timer, Message, Error). End events must be End or Terminate — and only used when warranted.
• Valid gateway usage: XOR, AND, and OR gateways must be paired correctly. A split must have a corresponding join. Inconsistent gateways break flow logic.
• Proper flow types: Sequence flows connect activities within a process. Message flows link pools. Mixing them creates confusion.

Even one incorrect symbol can invalidate the entire process interpretation — especially in automation.

Consistency: Is the style uniform and predictable?

Cohesive models follow internal rules. Inconsistency creates cognitive load. A reader must pause to interpret whether a label is a task, condition, or annotation.

Consistency means:

• Uniform naming: Use verb-object format: “Review Application,” “Approve Loan,” “Send Confirmation.” Avoid “Process,” “Handle,” or “Do.”
• Standardized layout: Flow direction (left-to-right or top-to-bottom) should be consistent. Avoid zig-zag or backtracking paths.
• Same treatment of similar elements: If one gateway uses “Yes/No” labels, all should. If an activity is marked as “Manual,” all similar ones should be too.

Inconsistency doesn’t just break trust — it breeds errors when models are reused or handed off.

Purpose: Who is it for, and what do they need?

A model’s value depends on its audience. A diagram for business stakeholders must reflect business language. A model for developers must reveal decision points, exceptions, and handoffs.

Ask: What is the goal of this diagram? If unclear, the model risks being either too abstract or too technical.

Examples:

• For business teams: Focus on roles, triggers, outcomes, and milestones. Avoid technical terms like “API,” “payload,” or “session.”
• For IT or automation: Include decision logic, error handling, and input/output conditions. Gateways should reflect real business rules.
• For auditors: Highlight control points, approvals, and legal dependencies.

Good BPMN adapts to purpose — it doesn’t force all audiences into one view.

What Defines a “Bad” BPMN Diagram?

Ambiguity: When the flow doesn’t mean what you think.

Bad BPMN hides intent behind vague labels, unclear gates, or missing conditions. You can’t trust a diagram if you’re unsure what triggers a step or when the process ends.

Examples:

• “Process Request” — what does that mean? Who initiates it? What’s the input?
• Gateway labeled “Yes/No” without specifying the condition: “Is approval required?” — but what if it’s not?
• End event with no description: “End” — ends what? Under what conditions?

These aren’t simple oversights — they’re interpretation risks. One team may assume “Yes” means “approved,” another assumes it means “requires attention.”

Broken Flow: Dead ends, loops, and disconnected logic.

Broken flow occurs when the process never reaches an end, or a path leads nowhere. These issues often escape early detection because they don’t break syntax.

Common patterns:

• Unreachable activities: A task exists but no flow leads to it.
• Unconnected end events: A process ends with no exit path from the final activity.
• Infinite loops: A gateway loops back without a termination condition.

These aren’t just layout errors — they represent flawed logic. The process as modeled cannot complete.

Unreadable Layout: Visual chaos that obscures meaning.

Even a correct model becomes bad if it’s hard to read. Crossing flows, cramped spaces, and inconsistent alignment damage comprehension.

Signs of poor layout:

• Lines crisscross, making it impossible to trace a path.
• Elements are crammed into one corner or staggered randomly.
• Color is used for decoration, not meaning — e.g., red for “important” without defining what “important” means.

Good layout guides the eye. Bad layout confuses it.

Mixed Modeling Goals: Trying to do too much.

Some diagrams aim to be business maps, system workflows, and technical blueprints all at once. This leads to clutter, overloaded gateways, and mixed semantics.

Examples:

• Using “System” tasks for every technical action — turning the model into a technical flowchart.
• Mixing business decisions with UI interactions: “Click Submit” as a task.
• Embedding business rules directly in gateways: “If applicant age > 18 AND credit score > 650 AND loan amount < 50k” — too complex to read.

When modeling goals conflict, the result is a hybrid that serves no one well.

Evaluate Your BPMN Model: A 4-Part Checklist

Use this mental model to assess any BPMN diagram — before presentation, review, or automation.

1. Clarity: Can you follow the flow at a glance?

• Is there a clear start and end?
• Are handoffs between roles or pools explicit?
• Can you trace the main path without backtracking?

2. Correctness: Does it obey BPMN rules?

• Are start and end events used appropriately?
• Are gateways paired (split and join)?
• Are sequence flows and message flows used correctly?

3. Consistency: Is the style uniform?

• Are activity names in the same format?
• Are conditions labeled consistently?
• Is layout direction the same throughout?

4. Purpose: Who is this for, and why?

• Does the model match the audience’s understanding?
• Are technical details only where needed?
• Are business terms used instead of system jargon?

If you can answer “yes” to all four, your diagram is good enough for its purpose.

When Is a Diagram “Good Enough”?

Not every diagram needs to be perfect. But “good enough” is not a synonym for “acceptable.” It means: valid for its intended audience and purpose.

Consider:

• A high-level business map for executives may omit gateways, sub-processes, or message flows. It needs clarity and purpose — not full technical depth.
• A technical design model for developers must show error paths, loops, and decisions. Correctness and consistency are non-negotiable.

Good vs bad BPMN isn’t binary. It’s a spectrum. The goal isn’t perfection — it’s trustworthiness.

Frequently Asked Questions

How do I evaluate BPMN models when I have no BPMN training?

Start with the 4-part checklist. Focus on flow clarity, correct events, consistent naming, and audience alignment. Use tools like Visual Paradigm’s built-in validation to catch obvious syntax issues. Ask: “If I were a stakeholder, would I understand this?”

Can a BPMN model be correct but still bad for the audience?

Absolutely. A model might be syntactically correct but use technical terms, dense logic, or poor layout. It’s correct but not useful. Good BPMN must be valid and readable for its audience.

What if my diagram is too complex to simplify?

Break it into levels. Use sub-processes to hide detail, or split the process into multiple diagrams. Use call activities to reference reusable flows. Always define a clear scope — what’s in, what’s out.

How do I handle conflicting feedback from business and IT on the same BPMN?

Don’t merge them into one model. Create two views: one business-focused, one technical. Use consistent naming and reference points. Then link them — e.g., “Approval Flow” in the business model refers to “Call Activity: Approval Process” in the technical model.

Should I use DMN to handle complex decisions in BPMN?

Yes. If a gateway contains more than two conditions or complex logic, move that logic to a DMN decision table. Reference it in BPMN with a “Decision” event. This keeps BPMN clean and separates concerns.

How often should I review BPMN models for quality?

Review every model before sharing, especially before automation. Use the 4-part checklist as a peer review tool. Conduct stakeholder walkthroughs for high-impact processes. Regular audits prevent drift and ensure consistency.