Reference entry content
Concept facts
A failure state is a product, interface, system, or service condition where a process, submission, decision, transaction, data request, or automated action has failed or cannot continue as expected.
- Also known as
- Error state, failed state, service failure state, blocked state.
- Used in
- UX evaluation, service design, form design, payment flows, verification workflows, automated decisions, support design, accessibility, and release readiness.
- Interpret with
- Error message, error recovery, recovery path, status message, input validation, decision explanation, and service handoff.
Plain-language explanation
A failure state is the condition users or staff encounter when something has gone wrong or cannot proceed.
This may include failed payment, failed document upload, failed identity check, failed data loading, rejected submission, failed automated review, or blocked account recovery.
A good failure state helps people understand what failed, what it means, and what can be done next.
Why it matters
Failure states often happen at stressful and high-consequence points in a service journey.
If a failure state is unclear, users may repeat the wrong action, abandon the service, contact support unnecessarily, miss deadlines, or lose access.
In regulated, public-service, financial, health, and development-sector services, poor failure states can create support burden, decision risk, compliance issues, and trust loss.
Use contexts
Failure states are used when:
- a form submission fails
- payment, identity, or document verification fails
- service data cannot load
- an automated decision cannot be completed
- a case cannot move to the next workflow stage
- a user is blocked from continuing
- staff need to diagnose failed system or service actions
- recovery, appeal, or support paths must be triggered
Application guidance
State that failure occurred and identify what failed.
Explain the consequence. Users need to know whether data was saved, whether action is needed, whether money was deducted, or whether a case was affected.
Provide a recovery path. Users should know whether to retry, correct information, upload evidence, contact support, or wait.
Avoid blaming the user where the system or service may be responsible.
Make failure states accessible. Error and status information should be available to assistive technologies.
Log and monitor repeated failure states. Frequent failures may reveal deeper usability, technical, operational, or policy problems.
Practical example
A fintech onboarding service fails during identity document upload. The screen says “Something went wrong” and returns the user to the previous page. The user does not know whether the document was uploaded or whether the application is saved.
A failure-state redesign explains that upload failed, confirms the application draft is saved, shows accepted document formats, and provides retry and support options.
The UX consequence is reduced abandonment, fewer duplicate applications, lower support burden, and stronger trust in account opening.
Interpretive boundaries
A failure state is not the same as an error message. The error message is the communication; the failure state is the broader condition and service context.
A failure state is not the same as recovery path. The failure state describes the problem condition; the recovery path describes how users or staff can move forward.
Some failure states result from valid service rules, not system errors. They still need clear explanation and next action.
Applied at Userhub
Userhub evaluates failure states where blocked progress, failed submissions, automated review problems, or unclear system conditions affect user trust and task completion.
In UX Lab work, failure states can be assessed through usability validation, accessibility review, product evaluation, and release-readiness analysis.
See Userhub UX Lab for applied UX research and evaluation context.
Sources and references
World Wide Web Consortium. (2024). Web Content Accessibility Guidelines (WCAG) 2.2. https://www.w3.org/TR/WCAG22/
Government Digital Service. (n.d.). Writing for GOV.UK. GOV.UK. https://www.gov.uk/guidance/content-design/writing-for-gov-uk
Amershi, S., Weld, D., Vorvoreanu, M., Fourney, A., Nushi, B., Collisson, P., Suh, J., Iqbal, S., Bennett, P. N., Inkpen, K., Teevan, J., Kikin-Gil, R., & Horvitz, E. (2019). Guidelines for human-AI interaction. Proceedings of the 2019 CHI Conference on Human Factors in Computing Systems. https://doi.org/10.1145/3290605.3300233
Government Digital Service. (n.d.). Service Standard. GOV.UK Service Manual. https://www.gov.uk/service-manual/service-standard
Cite this entry
APAUserhub. (2026). Failure State. UX Reference. https://userhub.com.bd/reference/failure-state/