设置页面问题

设置页面是你产品里最诚实的一屏。只需滚动一次,它就能告诉你团队究竟拒绝做了哪些决定。每一个开关都是一场被固化的争论。每一层嵌套标签页,都是一句“以后再想”,而且从来没人想过。

大多数设置页面都是垃圾填埋场。三年的开关,堆砌自不会说不的工程师、需要退订选项的市场人员,以及把“做成可配置”当作“做决定”替代品的产品经理。结果是一个团队不好意思演示、用户不敢乱碰的页面。

这篇文章主张把设置当作一等产品界面来对待。五种原型、六条规则、来自你每天都在用的产品的真实案例,以及上线前该跑一遍的审查清单。

设置页面会暴露整个团队

设置膨胀是组织失调的领先指标。 团队无法就默认值达成一致,开关就上线了。客户抱怨而没人想顶回去,开关就上线了。产品经理在两种流程之间拿不定主意,两种都会藏在一个设置后面上线。

六个月后,没人记得一半的开关为什么存在。删除一个设置,需要做团队当初回避的同一个决定,于是它们越积越多。看看任何一个上线超过三年的产品,你都能在设置树里数出那些没做的决定。

糟糕设置页面的五种原型

糟糕的设置页面并非随机产生。它们落入五种模式,每一种都是某种组织惰性的终点。

1. 垃圾堆

按时间顺序堆积。设置按添加顺序出现,从不分组。最新的功能开关紧挨着一个 2019 年的通知偏好,再旁边是本该两年前转正的测试版开关。Cursor 正在滑向这里。每次发布都往“通用”标签页里加三个开关,如今“通用”页已经是 40 行互不相干决定的长卷轴。垃圾堆是任何没人认真设计的设置页面的默认状态。

2. 电子表格

按字母排序的偏好项。团队放弃了层级,让系统去排序。每个开关权重相同,每一行长得一模一样。Slack 的通知偏好就住在这里。声音、角标、移动端、频道、关键词、勿扰、日程、自定义,全部被压成一堵墙,没有任何叙事说明哪些才重要。

3. 死胡同

改了却毫无可见变化的设置。用户打开“紧凑模式”,屏幕看起来一模一样。打开“启用高级功能”,什么也没出现。macOS 上 Apple 重新设计的“系统设置”就带来了一整代这样的东西:被其他设置悄悄覆盖的设置,需要重启而界面从不提及的设置。死胡同教会用户设置没用,于是他们也不再信任产品的其余部分。

4. 迷宫

十层嵌套标签页。设置被埋在类别、子类别、“高级”折叠区、弹窗之下。用户知道这个开关存在,以前也切换过,却还是找不到。老版 Jira 就靠这个吃了一辈子饭:项目、看板、工作流、方案、权限方案、通知方案,全是各自独立的树。

5. 博物馆

三年没人碰过的设置。它们存在,只因为删掉感觉有风险。它们指向 2023 年就已下线的功能。每个老牌 SaaS 产品都有一座博物馆侧厅,代价是团队承诺维护那些两次重构前就该杀掉的代码路径。

设置是产品界面,不是储物间

大多数团队把设置当作产品其余部分收拾残局的地方。这种看法本身就是 bug。设置是产品中杠杆率最高的界面之一,最强的团队也正是这样设计它的。

设置表达了产品对用户的世界观。它同时传达四件事:团队有多信任用户;团队愿意分享多少控制权;团队认为正确的默认值是什么;团队是否足够尊重用户的时间,为那 5% 会改默认值的人做设计,同时不惩罚那 95% 不改的人。

Linear 把设置设计成单一的搜索界面,由 command-K 驱动,几乎没有嵌套标签页。潜台词是:用户很能干,搜索很快,层级的活团队已经干完了,用户不必再干。Notion 走了相反的路,同样赢了。设置就放在它所影响的东西旁边。页面设置在页面上。数据库设置在数据库上。情境化设置消融在工作之中。

Vercel 使用有作用域的层级:项目、团队和账户,各自标注清晰,各自限定在所管辖的资源上。Stripe Dashboard 走行动导向路线,每个界面都是“去做这件事”,而不是“配置这个偏好”。GitHub 的仓库设置把作用域做得干净利落,仓库、组织和账户的归属清晰分离。

决定每个设置页面成败的六条规则

这些规则会产生复利。六条命中五条,页面读起来就是一个产品界面。只命中三条,一年内它就会滑进某种原型。

规则 1:搜索优先

层级是兜底,不是首选。用户先知道设置的名字,才知道它在哪个标签页下。Linear 的 command-K 把设置当作一等结果类型。Figma 加入设置搜索后,切换开关所需的时间立刻下降。如果你的设置页面没有搜索栏,你就是在赌用户会背下你的信息架构。他们不会。

规则 2:情境化放置优于中央注册表

设置放在它所影响的东西旁边。通知设置放在通知面板里。页面设置放在页面上。中央设置页面只适合账户级事务,比如个人资料、账单和会话,其他几乎都不适合。Notion 是黄金标准。Figma 的右侧栏对图层、画框和组件属性也起着同样的作用。

规则 3:赢得信任的合理默认值

