A workflow step is a meaningful point in a person’s or organisation’s progress towards an outcome.
The word meaningful is doing most of the work. A step should help the team understand progress, friction, delay, repetition, failure or completion. It should not merely copy the product’s screen structure.
For account registration, useful steps might be:
-
1
Start account creation
-
2
Enter and submit details
-
3
Verify email
-
4
Access the product
These steps compress several interface interactions into moments that matter to the measurement question. The team can always add more detail when it needs to diagnose a specific problem.
Start with behaviour, then decide the level of detail
A workflow map can be too coarse or too detailed.
“Complete registration” is too broad if the team needs to find where progress breaks. “Focus email field”, “blur email field” and “click continue button” are too detailed for the main workflow map unless those interactions are central to the investigation.
A useful step is detailed enough to distinguish a meaningful change in progress, but stable enough to survive small interface changes.
| Weak step | Better step | Why it is better |
|---|---|---|
| Registration page | Start account creation | Describes the beginning of the attempt |
| Continue button | Submit account details | Describes the meaningful action |
| Error state | Encounter a validation error | Describes what happened in the workflow |
| Confirmation screen | Verify email | Describes progress rather than presentation |
| Dashboard loaded | Access the product | Describes the selected completion condition |
The interface-level versions may still matter to design and engineering. They simply belong in a more detailed interaction or instrumentation view, not necessarily in the primary workflow map.
Not every step happens once or in order
Simple funnels suggest that each person moves through the same steps once. Many products do not work like that.
A workflow step may be:
- required — everyone must complete it
- optional — relevant only for some people or routes
- repeatable — information or choices may be revised
- conditional — triggered by earlier answers or checks
- shared — completed by a different role
- external — performed outside the product but necessary for progress
In a service-quotes marketplace, the customer submits the request, several providers may respond, either side may ask questions, a provider may revise or withdraw a quote and an offline visit may happen before the customer chooses. No single actor performs every step, and there may be no stable order between conversations and revisions.
Mark these differences explicitly. Otherwise the map quietly turns a complex process into a misleading funnel.
A step is not an event
A workflow step describes progress. An event record provides evidence that selected activity occurred.
Workflow step:
Provider submits a quote
Event:
quote.submitted
The distinction gives the team room to design the behaviour before choosing how to observe it. One step may need several events to explain attempts, errors and success. Several small interactions may be represented by one stable event if the finer detail adds no decision value.
The step should remain understandable even before instrumentation exists.
Steps create diagnostic choices
If quote acceptance falls, the team needs more than the headline rate. Clear steps create specific questions:
- Did fewer eligible requests receive any quote?
- Did the time to first quote increase?
- Did customers receive only one option rather than several?
- Did more quotes get revised or withdrawn?
- Did conversations move off-platform before acceptance?
- Did one service type or area account for the change?
A useful step map narrows the search without pretending the event data explains why the behaviour occurred.
Write steps as short verb phrases
Prefer:
Submit service requirements
Review a service request
Submit or revise a quote
Compare available quotes
Accept a quote
Avoid:
Request page
Provider card
Quote modal
Messages tab
Accept button
Define the behavioural structure first. Add interface and technical detail only where it improves implementation or diagnosis. Tracking can be extremely precise and still describe the wrong thing.