2009 年，David Siegel 受 Canonical 创始人 Mark Shuttleworth 邀请，加入 Ubuntu 的第一支设计团队，目标是让 Linux 变得更美。十六年后，这段经历重新引起关注，其中最值得工程团队警惕的画面，不是某个具体动画做得好不好，而是一群资深 Debian 参与者坐在会议室里，用投票决定启动器动画应该长什么样。
这不是在嘲讽社区治理。投票适合分配资源、确认规则和处理利益冲突，但它未必适合产生连贯的视觉语言。设计一旦被拆成许多可以逐项表决的偏好，最终结果通常不是“大家都满意”，而是每一种立场都留下了一点痕迹。
投票能形成共识，却不一定形成作品
启动器动画看似只是一个局部效果，实际上会同时影响响应感、品牌气质、操作反馈和性能预期。有人希望动画更明显，有人要求更快，有人偏爱克制，还有人认为动画本身就不必要。把这些意见放进票箱，最容易得到的是折中值，而不是明确方向。
工程决策与设计决策在这里存在一个关键差异：
- 工程方案经常可以通过正确性、复杂度、延迟和资源占用来验证。
- 设计方案也受可访问性、性能和一致性约束，但在多个合格方案之间，仍然需要判断力。
- 多数票可以说明哪个方案更受当前参会者欢迎，却不能证明它更符合目标用户、产品定位或整体设计系统。
所谓“品味死在投票箱里”，并不是说设计师应该拥有不受约束的权力，而是说团队不能把审美责任伪装成集体表决。十个人共同投票，不等于十个人共同承担最终体验。
真正的问题是决策权没有绑定责任
开源项目天然重视参与、公平和透明，这些价值没有错。问题出现在团队把“每个人都可以提供意见”误写成“每个人都应该拥有同等设计决定权”。
更可执行的分工是：开放收集证据，由明确的设计负责人作出选择，再由工程、可访问性和性能负责人检查边界。设计负责人必须解释决策，也必须对结果负责；其他参与者可以挑战依据，但不直接用个人偏好覆盖产品目标。
一次设计评审至少要分清三类信息：
- 硬约束：动画不能引发明显眩晕，不能阻塞操作，也不能突破性能预算。
- 用户证据：用户是否看懂状态变化，是否误以为程序没有响应。
- 方向判断：产品应该显得迅速、安静，还是富有表现力。
前两类可以测试，第三类需要授权明确的人作出取舍。把三者混在一次举手表决里，讨论就会退化成偏好统计。
可以这样实践：用决策记录代替审美公投
下面是一个最小示例。它不是 Ubuntu 当年的真实流程，而是一种可改造的团队实践：硬约束拥有否决权，加权评分只负责整理证据，最终决定仍由指定负责人签署。
运行前，可修改 constraints、weights 和各候选方案的评分。将以下内容保存为 design_review.py，然后执行 python3 design_review.py：
from dataclasses import dataclass
constraints = {
"reduced_motion_supported": True,
"max_duration_ms": 250,
}
weights = {
"clarity": 0.40,
"consistency": 0.30,
"performance": 0.20,
"delight": 0.10,
}
@dataclass
class Proposal:
name: str
duration_ms: int
reduced_motion_supported: bool
scores: dict[str, int]
proposals = [
Proposal("instant", 0, True, {
"clarity": 7, "consistency": 8, "performance": 10, "delight": 4,
}),
Proposal("subtle-scale", 160, True, {
"clarity": 9, "consistency": 9, "performance": 8, "delight": 7,
}),
Proposal("bounce", 420, False, {
"clarity": 8, "consistency": 5, "performance": 5, "delight": 9,
}),
]
def evaluate(proposal: Proposal) -> tuple[str, float | None]:
if proposal.duration_ms > constraints["max_duration_ms"]:
return "BLOCKED: duration exceeds budget", None
if constraints["reduced_motion_supported"] and not proposal.reduced_motion_supported:
return "BLOCKED: reduced-motion mode missing", None
total = sum(proposal.scores[key] * weight for key, weight in weights.items())
return "ELIGIBLE", round(total, 2)
for proposal in proposals:
status, score = evaluate(proposal)
print(f"{proposal.name:14} {status:40} score={score}")
这里的评分不是自动选出“最美方案”。它的作用是暴露分歧：如果某个方案因为视觉趣味得分高，却违反减弱动态效果或时长预算，它应当先被淘汰；如果两个方案都合格，负责人则要结合用户测试和产品方向作出选择，并记录理由。
一个简短的决策记录可以包含：
decision: launcher-feedback-motion
owner: product-design-lead
status: accepted
chosen: subtle-scale
constraints:
max_duration_ms: 250
reduced_motion_required: true
evidence:
- usability-test-2025-03
- frame-time-budget
rationale: >
The subtle scale made state changes easier to notice while staying
within the motion and rendering budgets.
review_after: 2025-09-01
这种记录允许社区审查事实、补充证据和追踪结果，同时保留清晰的责任归属。
团队应该保留什么，停止什么
Ubuntu 早期设计团队的往事值得讨论，不是因为开源项目不该民主，而是因为不同问题需要不同治理工具。许可证、发布节奏和公共资源分配可以通过提案与投票处理；图标体系、动效节奏和视觉语言则需要一致的方向、专业判断以及可追责的负责人。
落地时可以检查四件事：评审是否先声明目标用户；硬约束是否与个人偏好分开；是否只有一位最终决策负责人；上线后是否用可用性、性能和可访问性数据复核结果。
参与应当开放，证据应当透明，决定必须有人负责。投票可以告诉团队房间里的人喜欢什么，但产品设计还必须回答另一个问题：离开这间房之后，用户真正需要什么？