If you've ever opened a flowchart and wondered why there are so many different shapes or worse, if you've been using them interchangeably you're not alone. In software engineering, each flowchart shape carries a specific meaning. Using the wrong one can confuse your team, lead to misread logic, or create documentation that nobody trusts. Knowing what each shape represents is the foundation of writing flowcharts that actually communicate clearly.

What Are the Standard Flowchart Shapes Used in Software Engineering?

Standard flowchart shapes come from conventions established in the ISO 5807 standard, which defines how to document software processes visually. These shapes form a shared language when every developer on a team reads a rectangle as a "process" and a diamond as a "decision," there's no room for guessing. Here are the core shapes you'll encounter:

Oval (Terminator)

The oval, sometimes called a rounded rectangle, marks the start or end of a process. Every flowchart needs at least one start oval and one end oval. Think of it as the entry and exit doors of your diagram.

Rectangle (Process)

This is the workhorse of flowcharting. A rectangle represents any action, operation, or computation things like "calculate total price," "save to database," or "send email notification." If something is being done, it goes in a rectangle.

Diamond (Decision)

The diamond is where your flowchart branches. It always contains a yes/no or true/false question, such as "Is the user logged in?" or "Is the cart empty?" Two arrows leave a diamond one for each possible answer. This shape is central to representing conditional logic like if-else statements.

Parallelogram (Input/Output)

Use a parallelogram when data is being received or produced reading user input, displaying a result, writing to a file. It separates "thinking" from "interacting with the outside world."

Arrow (Flow Line)

Arrows connect the shapes and show the direction of flow. Without them, a flowchart is just a collection of shapes with no sequence. Arrow direction matters always read from tail to head.

Rectangle with Double Vertical Lines (Predefined Process)

This shape refers to a named process defined elsewhere, like a function call or a subroutine. If your flowchart has a step that says "Run Payment Module," you'd use this shape to signal that the details live in a separate flowchart.

Document Shape (Document Output)

Shaped like a rectangle with a wavy bottom edge, this represents a printed or digital document an invoice, a report, a receipt. Use it whenever a step generates something meant to be read by a person or another system.

Diamond with a T-Shape (Preparation)

Also called a hexagon in some toolkits, the preparation symbol marks setup or initialization steps like declaring variables or setting default values before the main logic runs. It signals "this step prepares for what comes next" rather than performing the core logic itself.

Database Shape (Storage)

A cylinder shape represents data storage, usually a database or a data table. Use it when your flowchart reads from or writes to a persistent store.

Connector (Circle)

A small circle, often labeled with a letter or number, is used to link different parts of a flowchart that can't be connected by a straight line commonly when a flow spans multiple pages or sections.

Why Does Using the Right Shape Matter?

Software documentation is only useful if people interpret it the same way. When you use a diamond for a process step or a rectangle for a decision, you introduce ambiguity. Teammates reviewing your flowchart might ask, "Wait, is this a question or an action?" That kind of friction slows down code reviews, onboarding, and debugging.

Consistent use of standard shapes also makes your diagrams scalable. A flowchart for a login system follows the same visual grammar as one for an order-fulfillment pipeline. Once your team internalizes the conventions, reading any diagram becomes second nature.

For teams working with business process mapping conventions, the shapes bridge the gap between developers and non-technical stakeholders everyone reads the same picture.

When Should You Create a Flowchart in Software Development?

You don't need a flowchart for every task. But certain situations benefit from one:

  • Planning complex logic before writing code multi-step conditionals, loops, and error handling are easier to reason about visually.
  • Documenting existing systems when onboarding new developers or preparing for handoffs.
  • Debugging a process that isn't working as expected drawing the current flow often reveals gaps you missed while staring at code.
  • Communicating with non-developers like product managers, QA testers, or clients who need to understand the logic without reading source code.
  • Code reviews where a visual summary of a proposed change helps the team understand intent quickly.

What Are Common Mistakes People Make with Flowchart Shapes?

