J1.07.2design-produced exclusion设计研究
设计决定谁被排除
别名: 设计排除 · who gets excluded · 默认身体假设
概念解释
结账只接受鼠标拖到指定区域才算确认，这份稿已经写好了客人名单：能精细指向、能看到热区、手里有指针设备的人。换键盘、换开关扫描、换成阅读器，同一笔钱付不出去。设计决定谁被排除（design-produced exclusion）说的不是恶意，是产品默认项在发入场券——颜色当唯一状态、悬停才出现操作、三十秒超时、图形验证码，每一项都在划线。
机制
每个默认值都编码了一种被当作「普通用户」的身体。优化那条路径时，被挤出去的人不会出现在漏斗里：他们从未成为用户，分析工具记成「没来」。第二层是排除常常是多数路径的残渣，不是单独的「无障碍功能」没做。把「搜索」做成只有图标可点、名称却是空的，视力用户的点击率可能还上升了——度量在奖励这条设计，被排除的通道没有计数器。所以排除是设计选择的产物，不是用户构成的自然结果。
怎么研究
做排除审计：同一关键任务分别用键盘、开关控制、阅读器、放大和语音控制走完，记录哪一步第一次失败、失败由哪条默认引起。把控件的可见设计和无障碍树上的名称、角色、状态对照。
自变量：输入通道、超时是否可关、状态是否只靠色相。 因变量：首次失败步骤、失败是否随默认项关闭而消失、分析漏斗在该步骤的「自然」流失里有多少其实是通道被关。
不要只用自动扫描的通过率当排除指标——扫描看不见「这份设计把谁写成了非用户」。
边界
法规要求的年龄门、地区下架、内容分级不是这层意义上的设计排除。硬件能力上限（某设备没有触觉引擎）也不能全算进产品稿。用户生成内容的排除，责任在作者和平台规则之间，不能单记在一个屏幕的控件上。排除审计在实验室任务上最清楚；开放浏览里「谁没来」需要另找未完成会话和客服记录，不能从成功用户样本反推。
怎么落地
- 关键路径（注册、搜索、付款、发布）列出默认假设：必须看见、必须用指针、必须在时限内、必须通过图形挑战。每一条假设旁边写被划出去的人怎么完成。
- 新交互先问「关掉指针 / 关掉声音 / 关掉色相，这条还通不通」，不通就还没定稿。
- 不要用「无障碍模式」把被排除者迁到另一条产品里；那是把排除制度化。
- 验证：关掉显示器只用键盘走完结账；用阅读器听每个会改变结果的控件名称。某一步只能靠拖、靠悬停或靠颜色完成，就是这步在决定客人名单。