UX & Software Ergonomics
A systematic usability examination starts with a defined task and evaluation question rather than a general preference. Criteria, test conditions, observations and limitations are documented before recommendations are derived.
Short answer
Define the real task, start and end states, evaluation criteria and test environment before running the usability test. Treat task success, time, errors and observations as findings; only then interpret their meaning and test alternative explanations.
A small test can reveal reproducible problems, but it does not automatically establish prevalence in a wider user population. A design recommendation is also distinct from the finding that motivated it.
1. Specify the examination question and real task
Translate a broad question such as “is the application intuitive?” into an observable task for a defined user group. State the goal, relevant prerequisites and what counts as task completion.
Document the start and end state so that repeated sessions examine the same proposition. If the task depends on prior data, permissions or navigation history, those conditions belong to the test definition.
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. Set criteria before conducting the test
Select quantitative and qualitative criteria before observing the result. Task success, completion time and error count can be combined with interaction observations, user questions and comments.
Criteria must match the professional question. A faster path is not automatically better if it increases errors, and successful completion does not by itself demonstrate efficient or understandable interaction.
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. Document test conditions reproducibly
Record product version, browser or operating system, device, viewport, input method and relevant data state. Performance and environment can change the user experience enough to alter the conclusion.
Record assistance, interruptions and deviations from the planned protocol. A result reached after coaching is different evidence from an unaided first attempt and should be reported as such.
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. Treat measurements and observations as findings
Record what occurred before explaining why it occurred. Task completion, hesitation, backtracking, errors and repeated attempts are observations that can be checked independently.
Do not equate a single metric with usability. A task may eventually succeed after unnecessary detours or cognitive effort, while a fast completion can depend on prior experience that is not representative of the intended user group.
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 counter-hypotheses and sample limitations
Consider experience, training, data quality, environment and technical defects as alternative explanations. Where practical, vary one condition at a time or compare additional evidence.
Small studies can reveal defects and interaction patterns, but they cannot automatically estimate how frequently a problem occurs in a population. Report sampling and recruitment limits explicitly.
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 assessment from design recommendation
First state the finding and the criterion against which it is assessed. A proposed redesign or workflow change is a subsequent recommendation, not part of the original observation.
Where a change is implemented, test it again rather than assuming that the recommendation solved the problem. A plausible design hypothesis is not evidence of improved usability until the relevant interaction is re-examined.
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 task defined as an observable goal?
- Are start and end states documented?
- Were criteria selected before testing?
- Are version, device and environment preserved?
- Are assistance and deviations recorded?
- Were counter-hypotheses considered?
- Are sample and generalisation limits explicit?
Constructed example
A checkout task is tested with a defined account state and browser version. All participants eventually finish, but several enter an error loop after one field loses its value. The report records the repeated sequence and the condition under which it occurs, then tests whether the behaviour changes with different data before proposing a design change.
The example is entirely constructed and does not describe a real engagement, client matter or historical case.
Sources and technical basis
- Normative referenceISO 9241-11:2018 — Usability: Definitions and concepts. Reference framework for usability and context of use. Open source.
- Normative referenceISO 9241-110:2020 — Interaction principles. General interaction principles for interactive systems. Open source.
- Normative referenceISO 9241-210:2019 — Human-centred design for interactive systems. Principles and activities for human-centred design. Open source.
- Technical guidanceW3C WAI — Involving Users in Evaluating Web Accessibility. Guidance on user involvement, context and limitations of generalisation. Open source.
- Methodological basisSources & Methodology documents source hierarchy, counter-hypothesis control and statement boundaries for the English knowledge base.
Further reading
- Usability and Software Ergonomics as a Subject of Examination
- Interaction Principles and Dialogue Quality
- Sources & Methodology
Critical review and methodological limitation
A usability protocol can be reproducible without being universally representative. The report should therefore distinguish repeatable interaction findings from claims about prevalence, user populations or future product versions.
Test design can itself influence behaviour through learning, ordering, assistance or artificial data. Those influences should be documented so that later reviewers can judge whether the observed effect is attributable to the interface, the protocol or both.
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