critique

强制准备工作

阅读 frontend-design，并遵循其中的上下文收集流程。复用已有上下文，只询问影响重大的信息缺口。此外，还需了解：该界面要实现什么目标。

---

进行全面的设计评审，评估界面是否真正好用——不仅是技术层面，还包括作为一种设计体验是否有效。以设计总监的视角给出反馈。

查看 hierarchy checklist，检查灰度测试、操作优先级以及标签与值的处理。 查看 text hierarchy and readability，检查行长、行高、基线、对齐方式以及标题是否克制。 查看 cognitive load，检查工作记忆限制和 8 项检查清单。 评估常见交互模式、目标尺寸、焦点处理和叠层行为时，查看 interaction design。 如果界面依赖站内搜索、命令面板、自动补全、结果相关性或无结果时的恢复机制，请查看 search and findability。 如果评审涉及旧系统、新旧界面的衔接、迁移候选项或高风险运营工作流，请查看 legacy modernization。 查看 ai slop detection，获取汇总的反模式清单。 评估主要、次要和第三级操作时，请查看 action hierarchy。 如果颜色承载了含义，请查看 semantic color。 评判边框、卡片的使用、重叠或背景变化时，请查看 surface separation。 如果截图、图标和媒体会影响可读性或精致感，请查看 image treatment。

将共享的 frontend-design 参考资料视为层级、可读性和认知负荷原则的权威依据，并让本技能聚焦于评估、评分和优先级排序。

当空状态与评审相关时，使用 empty-state 的思路评估零数据界面本身；使用 onboard 的思路评估更广泛的激活、关键体验时刻和首次运行引导。

使用 visual verification 处理截图、证据限制和可复用的评审结果记录。默认只审查并报告。仅在明确授权或先前已获授权实施的情况下修复问题。除非用户要求，或当前工作流本身已包含保存报告的步骤，否则不要创建保存的报告。

第一阶段：设计评审

从以下维度评估界面：

1. 产品与品牌契合度

评估整体构图是否适合目标受众和任务。将 AI slop detection 作为诊断提示，而非一概禁止的规则。保留已获认可的字体、颜色和常见模式。指出具体的层级、可读性或品牌契合问题，不要臆测页面是否由 AI 生成。

2. 视觉层级

• 视线是否会首先落在最重要的元素上？
• 是否有明确的主要操作？能否在 2 秒内找到？
• 真正重要的内容是否足够突出，还是强调程度平均分散，以至于没有任何内容令人印象深刻？（冯·雷斯托夫效应）
• 尺寸、颜色和位置是否正确传达重要性？
• 原本应该权重不同的元素之间，是否存在视觉竞争？
• 即使想象屏幕变成灰度，层级是否依然清晰？
• 分区标题是否比其引出的内容更轻，不会喧宾夺主？
• 操作层级是否被拉平，导致多个按钮看起来同样紧急？

3. 信息架构与认知负荷

请参阅 cognitive-load，了解工作记忆规则和 8 项检查清单

• 结构是否直观？新用户能否理解内容的组织方式？
• 相关内容是否按逻辑分组？
• 常见模式的行为是否符合用户已有的预期？检查导航、搜索、表格、筛选器、表单、标签页、下拉菜单、分页和设置，确认没有不必要的新奇设计。
• 是否通过默认值、预填内容和引导将可避免的复杂性转移到系统中，还是把它们都留给用户手动处理？（特斯勒定律）
• 可见选项是否让决策变得更困难？评估分组方式、熟悉度和任务复杂性，而不是采用通用的选项数量上限。
• 导航是否清晰且符合预期？
• 如果有搜索，它能否理解用户意图、同义词、拼写错误和可能的目标位置，还是会因为用户不熟悉内部术语而惩罚他们？
• 在新旧流程混用的情况下，是否有一个脆弱的步骤就让整个产品显得不可靠或不一致？
• 渐进式披露：是否只在需要时才展现复杂性，还是一开始就把所有内容都交给用户？
• 运行参考中的 8 项认知负荷检查清单。报告失败项数：0–1 = 低（良好），2–3 = 中等，4 项以上 = 严重。

4. 情绪体验历程

