克制：给颜色和字体做预算
一个主色、两种字重、一套圆角。往界面里加颜色看它变成年会海报，再一键做减法，感受高级感回来的瞬间
本页解决的问题
先给结论「克制：给颜色和字体做预算」要解决的关键问题是什么？
一个主色、两种字重、一套圆角。往界面里加颜色看它变成年会海报，再一键做减法，感受高级感回来的瞬间
把品味变成产品可重复的行为。 有用的结果不是一句“我觉得更好”。它应该是一条看得见的规则、一个小例子，以及判断体验何时低于标准的方法。
记录一个前后对比，让别人不用听解释也能看懂质量线。
表面更精致了，却没有减少用户的不确定感。
预算制的规则很短：一个主色，其余交给黑白灰的中性色；两种字重，正文一档强调一档；一套圆角，定一个数处处沿用。想加第二种彩色时，先问自己一句「它值不值得动预算」，多数时候答案是省下来。
下面是一张克制版的活动页。连点五次「再加一种颜色」，看它一步步劣化；点满五次后，再一键做减法。
加色器演的是怎么变丑，减法游戏演怎么救回来。《About Face 4》给过一个可执行的办法：删减东西，直到删掉某件破坏了设计为止，再把最后删掉的那件加回来。下面这张促销卡堆了六件装饰，逐件点掉试试，哪件删了页面就破，你自然会知道。
克制还有一条更细的纪律，管的是「差不多」。《About Face 4》把话说得很重：不必要的差异是一致设计的大敌。两个间距几乎一样，就调成同一个数；两种颜色几乎一样，就用同一个。每处差异的存在都要有理由，找不出理由，就消除它。下面这张卡藏着三处「差不多」，切换看收编前后。
颜色预算管的是「几种」，饱和度管的是「多响」。《About Face 4》提醒过：高饱和的颜色个个都在喊，凑在一起就是嘉年华效应，用户会被吵得不堪重负。同样三个标签，把饱和度当音量键推推看。
这回把三笔预算做成开关，任意组合，右下角的徽标实时告诉你超没超支。
预算制三条：一个主色加中性色、两种字重、一套圆角。想突破预算，先问值不值。
每多一种颜色，已有的颜色都在贬值。做减法比做加法更常出效果，删颜色是性价比最高的一步。
觉得页面廉价，按顺序查：先数彩色有几种，再数字重有几档，最后看圆角统不统一。
两条可执行的纪律：差不多一样就做成一模一样；拿不准要不要留，就删到破坏为止，再把最后删掉的那件加回来。
内容来源：newwebplay AI「审美工程」专题原创；「不必要的差异是大敌」「删减到破坏为止」等设计原则整理自《About Face 4：交互设计精髓》第 17 章（Alan Cooper 等）。
从「先给颜色和字体定个预算」把感觉变成判断
「预算制的规则很短： 一个主色 ，其余交给黑白灰的中性色；」指出，AI 降低了做出“能用”成品的门槛，读者真正需要练的是看出哪里不对，并把感觉说成可以执行的要求。
观察用户的下一步，而不是只看表面
「下面是一张克制版的活动页。连点五次「再加一种颜色」，看它一步步劣化；点满五次后，再一键做减法」可以转成几个可观察的问题：用户是否知道现在发生了什么，是否知道下一步做什么，出错或空白时能否恢复，以及信息层级是否让重要内容先被看见。
漂亮不等于容易用
把「两条可执行的纪律： 差不多一样就做成一模一样；拿不准要不要留，就删到破坏为止，再把最后删掉的那件加回来」用在第二个页面或流程上，记录一个具体犹豫点和一个改动后的用户动作；能被观察到的变化，才是体验改善。
从「先给颜色和字体定个预算」走到「亲手把一张页面做丑」
「先给颜色和字体定个预算」先把问题落在「预算制的规则很短： 一个主色 ，其余交给黑白灰的中性色； 两种字重 ，正文一档强调一档； 一套圆角 ，定一个数处处沿用。想加第二种彩色时，先问自己一句「它值不值得动预算」，多数时候答案是省下来」上；到了「亲手把一张页面做丑」，讨论继续推进到「下面是一张克制版的活动页。连点五次「再加一种颜色」，看它一步步劣化；点满五次后，再一键做减法」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
评估体验时，把抽象的“好看”或“顺手”换成用户动作：他是否看懂状态、找到了下一步、能从错误中恢复，并且愿意继续使用。
- 「先给颜色和字体定个预算」：预算制的规则很短： 一个主色 ，其余交给黑白灰的中性色； 两种字重 ，正文一档强调一档； 一套圆角 ，定一个数处处沿用。想加第二种彩色时，先问自己一句「它值不值得动预算」，多数时候答案是省下来
- 「亲手把一张页面做丑」：下面是一张克制版的活动页。连点五次「再加一种颜色」，看它一步步劣化；点满五次后，再一键做减法
- 「最后的要点」：觉得页面廉价，按顺序查： 先数彩色有几种，再数字重有几档，最后看圆角统不统一
最后的「最后的要点」把讨论落到「觉得页面廉价，按顺序查： 先数彩色有几种，再数字重有几档，最后看圆角统不统一」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。