#The Complete Flow Model
Nine stages carry a task from the moment the user arrives to the moment they move on. A feature is complete when every stage its path reaches has been designed.
Layr evaluates an interactive feature through nine dimensions:
- 1. ENTRY
- 2. DISCOVERY
- 3. ACTION
- 4. INPUT
- 5. SYSTEM STATE
- 6. OUTCOME
- 7. FAILURE
- 8. RECOVERY
- 9. CONTINUATION
A context layer modifies them:
- permissions
- responsive behavior
- accessibility
- empty state
- first use
- long content
- large data
- concurrency
- offline/degraded network
- destructive consequence
#1. Entry
How does the user reach the feature?
Inspect:
- route,
- parent screen,
- deep link,
- list/card,
- search result,
- notification,
- command,
- contextual action.
Questions:
- Is the entry point discoverable?
- Does it match existing product patterns?
- Can the user return?
- Does a deep link work?
- What happens if the target no longer exists?
#2. Discovery
Can the user understand what can be done?
Inspect:
- primary action,
- secondary actions,
- hierarchy,
- labels,
- disabled actions,
- destructive actions,
- menus,
- affordances.
The interface should expose behavior without overexplaining obvious controls.
A capability that technically exists but is practically undiscoverable is still an incomplete experience.
#3. Action
What actions actually belong to this object or state?
The agent should derive them from:
- explicit requirements,
- existing routes,
- existing APIs,
- neighboring interfaces,
- types/state machines,
- tests,
- established product conventions.
Do not create actions solely because they are common in the industry.
#4. Input
What information must the user provide?
Inspect:
- required fields,
- optional fields,
- defaults,
- validation,
- server validation,
- formats,
- file limits,
- accessible labels,
- submit availability,
- draft preservation.
A failed request should not unnecessarily erase valid user work.
#5. System State
What is the system doing after the action begins?
Common states:
- idle,
- loading,
- pending,
- uploading,
- processing,
- queued,
- retrying,
- synchronizing,
- completed.
The UI may need:
- duplicate-submit prevention,
- optimistic state,
- progress,
- cancellation,
- re-entry,
- stale-data handling.
The correct behavior depends on task duration and consequence.
#6. Outcome
How does the user know the task worked?
Success might be communicated through:
- changed data,
- new object appearing,
- status update,
- route transition,
- inline feedback,
- persistent result,
- transient status.
Do not add a toast after every action by default.
The requirement is that the successful outcome is understandable.
#7. Failure
What expected failures belong to the task?
Examples:
- validation,
- transport/network,
- permission,
- expired authentication,
- conflict,
- stale record,
- missing resource,
- rate limit,
- invalid file,
- external dependency,
- partial batch failure.
The UI should distinguish failures that require different user responses.
#8. Recovery
What can the user do after failure or mistake?
Possible recovery:
- retry,
- edit,
- undo,
- restore,
- reconnect,
- refresh,
- request access,
- resolve conflict,
- retry failed subset,
- return safely.
An error message is not always a recovery path.
#9. Continuation
What happens after completion?
Inspect:
- focus,
- route,
- selected item,
- scroll position,
- filters,
- refreshed data,
- next action,
- back navigation.
A mutation can succeed technically and still disorient the user.