mcpField
C
critique

critique

github.com/open-horizon-labs设计与 UI38 次安装
代码仓库

关于 critique

用于整体评估界面体验的设计评审技能,涵盖视觉层级、信息架构等方面。它将反馈整理为有优先级的评审报告,并给出具体修正建议和命令。

主要功能

  1. 01检查 AI 生成式设计痕迹
  2. 02评估层级与信息架构
  3. 03审视色彩、字体和构图
  4. 04检查交互与界面状态
  5. 05提供排序后的问题、修正建议和命令

适用场景

  1. 01在界面实现完成前进行评审
  2. 02发现不同界面状态中的易用性问题
  3. 03将视觉反馈转化为有优先级的设计修改

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/open-horizon-labs/impeccable --skill critique

安装后在 Claude Code 中输入/critique确认已加载。

详细介绍

进行全面的设计评审,评估界面是否真正好用——不仅要看技术层面,也要看它作为一项设计体验是否出色。请以设计总监的视角给出反馈。

首先:运用 frontend-design 技能中的设计原则和反模式。

设计评审

从以下维度评估界面:

1. AI 套壳识别(至关重要)

**这是最重要的一项检查。**它看起来是否和 2024—2025 年其他 AI 生成的界面如出一辙?

根据 frontend-design 技能中的所有禁止事项逐项审视设计——这些都是 AI 生成作品的典型特征。检查是否存在 AI 风格的配色、渐变文字、带发光点缀的深色模式、毛玻璃效果、主视觉区的指标布局、千篇一律的卡片网格、通用字体,以及其他所有类似特征。

判断标准:如果你把它展示给某人,并说“这是 AI 做的”,对方会不会立刻相信?如果会,问题就在这里。

2. 视觉层级
  • 视线是否会首先落在最重要的元素上?
  • 是否有明确的主要操作?能否在 2 秒内找到?
  • 尺寸、颜色和位置是否恰当地传达了重要性?
  • 原本应该有不同视觉权重的元素之间,是否存在视觉竞争?
3. 信息架构
  • 结构是否直观?新用户能否理解内容组织方式?
  • 相关内容是否按逻辑分组?
  • 是否同时给出了过多选项?(造成认知负担)
  • 导航是否清晰且符合预期?
4. 情感共鸣
  • 这个界面会唤起什么情绪?这是设计意图所在吗?
  • 它是否符合品牌个性?
  • 它给人的感觉是否可信、亲切、高端、活泼——或是符合预期的其他特质?
  • 目标用户会不会觉得“这就是为我设计的”?
5. 可发现性与操作暗示
  • 交互元素是否一眼就能看出可以操作?
  • 用户是否无需说明就知道该怎么做?
  • 悬停和聚焦状态是否提供了有用的反馈?
  • 是否有应该更明显展示的隐藏功能?
6. 构图与平衡
  • 布局是否平衡,还是有令人不适的偏重?
  • 留白是经过刻意设计的,还是单纯剩下的空间?
  • 间距和重复元素是否形成了视觉韵律?
  • 不对称是经过设计的,还是意外造成的?
7. 作为沟通方式的排版
  • 字体层级是否清晰地指示了阅读顺序?
  • 正文是否易于阅读?(行长、间距、字号)
  • 字体选择是否强化了品牌或语气?
  • 各级标题之间的对比是否足够明显?
8. 有目的地运用色彩
  • 色彩是在传递信息,而不只是装饰吗?
  • 调色板是否协调统一?
  • 强调色是否吸引了用户对正确内容的注意?
  • 色盲用户能否顺利使用?(不只是从技术上可用,也要确保信息含义仍然清晰)
9. 状态与边界情况
  • 空状态:是否引导用户采取行动,还是只说“这里什么都没有”?
  • 加载状态:是否能减轻用户对等待时间的感知?
  • 错误状态:是否有帮助且不归咎于用户?
  • 成功状态:是否确认操作成功并引导用户进行下一步?
10. 微文案与语气
  • 文案是否清晰简洁?
  • 听起来是否像真人所写?(符合品牌形象的那种人)
  • 标签和按钮是否含义明确?
  • 错误提示是否能帮助用户解决问题?

生成评审报告

请以设计总监的方式组织反馈:

反模式判定

**从这里开始。**通过/不通过:这个界面看起来像是 AI 生成的吗?列出技能中“反模式”部分提到的具体特征。请直言不讳。

整体印象

简要直述第一感受——哪些做得好,哪些不理想,以及最值得把握的一个机会。

优点

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

优先问题

按重要性排序,列出影响最大的 3-5 个设计问题:

对于每个问题:

  • 问题:清晰地指出问题
  • 为何重要:说明这会如何影响用户或阻碍目标实现
  • 修复方法:说明具体该怎么做
  • 命令:应使用哪个命令(/polish、/simplify、/bolder、/quieter 等)
次要观察

简要指出值得改进的小问题。

值得思考的问题

提出能够启发更好解决方案的问题:

  • “如果主要操作更加醒目,会怎样?”
  • “真的需要设计得这么复杂吗?”
  • “更有信心的版本会是什么样?”

请记住:

  • 直言不讳——含糊的反馈会浪费大家的时间
  • 具体明确——说“提交按钮”,不要说“某些元素”
  • 既要指出问题,也要说明它为何影响用户
  • 给出具体建议,不要只说“可以考虑探索……”
  • 果断排序——如果所有事情都重要,那就等于没有重点
  • 不要委婉批评——开发者需要坦诚的反馈,才能交付出色的设计

评论

支持 Markdown