UX & Software Ergonomics
Error handling in interactive systems is more than an error message. Invalid input, technical exceptions, rejected actions, timeouts and asynchronous states can produce different system conditions, and users need enough feedback and control to understand what happened and continue safely.
Short answer
Reproduce the trigger and resulting system state first. Then examine what feedback is presented, whether it is perceivable and attributable, how correction or recovery works and whether the user retains meaningful control. Technical cause, visible feedback and ergonomic impact are separate findings.
A clear message does not prove that the underlying state is correct, and a backend error does not by itself establish poor user feedback. Conclusions remain limited to the tested workflow, product version and context.
1. Define the error state and expected result
Establish the intended task and the state that actually occurred. Distinguish invalid input, domain rejection, technical exception, timeout and competing processing state instead of treating all of them as the same “error.”
Document start state, input data, permissions, version and environment so the trigger can be reproduced. Only then can the response be assessed against the expected task outcome.
The examination records the concrete task, user group, system version, device or input method and the selected assessment criterion before interpreting the result. An observation on one path is not silently generalised to all users, components or product states. Technical and ergonomic findings are kept separate from a legal conformity assessment, and untested contexts remain outside the conclusion.
2. Record feedback as a distinct evidence layer
Technical cause and user-facing feedback are different. A backend can correctly reject a request while the UI shows an unhelpful generic message, or a polished message can appear while the internal state remains inconsistent.
Record visual, auditory and assistive-technology feedback, timing and association with the relevant control or process. For automatically detected input errors, WCAG provides criteria relevant to identification and textual description.
The examination records the concrete task, user group, system version, device or input method and the selected assessment criterion before interpreting the result. An observation on one path is not silently generalised to all users, components or product states. Technical and ergonomic findings are kept separate from a legal conformity assessment, and untested contexts remain outside the conclusion.
3. Test correction and recovery
Check whether invalid input can be corrected, valid data is preserved and the process returns to a defined state. Multi-step operations can introduce duplicated actions or lost input when users retry.
For destructive operations, confirmation, undo, restoration or clearly limited effect may be relevant. Evaluate practical control in the task rather than merely counting dialogs or buttons.
The examination records the concrete task, user group, system version, device or input method and the selected assessment criterion before interpreting the result. An observation on one path is not silently generalised to all users, components or product states. Technical and ergonomic findings are kept separate from a legal conformity assessment, and untested contexts remain outside the conclusion.
4. Include asynchronous states and status messages
Background requests, queues and long-running operations can make a system appear unresponsive while processing continues. Test whether progress, completion, failure and required next actions are communicated.
Dynamic web applications should expose relevant status changes in a way assistive technologies can perceive where applicable. A visual toast or colour change is not automatically sufficient for every usage situation.
The examination records the concrete task, user group, system version, device or input method and the selected assessment criterion before interpreting the result. An observation on one path is not silently generalised to all users, components or product states. Technical and ergonomic findings are kept separate from a legal conformity assessment, and untested contexts remain outside the conclusion.
5. Test user control and alternative explanations
Control does not mean every operation must be cancellable at any moment. The relevant question is whether consequences remain understandable and whether users can avoid or recover from unintended action where the task permits it.
Permissions, network interruption, competing sessions and stale client state can produce similar symptoms. Test those alternatives so message quality and technical root cause are not conflated.
The examination records the concrete task, user group, system version, device or input method and the selected assessment criterion before interpreting the result. An observation on one path is not silently generalised to all users, components or product states. Technical and ergonomic findings are kept separate from a legal conformity assessment, and untested contexts remain outside the conclusion.
6. Separate finding from ergonomic effect
The technical finding describes trigger, response and recovery. The ergonomic interpretation asks whether the user can understand the state, identify the affected input, correct the situation and retain the task context.
One good error message does not prove robust error handling across the product, and one reproducible problem does not establish that all users or functions are equally affected.
The examination records the concrete task, user group, system version, device or input method and the selected assessment criterion before interpreting the result. An observation on one path is not silently generalised to all users, components or product states. Technical and ergonomic findings are kept separate from a legal conformity assessment, and untested contexts remain outside the conclusion.
Examination checklist
- Is the trigger and expected state defined?
- Are technical cause and visible feedback documented separately?
- Can the user correct input without losing valid context?
- Are asynchronous states and completion status visible?
- Is practical user control tested?
- Were network, permission and stale-state alternatives considered?
- Is ergonomic impact separated from technical cause?
Constructed example
A form submission returns a validation error. The backend response correctly identifies one field, but the UI displays only a generic banner and moves focus away from the form. The examination records both the technically correct validation and the interaction problem, then tests whether corrected input preserves the other valid fields.
The example is entirely constructed and does not describe a real engagement, client matter or historical case.
Sources and technical basis
- Normative referenceISO 9241-110:2020 — Interaction principles. General interaction principles for interactive systems. Open source.
- WCAG 2.2 guidanceW3C WAI — Understanding SC 3.3.1 Error Identification. Technical explanation of identifying input errors. Open source.
- WCAG 2.2 guidanceW3C WAI — Understanding SC 4.1.3 Status Messages. Technical explanation of status messages, including assistive-technology exposure. Open source.
- Methodological basisSources & Methodology documents source hierarchy, counter-hypothesis control and statement boundaries for the English knowledge base.
Further reading
- Interaction Principles and Dialogue Quality
- Keyboard Operation, Focus Management and Semantic States
- Sources & Methodology
Critical review and methodological limitation
Error handling is state-dependent. A message can be appropriate for one trigger and misleading for another, so findings should be tied to the reproduced condition and the actual system state behind it.
Do not infer overall usability from one recovery path. Different permissions, network states or asynchronous timing can create different behaviours that require separate reproduction and explicit boundaries.
Translation and methodological scope
This English article is based on the reviewed German V1 source article. The translation preserves the technical meaning, methodological distinctions, source status and stated limitations. It does not strengthen technical findings into legal conclusions and does not treat technical references as proof of compliance or suitability for a specific system.
Author's technical literature and publications
The following works provide additional technical and methodological context. They do not replace required primary sources, standards, manufacturer documentation or other independent specialist sources. Unpublished manuscripts, drafts and teaching materials are deliberately not presented here as public sources.
UX, Software Ergonomics & Accessibility
Technical and methodological examination of usability, context of use, interaction quality and accessible operation.
Explore this assessment service