识别排除，从被排除者出发
别名: 识别排除 · 从被排除者出发 · exclusion audit
概念解释
人物画像是双手完好、视力正常的年轻人。第一次发现有人进不来，是 VoiceOver 用户的一星评价：超时、悬停才出现的按钮、只有颜色的错误。识别排除（identify exclusion）是先找出产品假设已经把谁锁在门外，再从那个人的任务往回拆，而不是先画一个「无障碍人格」当配菜。Microsoft 的包容性设计把这一步放在开头：排除是被设计做出来的，不是用户自己带来的缺陷。
还没点出「谁开始不了、哪条假设害的」，后面的边石效应和参与式过程都没有工作对象。
机制
每个界面都默认了一具身体、一种环境、一段可用时间。默认一旦写成交互（限时、悬停、只靠色、只靠拖），不满足默认的人不是「边缘用户」，是被这条决策关在门外的人。从被排除者出发，是把那条决策翻到台面上：不是抽象地「考虑残障」，而是「这条超时把谁的任务掐断了」。
第二层是排除常常被平均数藏住。完成率 85% 的流程里，被挡住的 15% 可能整类通道都进不去；平均值看起来健康，门却是锁的。识别排除要的是失败案例的结构（哪一种输入、哪一种感官、哪一种时间压力），不是把残障标签贴进画像底部。Persona spectrum 在这里是工具：同一条需求可以落在永久、临时、情境三种身体上，用来发现假设，而不是用来把三种人写成三份互不来往的需求文档。
怎么研究
做排除审计：选一条关键任务，写下「怎样的人根本开始不了」以及对应的产品假设（必须看见、必须用指针、必须在五分钟内、必须听得见提示音）。对照真实反馈和辅助技术走查，看名单上的每一类是否被任务数据支持。
自变量：任务、被声明的用户画像是否包含失败结构、是否记录了假设本身。 因变量：能否点名被排除的群体与那条假设、审计前漏掉而反馈里出现的排除种类数。
招募障碍用户是后续参与步骤；这一步可以先用任务失败日志和 AT 走查把假设列出来。不要用「残障人口比例」代替排除结构——比例回答市场大小，不回答门在哪。
边界
安全与身份校验会故意排除未通过认证的人，那不是包容性意义上的排除，审计要分开写「谁不该进」和「谁该进却进不来」。极端小众、与产品目的无关的失败（用这套照片应用去控制核设施）不必列入。识别排除若只停在清单、从不改假设，就退化成展览。内部工具的「被排除者」可能是新员工或访客角色，不一定是残障诊断，假设照样锁门。
怎么落地
- 每条关键任务附一张排除卡：谁开始不了、是哪条假设（限时 / 悬停 / 单通道 / 单输入）。
- 画像里禁止只有成功路径的身体；至少写入一种会在这条任务上失败的结构。
- 新交互落地前先问「关掉这条通道或这种输入，任务是否还存在」，答「不存在」就先记排除，再谈方案。
- 验证：拿排除卡对照最近的失败反馈。反馈里有卡上没有的种类，卡就是还没识别到；卡上有种类但任务数据从未出现过失败，去核假设是否写错，而不是把卡当完成。