Process discovery — find the process, then the tools

Load when: the work is of a kind whose steps are not obvious — designing something, running a launch, building a content operation, anything where "how is this done well" has an answer nobody here knows yet.

The failure this prevents is concrete. Asked to design an app, a worker searched its skills for "designer", found nothing usable, and hand-drew gradient placeholders — two to five minutes per screen of garbage — while a flow library, a component library and a wireframing tool sat one rephrase away.

And the fix is not a built-in design pipeline. That is the encyclopedia trap: a hardcoded ladder is right for one domain and wrong for every other one, and this system is meant to work for a channel and a bakery too. The fix is a repeatable step for discovering a process, which is why it is named once here and reused everywhere there is a how rather than a what.

Five steps

1 · Research how the craft does it well — not from memory. The web, live documentation, awesome-{topic}, and the descriptions of skills that already exist. For "design a mobile app" this surfaces something like information architecture → user flows → low-fidelity wireframes → the owner approves the structure → high fidelity → design system. For a snack brand it surfaces something else entirely. You are finding this craft's process, not applying a stored one.

2 · Draft it as a table — one row per step: step · why · tool-or-gap.

The why is what lets the owner judge it — low fidelity before high fidelity because approving structure on cheap artifacts saves the days that redrawing finished screens costs.

The table is the form that cannot skip a step silently: every row must end in a tool line, and a step with no tool IS a gap — written as gap in that cell, never left blank. A blank cell reads as "handled"; the word gap reads as what it is. This is form doing work that prose cannot.

3 · Show the owner: cut, add, reorder — in their words. This is where a designer who skips wireframes gets caught, and where an owner who wants it faster can say so before rather than after.

4 · Search a tool per surviving step, by the step's function. Not one literal string. Use the broadening ladder: rephrase into the craft's own English terms · go one level up to the parent domain · adjacent crafts · decompose the step into tasks and search per task. "Map the user journeys" finds a flow library; "designer" finds nothing.

5 · Name the gaps. A step with no tool is stated as such — build something for it, or do it by hand and say which. A gap named is honest; a gap papered over with improvisation is how the garbage happened.

Record the process

Write the chosen process into the project's documentation, so the next run of the same kind of work starts from it rather than rediscovering it — and so that a better process found later is a visible change rather than a silent drift.

That is the same reason decisions are recorded: not to have a record, but so the next person argues with the previous answer instead of re-deriving it.

This is one method, used in four places

The interview, the discovery checklist, the role builder and this file are the same shape: research the real thing, draft it with reasons, show it for cutting, then tool each surviving step.

Naming it once is what stops it being re-invented per situation with slightly different rules each time — which is the whole argument for ./patterns.

When to reach for it

When the process is not obvious, and specifically:

• the work is in a craft nobody here has done
• a previous attempt improvised and the output was bad — run it on the redo, and it names the steps and the tool each needs rather than one worker winging it
• the owner asks "how should we run this kind of work?"
• a step keeps producing bounced reviews, which usually means a missing step earlier

When not to: a quick job, and anything whose process is already written down and working. Discovering a process that exists is ceremony.