Process and branching

Draws steps as boxes and conditions as branches, so you can see where a decision sits and where a path loops back.

You have practiced the same guitar piece for six weeks and it is not sticking. Some sessions leave you better and some leave you exactly where you started, and you cannot say what separates them. You have been describing your practice as one thing, a habit you either do or skip. It is not one thing. It is a path with at least two forks in it, and you take a different fork depending on how the day went.

Process and branching draws that path. Steps become boxes. Conditions become branches, so a diamond with two arrows out of it says the run splits here, and this is the question that splits it. Arrows carry you forward, and sometimes backward. The job of the form is to show where a decision sits, what each answer commits you to, and which paths return you to the beginning without having moved anything.

It has five common renderers. A flowchart is the plain version: boxes, diamonds, arrows, one start. A decision tree fans forward from a single trigger and never rejoins, so each leaf is one complete outcome you can hang a count on. A swimlane adds a row per person or system and puts every step in the row that owns it, which turns handoffs into arrows crossing a line. A service blueprint splits those rows with a line of visibility, above it what the other person sees, below it the work that makes it possible. A value stream keeps the steps and measures the gaps between them, so waiting shows up as length.