每个默认值都是一个产品决策。它表达的是团队认为对 80% 用户正确的答案。如果默认值是错的,开关就只是创可贴。Slack 的通知默认值假定你希望被联系到,而不是保持静默。这个赌注对中位用户是正确的。大多数团队先设计开关,让默认值自然冒出来。这个顺序是错的。

规则 4:渐进式披露优于平铺膨胀

用户应该看到 90% 用户在意的那五个设置。其余 50 个放在深一层,藏在清晰的“高级”入口后面。Vercel 的项目设置把这点做到了位。第一屏展示域名、环境变量和部署保护。构建覆盖、函数配置和重写规则都放在“高级”里。

规则 5:不留孤儿

每个设置都属于某个分组。每个分组都有名字。孤儿测试:脱离任何上下文,把任意一个标签大声读出来。如果你团队里的设计师说不清这个开关是干什么的,它就是孤儿。孤儿是博物馆的幼苗。

规则 6:每个设置都要挣到自己的位置

设置是一份合同。团队承诺永远维护它、记录它、测试它,并推演它与其他所有设置的相互作用。大多数设置付不起这笔租金。任何新设置的默认态度都应该是“不”。好团队砍掉的设置比上线的更多。

暗示更深层问题的反模式

有三种模式,杀死的设置页面比其余所有加起来还多。每一种都是症状:问题不在屏幕,而在屏幕背后的团队。

把设置当作产品决策的替代品。 团队无法就默认开启还是默认关闭达成一致,于是做成了开关上线。用户继承了这场没解决的争论。如果你在站会上听到“我们做成可配置吧”,你就正在目睹这种反模式成形。更深入的解读见有意设计摩擦。

用设置弥补糟糕的设计。 因为默认密度太松,所以加一个“紧凑模式”开关。因为品牌色过不了无障碍标准,所以加一个“高对比度”开关。因为改版被否决,所以加一个“经典视图”开关。每一个都是真正的修复,只是披上了选项的外衣。正解是一开始就把密度、对比度和视图设计对。

没人能用一句话讲清的设置。 如果设计师说不清这个设置做什么、切换后什么会变、是给谁用的,它就不该上线。任何新开关进入代码库之前,先跑一遍这个测试。

设置页面审查

让每个设置页面都过一遍这七个问题。七问里没有六个能自信地回答“是”,页面就没做完。

1. 用户能在五秒内找到任何一个设置吗? 如果不能,说明页面缺少搜索,或者层级坏了。
2. 每个设置都有一句非工程师也能看懂的描述吗? 如果标签需要工程师来解释,它就不属于产品界面。
3. 切换开关会产生可见、即时的效果吗? 隐藏的状态变化是信任杀手。
4. 设置是按用户任务分组的,而不是按功能团队分组吗? 按哪个团队负责功能来组织的页面,是泄漏进产品的内部产物。请按用户目标分组。
5. 默认值在某处有书面依据吗? 团队应该能指出一份文档、一个视觉层级决策,或一条品牌原则。如果默认值是“工程师在冲刺期间随手设的”,页面就没做完。
6. 你能在用户毫无察觉的情况下删掉一半设置吗? 如果能,就删。博物馆比团队想象的更沉重。
7. 页面的外观和感觉与产品其余部分一致吗? 把它和你的落地页设计原则放在一起看。如果品牌一塌糊涂,设置页面就是脱离品牌的。

每年跑两次这份审查的团队,交付的设置界面不会让用户皱眉。从不跑的团队,交付的设置页面迟早成为竞争对手的招聘工具。

先定原则,再修剪页面

设置是团队的世界观,被冻结在一个个开关里。好团队把这个页面当作一等流程,投入的工艺与对待新手引导、仪表盘和营销网站一样。

修复设置页面最快的方法不是重新设计,而是删掉一半。删掉每一个过不了孤儿测试、一句话测试和“挣得位置”测试的设置。剩下的,就是真正设置界面的脊梁。

它与空状态的联系并非偶然。这两种屏幕都揭示了:当屏幕上没有别的东西分散注意力时,团队究竟相信什么。同样的纪律也体现在网页设计原则中。

常见问题

一个产品应该有多少个设置?

越少越好。每个设置都是团队要永远维护的合同。任何新设置的默认态度都应该是“不”。如果团队无法用一句话为这个设置辩护、说出它服务的用户、描述它切换时有什么可见变化,这个设置就不该上线。

设置应该放在产品的哪里?

放在它所影响的东西旁边,而不是集中的设置侧厅里。页面设置在页面上。工作区设置在工作区里。通知设置在通知面板里。中央设置页面只适合账单、个人资料和会话这类账户级事务,其他几乎都不适合。

如何清理一个积累了多年开关的设置页面?

先跑审查,再删除。按用户任务给每个设置分组。找出孤儿、死胡同和博物馆展品。第一轮先删掉末尾 30%,然后观察支持工单。如果没人抱怨,再删 20%。

像设计首页一样设计设置页面

设置页面不是地下室。它是你的重度用户生活的房间,也是新用户评判你的地方。把它当作首页、新手引导、仪表盘来对待。投入同样的工艺。以同样的信念交付。

如果你想要一个像设计产品其他部分那样设计设置页面的团队,而不是从待办清单里继承它,聘请 Brainy。我们把设置设计成一等流程,用纪律让页面保持小巧,让每个开关都付得起自己的租金。