UI Audit

核心用法

UI Audit Skill 是一套结构化的界面评估框架，核心围绕三大决策支柱：

• Scaffolding（脚手架）：固化规则处理重复决策
• Decisioning（决策流程）：面对新问题的判断方法论
• Crafting（执行清单）：具体落地的检查项

使用场景覆盖设计决策压力下的快速判断、设计权衡的商业语境评估、UI模式选型、设计质量审查，以及新界面的结构化思考。

决策工作流：先「称重」信息（机构知识→用户熟悉度→研究证据），再「收窄」选项（排除约束冲突、对齐宏观押注、基于JTBD选择），最后「执行」（调用对应清单+模式）。

显著优点

1. 速度≠鲁莽的哲学：强调有意识的快速设计，而非无思考的赶工
2. 宏观押注对齐：将微观设计决策与公司级战略（速度/效率/精准/创新）绑定，确保设计投入产生业务价值
3. 完整的方法论体系：从心智模式（7个设计韧性锚点）到心理学/经济学/无障碍基础，再到20+模式库，形成闭环
4. 审计报告结构化：强制包含视觉层次、视觉风格、可访问性三大模块，按需扩展导航/可用性/ onboarding等，输出格式可直接对接开发

潜在缺点与局限性

• 作者中心化：完全依赖 Tommy Geoco 的个人方法论，缺乏多源交叉验证
• 西方产品语境：模式库和案例可能偏向欧美SaaS/消费级应用，对本土化复杂业务场景覆盖有限
• AI执行的不确定性：实际审计质量高度依赖模型对设计原则的理解深度，复杂界面可能出现「假阳性」或遗漏上下文敏感问题
• 动态界面支持弱：对实时数据驱动、高频状态变化的界面审计能力不足

适合人群

• 独立设计师/小团队：缺乏专职用研资源，需要快速、有依据的决策支撑
• 产品经理：需评估设计方案的业务对齐度
• 设计系统维护者：模式库和检查清单可直接纳入设计规范
• 初级设计师：通过结构化框架培养决策直觉

常规风险

| 风险类型 | 说明 |

|---------|------|

| 过度依赖框架 | 可能忽视特定用户群体的非常规需求，将「contextually appropriate」误解为「safe and boring」 |

| 可访问性检查流于表面 | JSON 输出中的 `status: pass` 可能基于视觉判断，而非真实屏幕阅读器/键盘测试 |

| 宏观押注误读 | 若对产品战略理解偏差，可能导致设计方向与公司实际优先级背离 |

| 输出格式僵化 | 强制JSON结构可能遗漏定性洞察，需人工补充叙事性分析 |

核心用法

UI Audit Skill 是一套结构化的设计审计方法论，源自 Tommy Geoco 的《Making UX Decisions》。其核心工作流程围绕三大支柱：

• Scaffolding（脚手架）：自动化重复决策的规则库
• Decisioning（决策）：新决策的三步权衡法——机构知识 → 用户熟悉度 → 研究依据
• Crafting（执行）：覆盖视觉、交互、可访问性的标准化检查清单

使用场景包括：时间压力下的设计决策、设计权衡评估、UI 模式选择、新界面构建、设计质量审查。用户可通过调用特定参考文档，获取从基础框架（如 7 大设计心态）到具体模式（如 12 种信息分块策略）的全栈指导。

显著优点

方法论成熟：基于出版著作的系统性框架，避免了经验主义的碎片化建议。决策效率极高："三步权衡法"和"宏观赌注（Macro Bet）"对齐机制，让设计决策从主观偏好转向与业务目标挂钩的理性选择。输出结构化：审计报告强制包含可视化层次、视觉风格、可访问性三大必检项，以及导航、可用性、 onboarding 等情境化模块，确保无遗漏。模式库丰富：涵盖认知负荷、渐进披露、社交证明、错误处理等 12 大领域，每个模式附带心理学原理与实现指南。

潜在局限

学习曲线陡峭：22 个参考文档、5,944 行内容需要用户投入时间理解框架结构，不适合即拿即用。主观性仍存：虽然强调"上下文适配"，但部分检查项（如"视觉重量平衡"）缺乏量化标准，依赖执行者经验。技术实现 gap：作为纯文档型 Skill，不提供自动化检测工具（如对比度计算、焦点顺序验证），审计结果需人工比对。更新依赖作者：模式库跟随 UX 趋势演进，但开源社区贡献度有限（GitHub 13 stars），长期维护存疑。

适合人群

• 中高级产品设计师：需要系统化框架支撑设计评审与决策辩护
• 设计团队 Lead：用于统一团队设计语言、建立审计 SOP
• UX 顾问/自由设计师：向客户输出专业化、可复现的审计报告
• 产品经理：快速评估设计方案完整性与风险点

不适合：寻求即时自动化检测工具的初级设计师，或完全无 UX 背景的技术开发者。

常规风险

低风险项：无数据收集、无网络请求、无代码执行，隐私与安全性极佳（S+ 评级）。使用风险：过度依赖框架可能导致" checklist 驱动设计"，忽视创新突破；检查项的"通过/警告/失败"判定若执行者经验不足，可能流于形式。业务风险："宏观赌注对齐"要求用户准确理解公司战略，误判可能导致设计决策与业务方向背离。