D2.11.4Responsibility transfer after muting设计研究

关闭声音后其他通道需要承担起被关闭的信息传递

别名: mute consequences · channel transfer · notification routing

概念解释

关闭一类声音意味着接收责任随之转移。用户把某类声音关掉时,通常仍希望这类事件在真正重要时能被知道;此时设计方的义务是安排这些事件走别的通道,或在确实无法转移时,明确告知这条信息今后不会主动送达。

机制

关闭是一种不可逆的注意力分配:通道被解除后,事件不会自己寻找新的路径。若设计方默认「用户关了就是不要了」,那些被关闭但仍重要的事件会静默消失,用户直到某次需要时才发现从未收到。转移的必要性取决于事件后果:低后果事件可以只留下可查看记录,高后果事件需要主动的替代通道。转移也有代价,视觉通道容易被塞满,因此不能无差别地把所有声音都搬到屏幕上。

怎么研究

可测量关闭后事件的到达率与用户察觉:设置某一类声音关闭,随后触发该类的关键与非关键事件,记录用户是否能获知、获知延迟以及是否认为系统仍会通知。因变量包括到达率、延迟与信任评分。研究需区分用户主动关闭与系统默认关闭,前者含有明确的用户意图,后者的责任更完全在设计方。

边界

当用户明确表达某项信息完全不需要时,强制的替代通道会成为骚扰,此时正确的做法是尊重选择并保留可查看的记录。若不存在合适的替代通道,设计方应显式说明后果而不是默默丢弃。转移设计也需要与静音场景下的降级规则保持一致,避免同一事件在不同入口下得到不同处理。

怎么落地

  • 对每类可关闭声音列出关闭后的去向:其他通道主动送达、仅保留可查看记录,或明确不再送达。
  • 在关闭操作发生时说明这一去向,让用户的决定建立在后果清楚的基础上。
  • 对高后果事件保障至少一条替代通道,并验证该通道在用户常见设置下仍然生效。
  • 验证方式:关闭某一类声音后触发该类事件,检查是否按声明的去向处理,并请用户复述他们是否知道事件发生过。

延伸

  • 同组D2.11.1 用户需要能按类别而非全部开关来控制声音 · D2.11.3 分类控制入口需要独立于系统级静音开关
  • 相邻D2.05.1 静音时的关键信息需转移到其他通道 · D2.05.3 降级路径需预先定义
  • 站内检索mute consequences · notification routing · channel transfer

同组卡片

快捷操作

分享

分享当前页面

ios_share

https://hci.top/zh/handbook/D2.11.4