• 此界面会唤起什么情绪？这是有意为之的吗？
• 是否符合品牌个性？
• 它给人的感觉是否值得信赖、平易近人、高端、活泼——或其他预期的感觉？
• 目标用户会觉得“这就是为我打造的吗”？
• 高频交互的响应速度是否足以维持用户的操作节奏，还是反复等待不断打断用户的专注？（多尔蒂阈值）
• 峰终定律：最强烈的时刻是否积极？体验是否以良好的方式结束（确认、庆祝、明确的下一步）？
• 情绪低谷：检查是否存在令人沮丧的引导流程、令人困惑的错误、功能发现障碍，或在高风险时刻（付款、删除、提交）引发焦虑的情况。
• 负面时刻的干预措施：在用户可能感到沮丧或焦虑的地方，是否有设计干预措施？（进度指示器、安抚文案、撤销选项、社会认同）

5. 可发现性与可供性

• 交互元素是否一目了然？
• 用户是否无需说明就知道该怎么做？
• 主要和高频操作目标是否足够大、位置是否足够近，让用户能够放心操作，尤其是在粗指针设备上？
• 是否根据强大功能的风险程度提供相应的防护措施——权限、预览、撤销、确认、历史记录或明确说明后果？
• 悬停和焦点状态是否提供有用的反馈？
• 是否有应该更醒目的隐藏功能？

6. 构图与平衡

• 布局是否平衡，还是让人感觉重心不适？
• 留白是经过有意安排的，还是只是剩下的空间？
• 间距和重复元素是否形成视觉节奏？
• 不对称看起来是刻意设计的，还是意外造成的？
• 组与组之间的空间是否比组内空间更大，还是组边界不够明确？
• 边框是否承担必要的结构作用，还是只是在弥补间距或背景对比度不足？
• 卡片、阴影、重叠和背景变化是否采用了明确的区隔策略，还是多种方法堆叠在一起，显得杂乱？

7. 作为沟通方式的排版

• 字体层级是否清晰地提示了阅读顺序？
• 正文是否易于阅读？（行长、间距、字号）
• 字体选择是否强化了品牌和语气？
• 标题层级之间的对比是否足够明显？
• 是否有太多近乎相同的字号，以至于看不出真正的字号体系？
• 行高是否与行长匹配，还是长段落显得拥挤？
• 章节标题相对于其作用而言，在视觉上是否过于醒目？
• 链接是否因颜色而过于抢眼，而使用字重、下划线或悬停样式会显得更克制？
• 在需要比较和浏览数字时，数字列是否对齐？

8. 有目的地使用颜色

• 颜色是否用于传达信息，而不只是装饰？
• 配色是否协调统一？
• 强调色是否将注意力引向恰当的内容？
• 色盲用户能否正常使用？（不只是技术上可用——含义是否仍能传达？）
• 有色表面是否使用了恰当的文字颜色，还是出现了褪色的灰字叠加在彩色背景上的情况？
• 是否有太多临时添加的色调，导致配色缺乏系统性？

9. 状态与边缘情况

• 空状态：是否引导用户采取行动，还是只说“这里什么也没有”？
• 加载状态：是否能缩短用户感知到的等待时间？
• 表单和搜索是否能妥善处理无害的输入差异，还是会因为本可以规范化的格式问题而拒绝用户？（Postel 法则）
• 错误状态：是否有帮助且不责怪用户？
• 成功状态：是否确认操作成功并引导后续步骤？
• 截图在当前显示尺寸下是否清晰可读？
• 图标的缩放是否显得经过精心设计，而不是笨重或模糊？

10. 微文案与语气

• 文案是否清晰简洁？
• 听起来是否像真人（而且是符合这个品牌形象的真人）？
• 标签和按钮是否含义明确？
• 流程中是否有任何操纵性设计——混淆同意、阻碍取消、让用户内疚的文案、虚假的紧迫感，或迫使用户做出错误选择的视觉层级？
• 错误文案是否能帮助用户解决问题？

阶段 2：呈现发现

像设计总监一样组织反馈：

设计健康评分

请参考 启发式评分

