Flowchart: one process, drawn so people can follow it

A process or user flow drawn as steps, questions and outcomes, for the people who have to follow it.

2 live examples

The example: Handling a refund request at Oxbow Tableware

Four questions, three roles, and a written version

Handling a refund request at Oxbow Tableware

Open the exampleThe names and numbers are made up.

What to notice

  • Each of the four diamonds is a yes-or-no question with both branches labeled, such as "Is the refund over $150?"
  • Every step box names its role in capitals, Support, Warehouse or Finance, and each role has its own tint.
  • Three ends are drawn, not one: no refund, the customer's choice after a failed inspection, and refunded.

The prompt that starts one like it

Make a flowchart as a single HTML page for [process, such as handling a refund request] at [company]. The steps and rules: [paste them]. Draw it in inline SVG with a start, an end for every outcome, decision diamonds with labeled yes and no branches, and who does each step. Use a stacked layout on a phone so the text stays readable. Under the chart, write the same steps as a numbered list. Then publish it on sharable.link so only [your company's domain] can open it.

The example: Sign-up to first class in a climbing gym app

Seven screens, six actions, five ways off the path

Sign-up to first class in a climbing gym app

Open the exampleThe names and numbers are made up.

What to notice

  • The wanted path is solid blue and every arrow on it carries a short label, from "Create account" to "Book free class".
  • Five dashed boxes hang off the screens they belong to: three errors, one empty list and one stop for under-18s.
  • Two open questions sit at the bottom, each with the name of the person who has to answer it.

The prompt that starts one like it

Draw a user flow as a single HTML page for [app]: [the task, such as signing up and booking a first class]. The screens are [list them]. Show each screen as a box with what's on it, label every arrow with the action that causes it, and hang error and empty states off their screen in a different line style. Stack the screens on a phone. Add a screen-by-screen spec and our open questions underneath, then publish it on sharable.link so only [your company's domain] can open it.

A flowchart is worth drawing when two people would otherwise do the same job two different ways. This page has two to open: a shop's refund process, and an app's screens from sign-up to a first booking. Both are samples to adapt, and your own process goes in through the prompt.

Who it's for

Whoever owns a process and is tired of explaining it: an operations lead writing down how refunds work, a manager with a new hire starting Monday, a designer handing a flow to developers. Send it when the rules have just changed, or when the third person this month has asked what happens next.

It's the wrong tool for a workshop where the team drags boxes around together. Use a whiteboard app for that, and publish the chart once it has settled.

What a good one contains

  • One start, and an end for every outcome. The refund chart has three ends: no refund, the customer's choice, refunded. A single end usually hides the unhappy paths.
  • Questions that take a yes or a no. "Is the refund over $150?" can be answered at a desk. "Assess the refund" can't. Put the threshold inside the diamond.
  • A label on every branch. An unlabeled arrow out of a diamond makes the reader guess. Yes and No sit on the lines.
  • Who does each step. Each box carries a role. When a request stalls, the chart says whose desk it's on.
  • One main line. The usual case runs straight down and the exceptions step off to the side.
  • The same steps as a list. Seven numbered lines repeat the refund chart in words, for people who would rather read and for screen readers.
  • In a user flow, the paths nobody wants. The gym app shows five: a taken email, a wrong code, someone under 18, an empty class list, a full class. Developers build what's drawn, so draw what happens when things fail.

Small enough to trace with a finger

Most charts fail by trying to hold everything. The refund sample has nine steps and four questions, and that's close to the limit for one picture. Past that, split it: one chart for the main process, another for the exception with rules of its own.

Open it on a phone before sending. A wide chart shrunk onto a small screen turns into grey threads, so both samples switch to a narrower, stacked drawing there. Then ask someone who doesn't do the job to trace one case from start to end. Where their finger stops, a branch is missing.

When the rules change, replace the page. The link your team saved keeps working, and nobody follows last quarter's chart.

How to send it

To named people. A process chart shows where your limits sit, like the refund size that needs sign-off. Keep it to the team that follows it.

Every page you publish gets one link that opens in any browser. You choose who can open it: anyone with the link, anyone with the password, or only the people and company domains you name, who sign in with Google or Microsoft. Change the page later and the link stays the same.

Make yours in Claude

Add the connector once, then publish from any Claude conversation and get a link to send.

Add Claude Connector

Already have the file? Upload it here.

More in product and engineering

  • KPI dashboard: A few numbers with their changes and the reasons behind them, sent to the same readers on a schedule.
  • Product roadmap: What a product team is building now, next and later, by theme, for customers and colleagues.
  • Data visualization: One dataset drawn as a few interactive charts, each with a sentence that says what to see.
  • Product requirements document: The problem, the requirements and what's left out for one feature, for the people who will build it.
  • App prototype: A clickable phone app in one page, sent to a few people to try before anyone writes real code.
  • Release notes: What's new, better and fixed in this version of your product, written for the people who use it.
  • All use cases

Keep reading