mcpField
F
figma-design-qa

figma-design-qa

github.com/mohitagw15856测试与质量1.5k55 次安装5 天前更新
代码仓库

关于 figma-design-qa

面向设计师和产品团队的 Figma 交付前 QA 技能，按文件规范、组件、内容、状态、无障碍和交付准备度检查设计，并用 notugly 计算色彩对比度。

主要功能

  1. 01覆盖六类交付前检查
  2. 02使用 notugly 计算对比度
  3. 03记录问题、修复动作与负责人
  4. 04区分阻塞问题和次要问题
  5. 05提供明确的交付决策

适用场景

  1. 01检查 Figma 界面是否适合交付工程
  2. 02发现设计中的无障碍问题
  3. 03整理交付前待修复项

安装

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

$npx skills add https://github.com/mohitagw15856/pm-claude-skills --skill figma-design-qa

安装后在 Claude Code 中输入/figma-design-qa确认已加载。

详细介绍

Figma 设计 QA 技能

对 Figma 设计进行系统化的交接前 QA 检查，及时发现可能导致工程团队反复沟通的问题，避免这些问题造成高昂成本。

必需输入

如果用户未提供以下信息，请向其询问：

  • 正在进行 QA 的功能或界面（描述已完成的设计）
  • 平台（iOS / Android / Web）
  • 设计系统（自定义 / Material / HIG / 无）
  • 交接工具（Figma Inspect / Zeplin / Storybook / 直接链接）
  • QA 深度（快速，15 分钟 / 标准，30 分钟 / 全面，60 分钟）

编程辅助工具

无法靠目测判断对比度。AA 标准线为 4.5:1，白色背景上的 #777777 对比度为 4.478（不达标），而 #767676 为 4.54（达标）——无论怎么看 截图，都无法区分这两者。请计算：

npx --yes notugly fix "#8ab4f8" "#ffffff"     # ratio, APCA, and the nearest passing colour
npx --yes notugly onepager <url> --out review.html   # every pairing, printable
npx --yes notugly vision                      # which colours merge for colour-blind viewers

notugly fix 会返回对比度、APCA 亮度对比度，以及与已选颜色最接近且达标的颜色——色相相同、彩度相同。请将这些数值填入下方表格，不要靠估算。

结果确定、零依赖，且不调用模型——因此运行无需花费任何成本，并且每次结果都相同。

QA 是一项通过/失败检查，因此每一行对比度都需要填写数值并给出判定。 对于已部署的构建，npx notugly check <url> 在检查失败时会以非零状态码退出，因此可以直接用于 CI，而不只是手动检查。

输出结构

QA 报告：[功能] | [日期] | [平台] 总体状态： 已就绪 / 需要小幅修复 / 尚未就绪

第 1 部分：文件规范
  • 所有图层均使用语义化命名（没有“Rectangle 12”）
  • 最终画板中没有未使用或隐藏的图层
  • 使用库中的组件（而非分离后的副本）
  • 所有文本均使用文本样式（而非手动设置字体）
  • 所有颜色均使用样式或变量（而非十六进制覆盖值）
  • 画板名称与屏幕映射相匹配
  • 没有指向错误画板的遗留原型连线
第 2 部分：组件使用
  • 所有按钮均使用库组件
  • 所有输入框均使用库组件
  • 所有图标均来自获批的图标库
  • 没有本应纳入库中的自定义组件
  • 正确使用变体（尺寸、状态、类型均正确）
第 3 部分：内容与文案
  • 最终设计中没有占位文本（Lorem ipsum）
  • 所有文案均已审核并获批
  • 使用了真实内容（而非“用户名”）
  • 已测试长文本的边界情况
  • 错误消息通俗易懂
  • 空状态包含文案和 CTA
第 4 部分：状态与覆盖范围
  • 默认、加载、空、错误、成功状态
  • 交互元素具有悬停/激活状态（Web）
  • 适用时已设计禁用状态
第 5 部分：无障碍
  • 所有文本均符合 WCAG AA 对比度要求（正文 4.5:1，大号文本 3:1）
  • UI 组件与背景的对比度达到 3:1
  • 触控目标最小尺寸：iOS 为 44x44pt / Android 为 48x48dp
  • 为键盘/开关导航提供焦点状态（Web）
  • 不单独依靠颜色传达信息
  • 图标已标注文本标签或无障碍名称
第 6 部分：交接准备情况
  • 为不明显的交互添加开发注释
  • 使用自动布局控制间距（而非绝对定位）
  • 图像/资源已按正确分辨率导出
  • 设计符合获批的需求
  • 已附上原型链接
发现的问题

对每项未通过的问题： [问题] — 阻塞 / 交接前修复 / 在下一次迭代中修复

  • 内容：[具体图层/屏幕/元素]
  • 修复：[所需的具体操作]
  • 负责人：[设计师/PM/双方]
交接决定

状态、签核人、日期。

质量检查

  • 已完成全部 6 个部分
  • 每项未通过的问题都有具体描述和修复操作
  • 已将阻塞问题与轻微问题区分开
  • 已明确给出交接决定

反模式

  • 不要只做部分 QA——必须评估每个检查清单类别，而不只是明显有问题的类别
  • 不要让交付决策含糊不清——输出必须明确说明通过、有条件通过或未通过
  • 不要跳过无障碍检查——色彩对比度、点击目标尺寸和屏幕阅读器标签都是必需项，而非可选项
  • 报告问题时，必须指出问题出现在哪个屏幕或组件上
  • 如果任何组件脱离了库，且没有记录在案的理由，就不要批准设计

示例触发语

  • “在交付前对这个 Figma 设计进行 QA”
  • “对 [feature] 设计进行交付前检查”
  • “这个 Figma 设计可以交给工程团队了吗？”
  • “对 [screen/feature] 进行设计 QA”
  • “交付前还需要修复什么？”

评论

支持 Markdown