Design the task, not the requested component.
A frontend feature is not complete because the requested component exists.
A button can render correctly and still leave the experience unfinished. A card can look polished and still fail to support the work the user came to do. A form can submit successfully in the happy path and still collapse when validation fails, the network slows down, the user lacks permission, the server returns a conflict, or the user needs to correct a mistake.
The Complete Flow Law asks designers, frontend engineers, and coding agents to treat the user task as the unit of completion.
The requested interface element is only one part of that task.
A complete experience considers how the user reaches the feature, what they understand before acting, what they can do, what the system does while work is in progress, how success is communicated, what happens when something fails, how the user recovers, and where the experience goes next.
This matters especially in AI-assisted development because coding agents often optimize for the literal surface of a prompt.
A prompt such as:
Add an invoice card.
can easily produce:
- invoice number,
- customer,
- amount,
- date,
- status,
- perhaps a menu.
The component may be correct. The task may still be incomplete.
If the existing product already allows invoices to be opened, edited, downloaded, cancelled, deleted, or otherwise acted upon, the new card lives inside that behavioral system.
The implementation question therefore changes from:
What component was requested?
to:
What user task does this component participate in, and what states are required for that task to actually work?
Sections
- 01Foundation and the task unitA feature is complete when its expected user task can be entered, understood, performed, interrupted, corrected, recovered from, and finished across the states that reasonably belong to the product.
- 02The nine flow stagesNine stages carry a task from the moment the user arrives to the moment they move on.
- 03Context layersThe nine stages are not fixed. A context layer decides which of them a task can reach at all, and a flow that is complete for one user can be unreachable for another.
- 04Scope and feature creepCompleting a task is not the same as inventing product scope. Three levels separate the work that belongs to the request from the work that belongs to a product decision.
- 05Worked examplesFour tasks, each traced from the requested surface to the states a real path reaches.
- 06State completenessNot every component needs every state. It needs the states its own task can reach, which is a shorter and more specific list.
- 07Anti-patternsFour shapes a surface-only implementation takes. Each is a decision the flow never made.
- 08Agent execution and evidenceHow an agent applies this law: the order of reasoning, the evidence that supports a finding, the scope boundary that stops one, and the exact shape a report has to emit.