标准规定过程要求而非仅结果
别名: 人机工效过程 · ISO 9241-210 · 以用户为中心的设计过程
概念解释
验收会只问「按钮够不够大、对比够不够」。人机工效标准里另一类条款根本不问成品长什么样，问的是你怎么做出来的：有没有描述使用情境、有没有让真实用户参与、有没有在情境里评过再改。ISO 9241-210 这类过程要求（process requirements）的合格证据是情境说明、评估记录、迭代痕迹，不是一张对比度截图。
把它当成又一份像素清单，会把标准里最硬的部分跳掉——恰恰是那些清单覆盖不到的可用性，要靠过程去逼出来。
机制
可用性依赖情境：谁、在哪、用什么设备、要完成哪件事。情境一变，同一套界面的对错会翻转，所以工效标准无法把「正确界面」写成一张与情境无关的完成态。它改写工作方式：先规定使用情境，再设计，再在情境中评价，不合格就回去改。条款满足与否，看活动有没有发生、产物能不能被审计。
第二层是与结果型准则的分工。WCAG 一类成功标准问「这一页现在是否还断着某条通道」；过程标准问「你们有没有用一种能发现断点的方法在做事」。两套可以同时要。只有结果清单时，没被抽到的任务、没被写成准则的障碍会漏掉；只有过程记录时，又可能写出漂亮的计划却交出过不了结果准则的界面。过程要求存在，是因为工效承认结果无法被穷尽列举。
怎么研究
按过程条款做档案审计，而不是再跑一轮对比度量：向项目要使用情境描述、参与者是谁、哪一轮原型在什么情境里评过、发现如何改回设计。对照 ISO 9241-210 的活动（理解情境、规定需求、产出、评价）看缺哪一环。
自变量：是否有情境文档、参与者是否为真实用户而非内部人员、评价是否发生在设计冻结之前、发现是否有回流。 因变量：过程条款能否被档案证明、关键任务上事后才发现的阻断缺陷数量。
人种志或情境调查本身可以是过程里的评价活动；把它们换成「我们内部走查过」不算同一条证据。不要编造效应量来证明「过程一定提高完成率」——这里检验的是过程有没有被执行。
边界
采购若只引用结果型条款（某一版 WCAG 的 AA），交过程档案并不能替代那一档结果证据。安全关键系统会另有更重的过程（独立评价、变更控制），一般交互产品的工效过程不能自动升级成那些制度。时间极短的实验性原型可以裁剪过程，但裁剪后就不要再声称符合那份过程标准。纯内容站点几乎没有「设计过程」可审时，过程要求的适用对象是持续迭代的产品团队，不是一篇静态文章。
怎么落地
- 把使用情境写成可审计的一页：用户、环境、设备、关键任务；没有这一页就不要进入视觉稿。
- 在方案锁定前安排至少一轮真实用户评价，记录改了什么；评价若只发生在上线后，过程条款仍算缺失。
- 验收同时要两份东西：结果准则的测试记录，以及过程产物。缺档案的，按过程未满足处理，即使像素已经对齐。
- 验证：抽一条过程条款（例如「在情境中评价」），向项目要日期、参与者、任务、改动列表。只有界面截图、没有这四项，就是把过程标准当成了结果清单。