根据参考标准，对已检查且相关的启发式原则按 0 到 4 分评分。其他原则标记为未测试或不适用。在每项判断旁列出可用证据：

#	启发式原则	评分	主要问题
1	系统状态的可见性	?	[具体发现；若表现良好则填“—”]
2	系统与现实世界相匹配	?
3	用户控制权与自由度	?
4	一致性与标准	?
5	错误预防	?
6	识别而非回忆	?
7	灵活性与效率	?
8	美观且简约的设计	?
9	错误恢复	?
10	帮助与文档	?
总分		??/40	[评级区间]

评分反映的是所评审的范围，不代表衡量得出的用户体验结果。只有在全部十项启发式原则都相关且经过检查时，才显示满分 40 分的总分。否则省略总分和评级区间。

构图判断

说明层级结构和视觉系统是否有助于完成任务。指出具体缺陷，并保留明确约束。仅字体或配色本身不能构成问题。

整体印象

简要说说直观感受——哪些地方有效，哪些无效，以及最大的改进机会。

做得好的地方

指出 2–3 个做得好的方面。具体说明它们为何有效。

优先问题

按影响程度排序，最多报告五个重大设计问题。若证据只支持更少的问题，就报告更少的问题；不要为了凑数而编造发现。

对于每个问题，标注 P0–P3 严重程度（严重程度定义请参阅 heuristics-scoring）：

• [P?] 问题：清楚说明问题
• 为何重要：说明它如何损害用户体验或削弱目标
• 修复方案：说明应如何处理（具体明确）
• 建议命令：可用于解决该问题的命令（从以下命令中选择：/animate、/arrange、/critique、/extract、/polish、/optimize、/audit、/typeset、/bolder、/clarify、/delight、/adapt、/colorize、/quieter、/harden、/distill、/onboard、/normalize、/showcase）

优先指出层级薄弱、系统随意、操作优先级不明确和装饰嘈杂等问题，而非表面上的小瑕疵。

适用时，明确指出：边框过多、分组含糊、字体大小过多、色调缺乏系统性、分区标题过于醒目、操作层级扁平、行长与行高不匹配、标签:值反模式、不必要的彩色链接强调、数字列未右对齐、表面区分策略薄弱、缩小后的截图难以辨读、放大后的图标显得笨重，以及图层未清晰分隔导致的重叠冲突。

Persona 警示项

请参阅 personas

从参考资料或已确认的受众背景中，选择相关的假设 Persona。将演练标注为启发式评估，而非用户研究。

对于每个选定的 Persona，演练主要用户操作，并列出发现的具体警示项：

高级用户演练： 完成测试的主要操作需要点击八次，且未发现快捷方式。如果这是常见任务，请考虑缩短操作路径。

首次使用者演练： 侧边栏图标没有可见标签。这可能妨碍用户发现功能；请通过基于任务的可用性测试进行确认。没有证据时，不要预测用户会放弃使用。

具体说明哪些元素和交互无法满足各 Persona 的需求。不要写泛泛的 Persona 描述；要指出具体是什么环节出了问题。

次要观察

简要记录值得处理的小问题。

请记住：

• 直截了当——含糊的反馈会浪费大家的时间
• 具体明确——说“提交按钮”，不要说“某些元素”
• 既要说明哪里有问题，也要说明这对用户为何重要
• 给出具体建议，不要只说“可以考虑探索……”
• 严格排定优先级——如果所有事情都重要，那就等于没有重点
• 不要弱化批评——开发者需要坦诚的反馈，才能交付出色的设计

第 3 阶段：建议下一步行动

在同一条回复中呈现发现和按优先级排序的行动计划。沿用已知的优先级、范围和已委派的选择。只针对尚未解决且会实质改变拟议工作的决策提问；不要把填写问卷设为必需的收尾步骤。

将每项重大问题对应到适当的已安装技能，例如 a11y、arrange、clarify、normalize 或 polish。提供足够的目标和证据细节，以便后续继续修复。没有相关问题的命令无需提及。仅在仍有收尾工作时建议使用 polish。

如果修复已获授权，请在该范围内继续，而不要再次询问。否则，将实施方案作为建议提出。后续评审必须依据当前证据，不得承诺更高的分数。