Appearance
模块 7：品味系统构建实践
A taste system is not an artifact — it is a living argument about what excellence looks like in a specific context. Build it as you would build a culture: with clarity, conviction, and room to grow.
学习目标
完成本模块后，你将：
- 整合前六个模块的全部知识——领导力、编码、设计系统、传递、冲突、迭代——为一个真实或假设的组织构建完整的品味系统
- 掌握品味系统构建的七步方法论——从品味审计到品味文档到品味治理
- 理解品味系统不是"一次性项目"而是"持续运作的基础设施"
- 完成 TASTE-401 的综合实践项目
一、什么是品味系统
品味系统的定义
品味系统（Taste System）不等于设计系统（Design System）。设计系统是品味系统的一个组成部分——它编码了视觉和交互层面的品味标准。品味系统更广，它是让一个组织持续产出高品味输出的完整基础设施，包括：
| 组成部分 | 功能 | 对应模块 |
|---|---|---|
| 品味声明（Taste Manifesto） | 定义品味方向——"我们追求什么样的品味" | 模块 1 品味领导力 |
| 品味原则（Taste Principles） | 将品味方向编码为可引用的原则 | 模块 2 编码层次 |
| 设计系统（Design System） | 将品味原则编码为 Token、组件、模式 | 模块 3 设计系统构建 |
| 品味传递机制（Transfer Mechanisms） | 评审流程、导师制、品味词汇库 | 模块 4 品味传递 |
| 品味冲突协议（Conflict Protocols） | 品味分歧的解决流程和权威分配 | 模块 5 品味冲突 |
| 品味迭代机制（Iteration Mechanisms） | 定期审查、版本化管理、刷新计划 | 模块 6 品味迭代 |
关键认识：大多数组织只有"品味系统"中的某些部分——可能有设计系统但没有品味声明，有品味领导者但没有品味传递机制，有品味标准但没有迭代机制。品味系统的价值在于完整性——六个组成部分的协同效应远大于单独存在的效果。
品味系统 vs 品牌规范
品味系统与品牌规范（Brand Guidelines）有交叠但不相同：
| 维度 | 品牌规范 | 品味系统 |
|---|---|---|
| 关注点 | 品牌视觉的一致性 | 所有产出的品味品质 |
| 覆盖范围 | Logo、色彩、字体、图片风格 | 视觉、交互、文案、服务、空间... |
| 编码层次 | 主要在规则层 | 跨越原则→指南→规则→自动化 |
| 谁使用 | 设计师和品牌经理 | 整个组织——设计师、工程师、产品经理、市场人员 |
| 演化频率 | 每 5-10 年大更新 | 持续迭代（补丁版本近乎连续） |
品牌规范是品味系统的子集——它编码了品牌层面的品味，但没有覆盖产品体验、服务体验等更广泛的品味维度。
二、品味系统构建的七步方法论
步骤一：品味审计（Taste Audit）
在构建之前，先理解现状——组织当前的品味状态是什么？
审计维度：
1. 产出品味分析
收集组织最近 6-12 个月的代表性产出（产品界面、营销材料、对外文档、客户沟通...），分析：
- 品味是否一致？不同产出之间是否有清晰的品味关联？
- 品味水平如何？与行业标杆相比处于什么位置？
- 品味盲区在哪里？哪些维度的品味品质明显低于其他维度？
2. 品味决策流程分析
品味决策是如何做出的？
- 谁在做品味决策？是否有明确的品味权威？
- 品味决策的速度如何？是否经常因为品味争论而拖延？
- 品味决策的质量如何？最终产出是否反映了好的品味判断？
3. 品味认知调查
团队成员对品味的理解是什么？
- 如果问每个人"我们的产品品味是什么"，答案一致吗？
- 团队成员是否有共享的品味词汇？
- 团队成员是否知道品味标准在哪里被记录？
品味审计的输出应该是一份品味现状报告——不是判断"好坏"，而是客观描述当前品味系统的状态、优势和差距。
步骤二：品味声明（Taste Manifesto）
品味声明是整个品味系统的锚点——它用简洁有力的语言定义了"我们追求什么样的品味"。
品味声明的三个组成部分：
1. 品味愿景（Vision）
一句话描述品味的终极目标。不是"我们要做好的设计"（这是废话），而是有立场的品味方向声明。
好的品味愿景示例：
- Stripe："Technology that feels as considered as a well-crafted sentence"
- Airbnb："Every touchpoint should feel like being welcomed into someone's home"
- Linear："Software that respects you — fast, precise, out of your way"
注意这些声明的共同特征：它们使用了隐喻或类比来传达品味感觉（"well-crafted sentence"、"welcomed into someone's home"、"respects you"），而不是列举视觉属性。
2. 品味价值排序（Value Hierarchy）
当品味价值之间冲突时，哪个优先？
示例：
1. 清晰 > 美观 — 如果在可理解性和视觉精致之间必须选择，选择可理解性
2. 克制 > 完整 — 如果在展示更多信息和保持界面呼吸感之间选择，选择呼吸感
3. 一致 > 创新 — 在核心交互中选择一致性，在品牌表达中选择创新品味价值排序的力量在于它处理了品味冲突中最难的问题——不是"什么是好的"，而是"当两个好的东西冲突时选哪个"。
3. 品味反面定义（What We Are Not）
明确品味的边界——"我们的品味不是什么"。
示例：
- "我们不是极简到冰冷——我们的克制始终保持温暖"
- "我们不是为了不同而不同——我们的差异化来自对问题的更深理解，不是来自视觉噱头"
- "我们不牺牲功能可发现性来追求视觉整洁——如果用户找不到功能，再美的界面也失败了"
反面定义通常比正面定义更有指导力——因为大多数品味错误不是"方向错了"而是"走过头了"。
步骤三：品味原则编写（Taste Principles）
将品味声明具体化为 5-7 条可在日常品味决策中引用的原则。
好的品味原则的标准（参考模块 2）：
| 标准 | 说明 | 反例 |
|---|---|---|
| 有立场 | 选择了一个方向，而非面面俱到 | "我们重视好的设计"（没有立场） |
| 可判断 | 面对具体决策时可以引用来做判断 | "我们追求卓越"（太模糊无法判断） |
| 有张力 | 每个原则排除了一个合理的替代方向 | "我们的产品应该好用"（没有张力——没有人会主张产品应该难用） |
| 可记忆 | 简洁到团队成员能记住并随时引用 | 超过两句话的原则通常记不住 |
| 有示例 | 附带正例和反例来锚定抽象的原则 | 纯抽象的原则缺乏可操作性 |
品味原则的编写过程：
- 收集团队中所有人对"我们的品味是什么"的描述——文字、关键词、参照产品
- 提炼共性——哪些品味价值被反复提及？
- 识别分歧——哪些品味维度上存在不同的看法？
- 起草 7-10 条候选原则
- 用"张力测试"筛选——去掉没有张力的原则（没有人会反对的原则没有价值）
- 精炼到 5-7 条
- 为每条原则添加正例和反例
步骤四：设计系统搭建（Design System）
将品味原则编码为 Token、组件和模式。（详见模块 3，此处聚焦于品味系统语境下的考量。）
与品味声明的对齐检查：
设计系统中的每一个品味决策都应该可以追溯到品味原则。例如：
品味原则："清晰 > 美观"
→ Token 决策：正文字号不低于 16px（可读性优先）
→ 组件决策：按钮文案始终可见，不使用仅图标按钮
→ 模式决策：表单验证错误信息在字段旁边即时显示，不集中到顶部这种追溯关系确保了设计系统不只是"看起来不错的组件"——而是品味原则的系统化体现。
步骤五：品味传递机制设计（Transfer Mechanisms）
设计让品味标准在团队中传播和内化的机制。（详见模块 4。）
最低可行的品味传递机制包括：
- 品味入职（Taste Onboarding）——新成员入职时花 1-2 天时间阅读品味声明和原则、浏览品味参照库、与品味导师进行一次一对一对话
- 周度设计评审（Weekly Critique）——每周 30-60 分钟的品味对话，遵循模块 4 的评审方法论
- 品味参照库（Taste Reference Library）——持续更新的内外部品味参照集合，用具体作品锚定抽象原则
步骤六：品味冲突协议（Conflict Protocols）
制定品味分歧的解决流程。（详见模块 5。）
最低可行的品味冲突协议包括：
- 升级路径——品味冲突在什么层级解决？设计师之间的冲突由设计负责人仲裁；跨职能的冲突由产品负责人仲裁；涉及品牌方向的冲突由品味声明仲裁
- 仲裁规则——仲裁者必须解释理由；裁定后的不同意见被记录但不继续争论；裁定结果可以在下次品味审查中被挑战
- 品味否决权的分配——谁有权在品味问题上说"不"？在什么范围内？
步骤七：品味迭代机制（Iteration Mechanisms）
设计品味标准的自我更新能力。（详见模块 6。）
最低可行的品味迭代机制包括：
- 季度品味审查——每季度回顾品味标准的执行效果，识别老化信号
- 品味变更日志——记录所有品味标准的变更及原因
- 年度品味大审查——每年一次对品味声明和原则的根本性审视——它们是否仍然反映组织的品味方向？
三、品味系统构建的常见陷阱
陷阱一：完美主义陷阱
试图在发布前把品味系统做到完美——结果是系统永远在"建设中"，没有人在使用它。
对策： 品味系统的第一版应该是"最小可行品味系统"（Minimum Viable Taste System）——只包含品味声明、3-5 条原则、核心 Token 和最关键的组件。先让它运转起来、被使用、被检验，然后迭代完善。
一个被使用的 60 分品味系统远好于一个永远在建设的 95 分品味系统。
陷阱二：孤岛陷阱
品味系统只被设计团队理解和使用，工程师、产品经理、市场人员不知道它的存在或不理解它的价值。
对策： 品味系统的受众不是设计师——是整个组织。品味声明应该在全公司分享；品味原则应该使用非设计专业人士也能理解的语言；设计系统应该有面向开发者的文档。
Shopify 的 Polaris 设计系统是一个好的参考——它不只是给设计师用的组件库，还包含面向开发者的实现指南、面向内容创作者的文案指南、面向所有人的设计原则。
陷阱三：遗忘陷阱
品味系统被创建后没有人维护——品味声明变成了没人看的文档，设计系统的组件逐渐与实际产品脱节，评审流程在几个月后无人组织。
对策： 品味系统需要一个"所有者"——一个人或一个小团队的明确职责包括维护品味系统。这个所有者不需要全职投入，但品味系统的健康必须是他们的 KPI 之一。
陷阱四：过度正式化陷阱
品味系统变成了繁重的官僚流程——每个品味决策都需要层层审批，每个组件变更都需要委员会讨论。
对策： 品味系统的"重量"应该与组织规模匹配。20 人的团队不需要品味委员会——一个品味领导者加一份品味文档可能就够了。200 人的组织需要更正式的治理，但仍然要保持决策的敏捷性。
判断品味系统是否过度正式化的信号： 如果团队成员开始绕过品味系统（而不是通过它）来做品味决策——说明系统的阻力超过了它的价值。
四、真实案例：品味系统的运作
案例分析：Linear 的品味系统
Linear（项目管理工具，由 Karri Saarinen 联合创立，2019-）是近年来品味系统运作最出色的科技公司之一。它的品味系统虽然没有被正式称为"品味系统"，但其运作方式完整地体现了本课程讨论的所有维度。
品味声明（非正式）： "Software crafted for the people who build products" — 品味方向是面向专业人士的工匠精神。
品味原则（从产出推断）：
- 速度即品味——Linear 的界面响应速度极快（键盘操作在 50ms 内完成），性能被视为品味的核心维度
- 密度而非简单——面向专业用户的界面可以信息密集，但必须层次清晰
- 键盘优先——专业工具应该支持不碰鼠标的完整操作
- 动效节制——只在有功能目的的地方使用动效，绝不为了"酷"
设计系统： Linear 的设计系统在视觉上极度一致——暗色主题、Inter 字体（后替换为自定义字体）、紧凑的间距、微妙的颜色区分。每一个组件都反映了"专业工具"的品味立场。
品味传递： Linear 团队很小（截至 2024 年约 80 人），品味传递主要通过小团队的密切协作和创始人 Karri Saarinen（前 Airbnb 设计系统负责人）的直接参与。这是 Ive 模式的工坊传递——在小规模下极其有效。
品味迭代： Linear 的品味迭代是渐进式的——每次更新都是微调而非大幅改变。这反映了他们的品味已经稳定，当前的品味方向是正确的，不需要激进转变。
品味冲突： 在 Linear 的公开讨论中，Saarinen 提到过工程和设计之间关于性能和视觉丰富度的平衡——他的立场是"如果一个动效导致了可感知的延迟，去掉它"。这是一个清晰的品味价值排序（速度 > 视觉表现力），减少了冲突的频率。
五、综合实践项目
TASTE-401 毕业项目：构建品味系统
项目要求：
为一个真实或假设的产品/品牌/组织构建一套品味系统。这个品味系统应该包含以下全部组成部分：
交付物一：品味审计报告（Taste Audit）
- 分析目标组织当前的品味状态
- 识别品味优势和差距
- 建议品味系统的优先建设方向
交付物二：品味声明（Taste Manifesto）
- 品味愿景（一句话）
- 品味价值排序（3-5 条排序规则）
- 品味反面定义（"我们不是什么"）
交付物三：品味原则（Taste Principles）
- 5-7 条品味原则
- 每条原则附带正例和反例
- 原则之间的关系说明
交付物四：设计系统概要（Design System Outline）
- Token 体系设计（色彩、间距、字体、圆角的品味逻辑）
- 3-5 个核心组件的品味决策说明
- 与品味原则的对齐检查
交付物五：品味运作方案（Taste Operations）
- 品味传递机制——评审流程、入职流程、参照库
- 品味冲突协议——升级路径、仲裁规则
- 品味迭代机制——审查周期、版本管理
选择你的目标组织：
你可以选择：
- 你当前所在的组织或团队
- 你正在开发的个人项目
- 一个你感兴趣的假设组织（例如：一个面向创意人士的 AI 工具、一个本地精品咖啡品牌、一个面向老年人的健康管理 App）
如果选择假设组织，请在品味审计部分详细描述组织的背景、用户群和品味语境。
设计系统/组织实践
Shopify Polaris 作为品味系统
问题：Shopify 的 Polaris 设计系统被认为是最完整的品味系统之一——它不只是组件库，还包含设计原则、内容指南、可及性标准、甚至商家体验研究。分析 Polaris 作为品味系统的完整性：它在哪些方面做得好？哪些方面仍有缺失？它的品味立场是什么？
分析：Polaris 的完整性在设计系统中是罕见的。品味声明层面：Polaris 有明确的品味方向——'build confidently for commerce'，定位为让商家（不是设计师）能够自信地构建店铺。品味原则层面：Polaris 有清晰的设计原则（Put merchants first / Empower but don't overwhelm / Be consistent but not rigid / etc.），且每条原则有具体的应用指导。设计系统层面：Token 体系完整、组件丰富、文档极其详尽（包括 Do/Don't 示例）。传递机制层面：Polaris 有面向不同角色的指南（设计师版、开发者版、内容创作者版）。品味迭代层面：Polaris 有公开的变更日志和版本迁移指南。缺失之处可能在于：(1) 品味冲突协议——Polaris 没有公开的品味分歧解决机制；(2) 品味声明的情感维度——Polaris 的品味立场偏功能性（让商家成功），在情感体验的品味维度上编码较弱；(3) Polaris 为了覆盖极大的商家多样性而做了较多妥协——品味方向可能不够锐利。
品味系统完整性评估
以下描述了不同组织的品味系统状态。评估每个系统的完整性和有效性，然后查看分析。
样本 A
样本 B
样本 C
样本 D
品味系统规模比较
个人品味系统
适用于独立设计师或小型自由职业者。核心组成：个人品味声明（1 页）、品味参照库（持续更新的 Moodboard）、作品自评习惯。不需要正式的传递机制（没有团队）或冲突协议（没有冲突对象）。重点在品味的自我认知和持续校准。
小团队品味系统（5-20 人）
适用于创业公司或小型工作室。核心组成：品味声明 + 3-5 条原则、轻量设计系统（Token + 核心组件）、周度品味对话、品味领导者直接参与。不需要复杂治理或正式的冲突协议——小团队的品味对齐主要通过直接对话实现。
中型团队品味系统（20-200 人）
适用于成长期公司。核心组成：完整的品味声明和原则、正式的设计系统（Token + 组件 + 模式）、结构化的评审流程、品味冲突升级路径、半年度品味审查。需要品味守门人角色和明确的治理模式。
大型组织品味系统（200+ 人）
适用于大型科技公司或跨国品牌。核心组成：全部六个组成部分的正式化版本、联邦制或中央集权的治理模式、品味系统团队（3-10 人全职）、自动化品味检查工具、品味变更日志和版本管理。挑战在于保持品味的活力不被官僚化消磨。
思考：你的毕业项目目标组织属于哪个规模？你会如何根据规模调整品味系统的复杂度？
TASTE-401 毕业项目：品味系统设计
60-90 minutes为你选择的目标组织设计一套品味系统。这是 TASTE-401 的综合实践项目——它应该整合你在全部七个模块中学到的知识。提交一份品味系统设计文档。
建议结构：
品味审计~15%
描述目标组织的背景和当前品味状态。如果是假设组织，描述其背景、用户群和品味语境。如果是真实组织，分析其产出品味、决策流程和品味认知。
品味声明~15%
品味愿景（一句话）+ 品味价值排序（3-5 条）+ 品味反面定义（我们不是什么）。确保品味声明有立场、有张力——不是放之四海而皆准的废话。
品味原则~20%
5-7 条品味原则，每条附带正例和反例。原则之间应有层次和互补关系，而非随机列举。
设计系统概要~20%
Token 体系的品味逻辑（为什么选择这些颜色/间距/字体）、3-5 个核心组件的品味决策说明、与品味原则的对齐检查。
品味运作方案~20%
传递机制（评审/入职/参照库）+ 冲突协议（升级路径/仲裁规则）+ 迭代机制（审查周期/版本管理）。根据组织规模调整复杂度。
自我评价~10%
你对这个品味系统设计最满意什么？最不确定什么？如果有三个月的时间来实际实施，你会先做什么？
- 品味系统设计不是理论推演——想象自己明天就要把它交给团队使用
- 品味声明是最重要的部分——如果声明不清晰，后续的所有部分都会失焦
- 不要试图做到完美——一个有明确立场和清晰原则的不完美品味系统，比一个面面俱到但立场模糊的系统有价值得多
- 品味运作方案应该是你最花时间思考的部分——品味系统的成败取决于运作而非文档
- 如果你对目标组织足够了解，品味审计会自然地引导出品味声明的方向
- 在写品味原则时不断问自己：如果一个完全不了解这个组织的人读了这些原则，他能做出正确的品味判断吗？
目标：600 字
延伸阅读
必读
Alla Kholmatova, Design Systems: A Practical Guide to Creating Design Languages (2017)
- 本模块综合实践的最佳参考——从品味原则定义到设计系统实现的完整方法论
Marty Cagan, Empowered: Ordinary People, Extraordinary Products (2020)
- 第三部分"Product Teams"讨论了产品组织中的品味权威如何分配——对品味运作方案的设计有直接帮助
推荐
Kim Goodwin, Designing for the Digital Age: How to Create Human-Centered Products and Services (2009)
- 850 页的巨著，但 Chapter 6-8 关于设计原则和设计语言的章节对品味系统构建有极高参考价值
Hayden Pickering, Inclusive Design Patterns (2016)
- 提醒品味系统必须包含无障碍维度——品味不能以排除为代价
Shopify Polaris — 最完整的公开品味系统之一，作为毕业项目的参考标杆
在线资源
- Design Systems Repo — 公开设计系统的合集
- Figma Design Systems Collection — 搜索 "design system" 浏览公开的 Figma 设计系统文件
- adele - Design System Repository — 按组件类型、技术栈分类的设计系统目录
本模块要点
- 品味系统 = 品味声明 + 品味原则 + 设计系统 + 传递机制 + 冲突协议 + 迭代机制——六个部分的协同效应远大于任何单独部分
- 品味审计是构建品味系统的第一步——先理解现状，再设计目标
- 品味声明需要有立场——"我们重视好的设计"不是品味声明，"速度即品味"才是
- 品味价值排序处理最难的问题——不是"什么是好的"而是"当两个好的东西冲突时选哪个"
- 品味反面定义通常比正面定义更有指导力——因为大多数品味错误是"走过头了"
- 品味系统的第一版应该是"最小可行"的——先让它运转，然后迭代完善
- 品味系统的受众是整个组织而非设计团队——语言和文档应该跨职能可理解
- 品味系统需要一个所有者——没有明确的维护责任，系统会被遗忘
- 品味系统的"重量"应与组织规模匹配——20 人的团队不需要品味委员会
- 品味系统的成败取决于运作而非文档——再好的品味声明如果没有传递机制和迭代机制也只是纸面文件
下一步
你现在拥有了品味领导力和编码的完整工具箱。TASTE-401 教你如何让品味从个人能力变为组织能力——从领导力到编码到系统到传递到冲突管理到持续迭代。下一门课 TASTE-402 是整个品味学院的终点——毕业设计。你将整合四个学期的全部训练，完成一个展示你品味能力的综合项目。
TASTE-401 总评
基于你在 TASTE-401 全部七个模块中的学习和综合实践项目，对自己做一次全面评估。这是课程级别的总评——它应该反映你在整门课程中的品味领导力和编码能力的成长。
品味领导力意识对品味领导力本质、模式、信任建设的理解和实践
品味编码能力将品味判断编码为可传递形式的能力（原则、指南、系统）
品味系统设计设计完整品味系统（声明+原则+系统+运作）的能力
品味对话能力在品味传递、冲突解决、迭代决策中的对话和论证能力
品味迭代意识对品味时间性和品味演化的理解
综合实践项目TASTE-401 毕业项目的整体品质