Ergonomics standards often bind the process, not only the finished interface

What it is

Acceptance asks “is the button big enough, is contrast high enough.” Another class of clauses in ergonomics standards never asks what the finished object looks like. They ask how it was made: whether context of use was described, whether real users took part, whether evaluation happened in that context and fed a change. For ISO 9241-210 and its kin, process requirements are met by context descriptions, evaluation records, and traces of iteration — not by a contrast screenshot.

Treating them as one more pixel checklist skips the hardest part of the standard: the usability no checklist enumerates, which the process is there to force into the open.

Why it happens

Usability is context-bound: who, where, on what device, trying to finish which job. Change the context and the same interface flips from right to wrong, so an ergonomics standard cannot write “the correct UI” as a context-free finished state. It rewrites how the work is done: specify context, design, evaluate in context, go back if it fails. A clause is met when the activity happened and the artefacts can be audited.

The second layer is a division of labour with outcome criteria. Success criteria in the WCAG family ask “is some channel still cut on this page right now”; process standards ask “are you working in a way that could discover the cut.” Both can be required at once. Outcome lists alone miss tasks that were not sampled and barriers that were never written as criteria. Process records alone can produce a beautiful plan and an interface that still fails outcome criteria. Process requirements exist because ergonomics admits that outcomes cannot be exhaustively listed.

Studying it

Do an archive audit against process clauses, not another round of contrast measurement. Ask the project for a context-of-use description, who participated, which prototype was evaluated in which situation, and how findings were written back. Map the gaps onto ISO 9241-210 activities (understand context, specify, produce, evaluate).

Independent variables: presence of a context document, whether participants were real users rather than staff, whether evaluation happened before design freeze, whether findings flowed back. Dependent variables: whether process clauses can be evidenced from the archive, count of blocking defects found only after release on critical tasks.

Ethnography or contextual inquiry can be the evaluation activity inside the process; replacing them with “we walked it internally” is not the same evidence. Do not invent an effect size to prove that “process always raises completion.” What is being tested is whether the process was performed.

Where it stops holding

If procurement cites only outcome clauses (AA of a dated WCAG), a process archive does not replace that band of outcome evidence. Safety-critical systems carry heavier process (independent evaluation, change control); a general interactive product’s ergonomics process does not automatically upgrade into those regimes. A short-lived experimental prototype can cut the process down — and then must not claim conformance to that process standard. When a purely static article has almost no “design process” to audit, the clauses apply to an iterating product team, not to one frozen page.

Applying it

• Write context of use as one auditable page: people, environment, devices, critical tasks. Do not open visual files without it.
• Schedule at least one evaluation with real users before lock, and record what changed. Evaluation that only happens after launch still leaves the process clause unmet.
• Acceptance should demand two piles: test records against outcome criteria, and process artefacts. Missing archives are unmet process, even when pixels already line up.
• How to check: pick one process clause (for example “evaluate in context”) and ask for date, participants, tasks, and the change list. Screenshots of the UI without those four items mean the process standard was treated as an outcome list.

Related

• Same group: J1.03.2 A legal citation of a standard is a citation of a dated version · J1.03.3 Meeting a standard is not evidence that people can complete the task
• Nearby: J1.04 Legal requirements · Q1.01 Formulating the research question · J5.14 Testing with disabled users
• Search terms: ISO 9241-210 · human-centred design process · process requirement