设计评审最容易滑向主观判断，原因是与会者各自带着不同审美经验参与讨论，而评审材料本身没有把判断标准前置。比如有人说“这个按钮不够明显”，另一个人说“已经足够了”，双方都无法拿出可验证的规则。要让评审结论稳定，需要把设计规范与可用性原则作为评审的共同语言。
一、主观性从哪里来
设计评审中的主观性通常表现在三个层面。第一，目标不一致，有人关注视觉风格，有人关注业务转化，有人关注开发成本，当讨论没有明确优先级，声音大的人往往占据主导。第二，缺少基线，评审没有列出哪些字段、间距、颜色是规范允许的，哪些是偏差，因此任何细节都可能被临时挑战。第三，语言模糊，常见评价如不够高端、感觉怪怪的、不够清晰等，无法转成具体行动。
这些问题的共同结果是评审结论很难沉淀。上一次否定的按钮样式，下一次可能因为不同参与者又重新被提起；已经通过的颜色方案，上线前又被主观推翻。要改变这种状况，不能只要求参与者更专业，而要在流程中注入可核查的规则。设计规范解决应该用什么的问题，可用性原则解决这样设计是否容易被理解和使用的问题。
如果评审材料里只有效果图，没有标注任何规范引用，评审者自然会用个人偏好填补判断空白。反之，当每个争议点都能指向一条规范条款或可用性检查项，讨论会从我喜欢变成这不符合第几条，主观性就会明显下降。
二、设计规范注入：从视觉基线到组件状态
设计规范注入的核心不是把文档发给每个人，而是把规范中的关键值直接标注到评审对象上。页面中每个颜色、字号、间距、圆角都应当能对应到设计令牌。例如主按钮颜色应来自品牌主色，而不是设计者临时取的近似值；卡片与正文间距应使用 8 的倍数，而不是凭眼调整的 13 像素。这样做一方面减少视觉决策随机性，另一方面让开发还原有据可查。
下面是一个简化的设计令牌示例，可以作为评审基线维护在项目文档中：
{
"color": {
"primary": "#2F54EB",
"primaryHover": "#1D39C4",
"text": "#1F1F1F",
"textSecondary": "#595959",
"border": "#D9D9D9",
"danger": "#FF4D4F"
},
"font": {
"sizeSM": 12,
"sizeBase": 14,
"sizeLG": 16,
"sizeXL": 20
},
"spacing": {
"xs": 4,
"sm": 8,
"md": 16,
"lg": 24,
"xl": 32
},
"radius": {
"control": 4,
"card": 8
}
}
这些令牌进入评审后，检查项就可以写成：主操作按钮的颜色是否使用了 color.primary，悬停态是否为 color.primaryHover；正文与标题之间的间距是否在 spacing.md 到 spacing.lg 范围内。只要出现偏离，评审就能明确标记为规范偏差，而不是好不好看的问题。
除了静态令牌，组件状态也必须纳入规范。按钮、输入框、下拉选择器在不同状态下的边框、背景、阴影、提示文案都应有定义。例如输入框在焦点态必须有 2 像素主色描边，同时不能只依赖颜色区分错误，还要出现错误图标与文案。评审会上，可以要求设计师把每个关键组件从默认、悬停、焦点、禁用、错误五种状态截图排列，逐项对照规范。这样很多只在默认态看起来不错、却在错误态或禁用态暴露问题的设计会被提前拦截。
还需要注入交互规则。比如操作后多久必须出现反馈、危险操作是否需要二次确认、表单校验是在失焦时触发还是在提交时触发。把这些规则写进评审清单，可以避免评审只停留在静态视觉层面，而忽略真实使用流程。
三、可用性原则注入：把体验问题变成可打分项
设计规范关注一致性，可用性原则关注用户能否顺利完成目标。评审时如果只说这个流程不太好用，仍然缺乏判断依据。更有效的方式是把通用可用性原则拆成具体检查项，让每个界面或流程都能打分。常用的基础是尼尔森十大可用性原则，但需要针对产品类型进行裁剪。
可以建立一个评分表，每项按 0、1、2 打分。0 表示未满足且存在明显风险，1 表示部分满足或需要验证，2 表示满足并有明确证据。评分维度包括：系统状态是否可见，操作后是否有加载、成功、失败反馈；语言是否贴近用户认知，是否使用用户可以理解的词汇而不是技术术语；用户是否拥有控制权，能否撤销或返回；一致性是否满足，相同场景是否使用相同组件和文案；错误预防是否到位，高风险操作是否有约束或确认；识别是否优于回忆，关键信息是否直接可见而不是藏在深层菜单；灵活性与效率，高频操作是否提供快捷路径；视觉是否克制，信息层级是否清晰；错误恢复是否有效，错误信息是否说明原因并给出解决建议；帮助文档是否必要且可访问。
这样评审时不再笼统地说反馈不好，而是可以说：系统状态可见性这一项得 0 分，因为点击导出后没有任何加载提示，用户在网络慢时可能重复点击。评分表中的证据列要求评审者截图或说明现象，避免只凭印象。这种结构也让设计师在评审前可以自行预检，把明显问题提前改掉。
下面是一个可用性检查项配置示例：
[
{
"id": "US-01",
"principle": "系统状态可见",
"check": "用户操作后是否在 300ms 内出现反馈",
"score": 0,
"evidence": "导出按钮点击后无 loading 状态，接口较慢时页面无任何变化"
},
{
"id": "US-02",
"principle": "错误预防",
"check": "不可逆操作前是否有确认或撤销机制",
"score": 1,
"evidence": "删除有确认弹窗，但批量删除后无法撤回"
},
{
"id": "US-03",
"principle": "一致性与标准",
"check": "相同含义的操作是否使用一致的按钮文案和位置",
"score": 2,
"evidence": "列表页与详情页的主操作均位于右侧，使用同一主色按钮"
}
]
这个 JSON 片段可以直接作为评审记录模板，也可以放在在线协作文档中维护。它让每个问题都有唯一编号，方便后续跟踪。汇总评分时，可以按业务影响加权，而不是简单平均。例如支付流程中的错误预防和状态可见性权重更高，营销落地页的文案一致性权重可以适当降低。权重可以根据用户任务的核心路径调整，但必须在评审前达成一致，否则权重本身也会变成新的主观争论。
可用性原则注入的另一个好处是，它能帮助团队区分规范缺陷和体验缺陷。规范缺陷通常有明确标准，修起来快；体验缺陷需要更多上下文判断。两者混在一起，会导致评审会既讨论字号又争论流程，效率很低。通过评分表和问题分级，可以把规范偏差直接交给设计系统维护者，把体验问题交给产品与用户研究跟进。
四、评审会议如何执行
有了规范与可用性原则，还需要调整评审会议的组织方式。会前至少一天，设计师应提交带有标注的评审材料，包括页面截图、流程说明、涉及的设计令牌引用、关键组件状态、自检评分表。评审负责人需要确认这些材料已经覆盖本次范围，如果缺少评分表或规范引用，可以要求补齐后再开会。这样可以过滤掉大量低质量评审。
会议开始后，先对齐本次评审目标，例如是检查视觉一致性还是验证任务流程，不要同时展开所有维度。然后按照评分表逐项过，先看规范符合度，再看可用性得分。发生分歧时，主持人应要求发言者明确指出违反的是哪一条，而不是反复表达个人感受。例如不能说我觉得这个颜色不舒服，而要说这个提示文案的颜色与设计令牌中的 danger 不一致，可能让用户误以为操作失败。后者容易被验证，前者无法裁决。
评审结果应输出问题清单，每条包含问题编号、所属页面、违反的规范或原则、严重级别、建议处理方式、负责人和期限。清单写清楚后，评审才算闭环。问题分为阻塞、主要、次要三级：阻塞问题必须修改后才能进入下一阶段；主要问题应在当前版本尽快处理；次要问题可以进入设计系统优化池。
每次评审结束后，还需要做一件事：把新出现的模糊点补充到设计规范或可用性检查库中。例如本次评审发现空状态没有统一插画风格，就可以在设计规范里新增空状态组件条目。只有不断更新基线，后续评审才会越来越容易。否则每次都靠相同的几条原则，细节问题仍然会重复讨论。
这种注入式评审不是要把设计变成机械打分。它不替代设计判断，而是把判断放进一个更透明的框架里。对于创意方向和品牌表达，仍然需要保留讨论空间；但对于组件状态、交互反馈、信息层级这些可规范化的部分，规则越清楚，团队越能把精力集中在真正需要决策的地方。