UX & Software Ergonomics
Usability is a property of use in a defined context, not an abstract label attached to an interface. A defensible examination therefore identifies the users, tasks, system state, environment and assessment criteria before drawing conclusions about interaction quality.
Short answer
A UX examination becomes technically examinable when the concrete system version, user group, task and context of use are defined and observations are connected to explicit criteria. Personal preference, measured behaviour, user statements and technical logs are different evidence types and should not be collapsed into one conclusion.
The result is bounded to the examined users, tasks, product state and environment. A technical UX assessment does not by itself establish legal accessibility or other legal conformity.
1. Define users, tasks and context of use
Identify the intended or observed user group, relevant experience, abilities and prerequisites. The same interface can create different demands for an experienced administrator, an occasional customer or a person using assistive technology.
Describe the task as an observable goal rather than evaluating the screen in isolation. The question is whether the defined user can complete the intended task under documented conditions and what interaction events occur along the way.
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. Preserve the concrete system and version state
UX findings must be tied to the product state actually examined. Record version, configuration, relevant content, browser or platform and the interaction components that can affect the task.
Navigation, wording, interaction logic and performance can change between releases. Device class and input method also matter because keyboard, pointer, touch and assistive technologies can expose different behaviour.
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. Separate personal impressions from assessment criteria
Words such as intuitive, attractive or confusing are observations or opinions until they are related to a defined quality criterion. State whether the examination concerns task completion, efficiency, controllability, error handling, learnability or another explicit characteristic.
Select references that fit the question. ISO 9241 terminology can structure usability and interaction principles, while the technical examination must still show how a cited concept maps to observable behaviour in the product.
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. Document different evidence types separately
Record task success, errors, interaction sequences, timing, user statements and technical logs as distinct evidence layers. An observed abandonment or successful completion is a finding, but it does not yet explain its cause.
A user statement may reveal an important difficulty without being a statistical estimate for an entire population. Likewise, a log or telemetry event can show a system state without proving how a user understood it.
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 alternative explanations
Do not attribute every difficulty to interface design. Performance, bad data, missing domain knowledge, device conditions, permissions or technical defects can produce similar symptoms.
Use counter-tests where possible: change one condition, compare another user group or environment, or inspect technical evidence. Alternative explanations that remain compatible with the evidence should remain visible in the conclusion.
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. Limit the conclusion to the examined context
Report which users, tasks, versions and environments were actually examined and which were not. A small usability test can reveal important problems but does not automatically establish population-wide frequency.
Keep technical UX findings separate from legal conformity. Accessibility statutes, contractual obligations or product acceptance can require additional legal or normative analysis beyond the examined 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.
Examination checklist
- Is the user group explicitly defined?
- Is the task observable and bounded?
- Are version, configuration, device and input method documented?
- Are criteria selected before the conclusion?
- Are observation, user statement and technical data distinguished?
- Were relevant counter-hypotheses tested?
- Is the statement boundary tied to the examined context?
Constructed example
A team reports that an administrative workflow is “unusable.” The examination defines the relevant user role, records the exact release and browser, and observes a multi-step task. The user eventually completes it, but repeated navigation errors and hidden state changes occur. The finding is reported for that task and context rather than converted into a universal statement about the entire product.
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
Critical review and methodological limitation
Usability evidence is context-dependent. Changing the user group, task, product version, device or environment can materially change the observed result, so reproducibility requires more than repeating the same clicks.
The examination should show which parts are direct observation and which are professional interpretation. Where sample size, historical state or user context is limited, that limitation belongs in the result rather than being hidden by broad labels such as “good UX” or “bad UX.”
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