Map a workflow before you build it

Intermediate · 6 min · Draw a one-page map: inputs, steps, outputs and checks.

  • workflows
  • process design

A workflow map is four boxes — input, steps, output, checks — plus a name, drawn on one page before anything is built. If you cannot draw it, you cannot test it, and the version in your head will quietly disagree with the version in everyone else’s. The map is not documentation written after the fact; it is the design.

The four boxes

  • Input. The artefacts that arrive, in what state — and how you notice when one is missing or broken.
  • Steps. One job per step, in the order the inputs move. “Extract the decisions” is a step; “and also write the summary” is a second step pretending to be one.
  • Output. The artefact that leaves, and who consumes it. Naming the consumer decides the format.
  • Checks. Where a mistake is caught: a format check, a rubric pass, a comparison against the source, a human gate. At least one check should sit before the output leaves.

Draw it backwards, in six moves

  1. Name the output and its consumer — the artefact that leaves and who reads it.
  2. List the inputs that must exist for that output to be possible, in the state they must arrive.
  3. Place the steps between them — one job per step, in movement order.
  4. Mark the joins: confirm each step's output is exactly what the next step expects as input.
  5. Add the checks: format validation, a rubric pass, and the human gate before the output ships.
  6. Add the failure paths: missing input, low-confidence output, a step that errors — say where each one goes.

Where workflows actually break

At the joins. Step 2 produces a prose summary; step 3 needed a table. Or the extractor returns dates as “next Tuesday” and the filter sorts by ISO date. Joins are where silent corruption happens, because each step did its own job fine.

At the edges. Odd inputs arrive: a scanned page where a digital one was expected, a source in another language, a missing field. A workflow without an edge policy does not fail loudly — it fails politely, by producing something plausible from incomplete material. Naming the edge and its route (“flag and skip, note it in the output”) is the difference between a process and a wish.

You are mapping a workflow that turns interview transcripts into a themed summary. Which item is a join check rather than a step?

A bad example

Plan: “We’ll throw the transcripts at the assistant, get themes, and someone will read it before sending.”

Which transcripts, in what state? What does “read it” check? With no map, the human review is doing quality assurance for a process nobody described — and it will miss the empty file and the missing speaker labels.

A better example

Plan: “Inputs: one audio file per interview, transcriber output named [interviewer]-[date].txt. Steps: transcribe → join check (non-empty, speaker labels present) → extract quotes by topic → cluster quotes → draft themes. Check: each theme must quote at least two participants, or it is dropped. Edge: a failed transcription goes to the flag list and the summary ships with its coverage note.”

Now every part of “someone will read it” has a name, and the map doubles as the test plan.

Why it works

The map converts quality from an intention into a placement question. Checks become visible objects you can assign to a person or a rule; joins become mismatches you can catch before they compound; edges become routes instead of surprises. It also disciplines the build: you can implement and test one step at a time, with a stub for the neighbours, and you will notice early when a step is trying to do two jobs.

Practice

Order the workflow map

Your team wants to automate a recurring client report: transcripts, CRM notes and a metrics sheet go in; a two-page summary goes out. Before anyone builds anything, you are mapping the workflow on one page.

Order the moves so the map is drawn in a sequence that surfaces checks and failure paths before the build starts.

  1. Mark the joins: check that each step's output is exactly what the next step expects.
  2. Add the checks: format validation, a rubric pass, and the human gate before the output ships.
  3. Add the failure paths: missing input, low-confidence output, a failed step — and where each one goes.
  4. Name the output and its consumer — the artefact that leaves and who reads it.
  5. List the inputs that must exist for that output, and the state they must arrive in.
  6. Place the steps between them — one job per step, in the order the work moves.
Hint

Start from what leaves, not from what arrives: the consumer decides the format.

Checks are placed, not sprinkled — put each one at a specific join or gate.

Transfer

  • Repeatable reports: the map doubles as the handover document when someone covers your leave.
  • Data pipelines: the join check is the schema; the edge policy is the error queue.
  • Hiring and ops processes: the same four boxes reveal where approvals actually belong.
  • Before buying tools: map the process first — the map, not the tool, decides what you need.

Key takeaways

  • Four boxes on one page: input, steps, output, checks — drawn before building.
  • Workflows break at the joins and the edges; name both, and say where failures go.
  • A map with checks is also a test plan — each step can be tried on its own.

Next

Finished this lesson?