H5.09.2over-fine notification categories become a setting burden设计研究
分类粒度过细会让设置界面本身变成负担
别名: 分类过细 · 设置过载 · channel explosion
概念解释
类型太细——按每一个活动、每一个话题、每一个内部事件名各做一只开关——设置页本身变成一次分类劳动。人看不懂差别，就不配，然后在被烦时一键全关。粒度的用处是让取舍便宜；过细把取舍变成编制目录。
这条管「细到什么程度就不值得」。它不否定按类型开关优于总开关，也不谈新类型该默认关。
机制
每只开关都要占用：读名字、想象会来什么、决定开还是关、记住这个决定。工作记忆一次只能稳住有限几项，列表一长，策略就变成不碰或全关。过细还制造无法从到达反推的名字：人收到一张卡，无法指出它属于 40 只开关里的哪一只，现场退订也对不上去。
工程上过细来自把内部事件总线直接暴露成通道。总线的基数是开发方便，不是人的心智类别。人的类别大约是「谁在找我 / 我的钱和订单 / 安全 / 社交噪音 / 推销」。超出这个量级，就要合并，而不是再加一只。
怎么研究
把同一到达集合映射到 4、12、40 只开关，看完成配置的时间、事后能否把一张新卡对回正确开关、以及最终是否改用总关。
自变量：开关数量、命名是否用人的任务还是内部事件、是否分组。 因变量：配置完成率、对回正确率、放弃配置改走总关的比例。
实验室里「请把这些都设好」会高估耐心。更硬的是给一个与通知无关的主任务，设置是可选的。不要用「开关被打开的数量」当参与度——过细时人可能随机开着默认，测到的是惰性，不是同意。
边界
专业运维控制台本来就要上百条规则，操作者是在编规则而不是在「订阅」，不能用消费设置页的粒度上限去砍。无障碍用户用线性导航走完 40 只开关的代价更高，过细对他们先变成不可达。操作系统自己的通道列表若已经很长，应用再叠一层等于双倍负担。
怎么落地
- 把内部事件收成少数以用户任务命名的类型；需要更细时，做成某类型下的二级，默认不要把二级铺在首页。
- 一只开关要对得上人能指认的到达样本；对不上就合并。
- 设置页先给 5 只左右的主类型，进阶再展开。
- 验证：把最近 20 张真实通知发给未参与设计的人，问「关掉哪一只能停这张」。对不上或要猜，就合并那些开关。若设置页要滚动一屏以上才看到事务类，粒度已经在惩罚取舍。