#Context changes the flow
The 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.
#Permissions
Do not show actions that will always fail unless exposing the restriction itself has value.
Use the product's established permission model.
#Responsive behavior
Responsive completeness means the task remains available.
A desktop action row may become an overflow menu on mobile.
Do not hide necessary actions merely to make a layout fit.
#Accessibility
The flow should remain operable through:
- keyboard,
- visible focus,
- programmatic labels,
- semantic controls,
- appropriate status feedback,
- assistive technology.
Accessibility belongs to completion, not a future polishing pass.
#Empty states
Different empty states can represent different tasks:
They require different next steps.
#Long and unusual content
Test realistic extremes:
- long names,
- large currency values,
- missing optional fields,
- long localization strings,
- many tags,
- long tables.
Do not design only against ideal mock fixtures.
#Concurrency
Collaborative products may need to handle:
- stale data,
- edits by another user,
- deleted records,
- changed statuses,
- conflicts.
Only implement this when the product architecture supports such states.