O1.05.3Freely given consent设计研究

拒绝即不可用不构成自由选择

别名: 自由同意 · 强迫同意 · take-it-or-leave-it consent

概念解释

自由给予的同意(freely given consent)要求拒绝可选处理不会带来与该处理无关的重大不利后果。若界面以“同意否则无法使用”捆绑一项并非核心功能必需的收集,用户的点击反映的是对服务的依赖或退出成本,而不是对该数据用途的认可。这不同于拒绝必要处理导致相应功能确实无法工作,关键在于后果是否与所拒绝的数据因果相关且相称。

机制

同意假定存在可接受的替代路径。账户历史、社会关系、工作要求、已付款项或市场支配会抬高离开成本,使形式上的二选一变成压力下的服从。系统若把这种点击记录为偏好,会进一步高估用户对处理的接受度。拒绝代价越大,接受率越缺乏解释力;它测到的是约束条件下的行为,而非孤立态度。

怎么研究

研究可操纵拒绝后的功能损失、迁移成本和替代方案,测量选择、感知自主性、后悔与后续撤回。结构化访谈应要求参与者解释“如果拒绝会失去什么”以及这些后果是否合理。现场数据需结合账户依赖程度和可替代性分层,不能把高接受率当作自由意愿。伦理上也不应通过真实剥夺关键服务来制造实验条件,可使用情景或低风险原型。

边界

自由选择不意味着服务必须在缺少技术必需数据时提供完全相同的能力。例如不提供地址就无法完成实物配送,但这不自动授权营销画像。付费替代方案是否自由取决于价格、可及性与服务性质;象征性选择可能仍具强制性。组织或学校要求使用的工具中,真正的决策者还可能不是界面前的个人。

怎么落地

  • 对每个拒绝后果写出与数据用途的技术依赖,无法证明因果关系的功能不得被关闭。
  • 保留不含可选处理的核心路径,并在选择前准确预览差异,不用模糊的“体验可能受影响”恐吓。
  • 对已有内容、联系人或付费权益提供导出、过渡期和退款安排,降低沉没成本对选择的扭曲。
  • 用拒绝账户完成端到端任务,逐项记录缺失能力并由独立评审判断其必要性;同时访谈用户能否在不承受额外惩罚时维持拒绝。

延伸

  • 同组O1.05.1 冗长条款实际上无人阅读 · O1.05.2 一揽子同意无法表达细粒度意愿 · O1.05.4 同意请求出现的时机决定用户是否有认知资源阅读 · O1.05.5 移动端小屏幕进一步压缩了可理解同意的信息量 · O1.05.6 用简化摘要替代法律原文会丢失关键例外条款 · O1.05.7 频繁的同意请求造成机械式点击接受而非理解后同意
  • 相邻O1.10 同意的粒度与可撤回 · O4.02 暗黑模式的分类
  • 站内检索freely given consent · take-it-or-leave-it · undue influence

同组卡片

快捷操作

分享

分享当前页面

ios_share

https://hci.top/zh/handbook/O1.05.3