Even experienced developers get sloppy with flowcharts. Here are mistakes that hurt readability:

  1. Using rectangles for everything. When every step looks the same, readers can't tell where decisions happen or where data enters the system.
  2. Forgetting start and end points. A flowchart without terminators leaves readers guessing where to begin reading.
  3. Overloading diamonds with multiple conditions. A decision should have two outcomes yes or no. If you need three or more branches, either chain diamonds together or use a case structure following standard conventions.
  4. Mixing abstraction levels. Don't put "save to database" and "call atomic function to acquire row lock" in the same flowchart. Keep detail levels consistent.
  5. Skipping arrow labels on decision branches. Always label "Yes/No" or "True/False" on decision branches so readers don't have to guess which path means what.
  6. Creating flowcharts that are too large. A single diagram covering an entire application is unreadable. Break it into modules using the predefined process shape to link smaller charts together.

Practical Example: Login Flowchart Shapes

Suppose you're documenting a basic login flow. Here's how you'd assign shapes:

  • Oval: "Start"
  • Parallelogram: "User enters email and password"
  • Rectangle: "System hashes password and queries database"
  • Database shape: "User table"
  • Diamond: "Do credentials match?"
  • Rectangle: "Create session token" (Yes branch)
  • Parallelogram: "Display dashboard" (Yes branch)
  • Rectangle: "Increment failed login counter" (No branch)
  • Diamond: "Have attempts exceeded limit?"
  • Rectangle: "Lock account" (Yes branch)
  • Parallelogram: "Show error message" (No branch)
  • Oval: "End"

Notice how each shape tells you what kind of action is happening without needing to read the text inside. That's the value of using shapes correctly they carry meaning before you even read the words.

Tips for Creating Clear Flowcharts

  • Follow a top-to-bottom, left-to-right flow. This matches how most people read and reduces confusion.
  • Limit each flowchart to one process. If you're documenting login and password reset, make two charts.
  • Use consistent spacing and alignment. Messy layouts make even correct flowcharts hard to follow.
  • Label every arrow leaving a decision. Never assume readers will know which path is "yes."
  • Keep text inside shapes short. A rectangle that says "Validate that the user's email address matches the RFC 5322 standard and is not already registered in the user table" is unreadable. Write "Validate email format" instead.
  • Use a legend if your audience includes non-developers. A small shape key at the top of the diagram prevents confusion.

Where Can I Learn More About Flowchart Symbol Standards?

If you want the formal specification behind these shapes, the ISO 5807 document covers symbol definitions, usage rules, and diagram structure in detail. You can read more about how ISO 5807 standardizes flowchart symbols on our breakdown page. For an external reference, Lucidchart's guide to flowchart symbols provides a visual overview of each shape with examples.

Quick Reference: Flowchart Shapes at a Glance

  • Oval/Rounded Rectangle → Start or End
  • Rectangle → Process / Action
  • Diamond → Decision (Yes/No question)
  • Parallelogram → Input or Output
  • Arrow → Direction of flow
  • Double-bordered Rectangle → Predefined process (function/subroutine)
  • Document Shape → Generates a document
  • Cylinder → Database / Data storage
  • Circle → Connector (links sections)
  • Hexagon/T-Rectangle → Preparation / Initialization

Checklist Before You Share Your Next Flowchart

  1. Does it have a clear start (oval) and end (oval)?
  2. Is every decision step a diamond with labeled Yes/No branches?
  3. Are input/output steps using parallelograms, not rectangles?
  4. Is each shape used for only one type of meaning throughout the diagram?
  5. Are text labels short enough to read at a glance?
  6. Does the flow move top-to-bottom or left-to-right without crossing arrows?
  7. If the chart spans multiple pages, are connector circles used to link sections?
  8. Would a new team member understand this without asking you to explain it?

Print this checklist and keep it next to your keyboard the next time you open a diagramming tool. Getting the shapes right from the start saves you from rewriting the whole thing later and makes your engineering documentation something people actually read.