Flow Chart

Written prose holds up until the conditions start overlapping. "If someone who clicks an invite link already has an account, send them to the document; if not, send them to sign-up; if the link has expired, send them to the resend notice regardless of whether they have an account" is still readable. Add the case where the person who sent the invite has since left the company, and the case where the team has hit its plan's seat limit, and you can read the same paragraph three times without forming a picture of which case leads where.

So specification reviews kept producing the same moment. An engineer asks, "if someone without an account clicks an expired link, do they sign up first or do we block them outright?" and the person who wrote the document starts thinking it through on the spot. Usually that case was never decided — and the fact that it was never decided is invisible in prose. That is the weakness of writing it out: a missing case looks exactly like the text around it.

A flow chart fixes this by giving every branch its own shape. Put a diamond at each point where the path splits and draw the arrows leaving it, and a diamond with only one exit looks wrong at a glance. Cases nobody decided show up as empty space.

A chart is built from four shapes and one connector, and each shape carries a fixed meaning so that another team can read it without a legend.

1. Start and end — drawn as rounded shapes. One chart gets one start; it can have several ends. An invite acceptance chart starts the moment the link is clicked and ends three ways: inside the document, at a completed sign-up, or at a blocked notice.
2. Process — a rectangle. Something that simply happens without splitting. "Send the invite email" or "set the role to editor" — one line ending in a verb.
3. Decision — a diamond. A question that can be answered yes or no. "Does an account exist" works; "check the account status" doesn't, because you can't label the outgoing arrows if the answer doesn't fall into branches.
4. Off-page connector — a marker that carries the flow onto another page when it gets long. Once more than about twenty shapes crowd onto one page, reading the chart becomes slower than reading the prose.

Arrows carry the conditions. The two arrows leaving a diamond get labeled yes and no, and when a condition has three or more outcomes, each branch gets its value written on it. The easiest thing to leave out is the arrow that loops back. If someone who finishes signing up has to return to the invite check and that line isn't drawn, readers conclude the flow ends at sign-up.

The person who owns the feature usually draws it, and a designer joins in when the path crosses several screens. If the designer has already sequenced the screens in a wireframe, the faster route is to carry that sequence over and only add diamonds where the path splits.

Three groups read it, and each looks at something different. Engineers count the diamonds to estimate how many conditional branches the code needs. Seven diamonds means seven or more paths to test, which changes the answer about how long the work takes. Designers count the rectangles to see how many screens they have to produce. Whoever owns quality assurance (QA) walks each path from start to end to build a test list, and raises a question on the spot when that list disagrees with the acceptance criteria.

One diagram is not the whole specification. A flow chart shows order and branching only, so what each step actually displays belongs to the functional spec and the screen definition. Keep the three together, and when a diamond changes, change the matching condition sentence too. Update only one of them and two weeks later nobody can tell which version is real.

"This case isn't on the flow chart. Where does someone with an expired link go?"

A gap in the diagram, which usually means a case that hasn't been decided yet.

"Nine branches is more than fits in this sprint. Let's do the first four."

Converting the diamond count into scope and cutting it.

"We have the flow chart but no screen definition. What shows on an empty state?"

The order is settled but the content of each step is still blank.

Mia drew one of these during the week Pagedeck reworked its invite feature. The path split three times — on whether an account exists, on whether the invite is still valid, and on the team's seat limit — giving three diamonds and five ends. The case where the person who sent the invite has already left the company turned out to be blank, and that only surfaced while the diagram was being drawn.

Theo looked at it and said two of the five paths were already covered by existing code, which narrowed the work to the other three. Without the picture, reaching the same conclusion would have taken two more meetings. The value of the chart is not that it renders the feature precisely; it's that it makes the missing cases visible.

Worrying about tools and appearance first is common. It's a picture, so it feels like it should look good, and most people have seen a handsome one somewhere. What readers actually check is whether every branch is present. Spend half a day on colors and alignment and that's half a day not spent working through the cases, and a pretty chart with one diamond missing goes into the meeting.

The other mistake is treating the chart as a replacement for the specification. It has the order and the conditions in it, so it feels sufficient. But the diagram stops at "if there's no permission, go to the blocked notice" — it says nothing about what that notice reads or how many buttons it has. Hand over the chart alone and engineering can start, but a question comes back with every screen, and the people running the check have no basis for deciding whether the work passes.