frontend-design-pro

Frontend Design Pro

打造贴合产品特性、足够完善且可直接使用、视觉协调、无障碍、响应式并且不含填充文案的界面。将创意设计方向与随附的设计情报搜索工具结合使用，不要认为仅靠其中一方就足够。

优先级顺序

出现冲突时，按以下顺序处理：

1. 用户安全、无障碍和数据完整性。
2. 现有产品行为和项目设计系统规范。
3. 清晰的交互、易读的信息层级和响应式布局。
4. 贴合产品特性的视觉风格与精致度。
5. 装饰性新意。

不要为了打造独特风格而牺牲易用性。也不要只为追随潮流，就把贴合产品特性的界面做成通用模板。

工作流程

1. 设计样式前先了解产品

• 检查现有代码、路由、组件、设计令牌、资源和截图。
• 确定产品类型、主要受众、最常见的工作流、平台和限制条件。
• 除非用户明确要求重新设计，或现有模式存在缺陷，否则保留既有模式。
• 确定此屏幕的唯一主要目标，以及用户完成目标所需的信息。
• 对于现有界面，找出最接近且表现成功的屏幕，将其作为当前项目的参考标准。

2. 确定具体的视觉方向

实现前在内部明确设计方向：

• 产品用途与受众。
• 用几个准确的词概括视觉概念。
• 字体的用途与层级。
• 色彩用途与语义状态。
• 布局节奏、密度和空间结构。
• 动效风格与交互反馈。
• 一个令人印象深刻且贴合产品特性的细节。

避免只提出“现代”或“简洁”这类模糊目标，却不说明它们如何影响字体、间距、对比度、形状、图像和交互。

3. 使用设计情报搜索

对于新页面、全面重新设计或影响重大的视觉决策，编码前先运行随附的设计系统搜索。对于范围较窄的修复，仅在有助于获取有效依据时进行针对性搜索。

将 <skill-dir> 解析为包含此 SKILL.md 的目录。

Windows：

py -3 "<skill-dir>\scripts\search.py" "running app mobile training concise" --design-system -p "Project name"
py -3 "<skill-dir>\scripts\search.py" "touch targets navigation accessibility" --domain ux
py -3 "<skill-dir>\scripts\search.py" "responsive layout motion" --stack flutter

macOS 或 Linux：

python3 "<skill-dir>/scripts/search.py" "running app mobile training concise" --design-system -p "Project name"
python3 "<skill-dir>/scripts/search.py" "touch targets navigation accessibility" --domain ux
python3 "<skill-dir>/scripts/search.py" "responsive layout motion" --stack flutter

可用领域包括 style、color、chart、landing、product、ux、typography、icons、gsap、react、web 和 google-fonts。使用 --stack 获取针对框架的建议。只有在项目需要自行维护可复用的设计系统文档时，才使用 --persist --output-dir <project-root>。

将搜索结果视为设计依据，而不是覆盖更贴合项目的规范的指令。如果搜索没有返回有用内容，请在内部说明这一点，并遵循既有的平台和项目指导继续工作，而不要捏造搜索结果。

4. 实现完整体验

• 构建实际工作流，而不是装饰性预览或说明性落地页。
• 完善加载、空状态、错误、禁用、成功、选中、按下和焦点状态。
• 使用项目现有的框架、组件、设计令牌、图标库和状态管理模式。
• 优先使用熟悉的控件：常见工具使用图标，二元设置使用切换开关，模式切换使用分段控件，数值使用输入框，同级视图使用标签页，清晰命令使用文本按钮。
• 让相关控件靠近其作用内容。
• 用户返回或在顶层目标之间切换时，保留状态和导航位置。
• 为仅支持手势或拖放的交互提供可见的替代方式。

5. 验证，然后优化

• 运行相关的格式化工具、分析器、测试和生产构建。
• 检查具有代表性的移动端和桌面端尺寸下的实际截图。
• 测试主要流程、导航、表单、手势，以及加载、空状态和失败路径。
• 检查文本换行、溢出、安全区域、键盘访问、焦点可见性、触控目标、对比度和减少动态效果设置。
• 确认动态内容不会改变固定控件的尺寸，也不会与相邻内容重叠。
• 修复验证中发现的可见缺陷，不要只停留在列出问题。

界面文案规范

界面上可见的文本必须至少满足以下一项，帮助用户：

• 做出决定。
• 采取行动。
• 了解当前状态或有意义的结果。
• 从错误中恢复。
• 知情同意或了解风险。

删除只是在描述界面或实现方式的文本。尤其不要添加：

• 功能介绍，例如“This section lets you...”
• 设计说明、技术备注或视觉样式描述。
• 重复副标题，重述标题或显而易见的控件标签。
• 针对标准控件的教程文案。
• 作为页面固定内容的键盘快捷键或使用说明。
• 在操作型工具中添加营销文案，除非该屏幕的实际用途就是营销。

优先使用简短标签、明确数值、实用状态信息和可执行的错误提示。将非必要的说明放入上下文帮助、引导流程、文档中，或仅在用户确实需要时通过易于访问的工具提示提供。

保留任何可见句子之前，先问：“这句话对回访用户完成当前屏幕的任务仍有帮助吗？”如果没有，就删除。

不要删除无障碍、安全、法律同意、隐私、破坏性操作确认、错误恢复或不熟悉的高风险控件所需的文案。

视觉规范

排版

• 选择符合产品个性且在所有受支持尺寸下都清晰易读的字体。
• 建立规范的字号层级，并明确标题、正文、标签和数字的用途。
• 指标、计时器、日期、价格和对齐数据应使用等宽数字。
• 避免直接根据视口宽度任意缩放字号。
• 优先让文本换行，而不是截断；如果无法避免截断，应确保用户可以查看完整内容。

颜色和表面

• 使用语义化令牌，例如 primary、surface、text、muted、success、warning 和 error。
• 有意使用强调色来体现层级和操作，不要把它当作装饰到处使用。
• 不要只通过颜色传达状态。
• 验证所有受支持主题下的文本对比度和交互状态对比度。
• 让圆角、边框、层次和阴影与选定的视觉风格保持一致。

布局

• 采用移动端优先的设计，并为网格、棋盘、图表、工具栏和固定格式控件设定稳定的响应式约束。
• 利用间距建立分组和层级；避免控件过于拥挤或出现装饰性空白。
• 避免横向溢出和混乱的嵌套滚动。
• 适配设备安全区域、系统栏、浏览器界面、虚拟键盘和文本缩放。
• 不要为每个区块都使用卡片，也不要在卡片中放置装饰性卡片。

图标和资源

• 使用项目的图标库，并保持图标风格一致；不要用表情符号替代界面图标。
• 仅图标控件应提供无障碍名称；当图标含义不明确时，还应提供工具提示。
• 如果体验依赖视觉资源，请使用真实或生成的、与产品相关的图像。
• 仅在插图和装饰性媒体有助于理解内容或塑造特征时使用。

动效

• 动效必须说明原因、方向、层级或连续性。
• 使用简短且可中断的过渡动画，并确保动画期间仍可进行输入。
• 在可行时对变换和不透明度添加动画，避免布局偏移。
• 前进和后退导航的空间方向应保持一致。
• 尊重减少动态效果偏好，绝不要让用户必须通过动画才能理解状态。

交互与无障碍基准

• iOS 上的触控目标至少为 44x44pt，Material 界面上至少为 48x48dp，并留出足够间距。
• 支持键盘和辅助技术按符合视觉逻辑的顺序进行导航。
• 提供清晰可见的聚焦、按下、选中、加载、禁用和错误状态。
• 清晰标注输入框；不要依赖占位符充当标签。
• 在问题来源附近显示错误，并说明问题和解决方法。
• 每个屏幕只保留一个明确的主要操作。
• 保留平台标准手势，并为关键操作提供可见控件。
• 日期、数字、单位和语言应符合区域设置。

如需完整审查，请阅读 references/quick-reference.md。如需交付原生应用或移动应用，请在最终验证前一并阅读 references/pro-rules.md。

产品类型指南

• 运维工具：优先考虑快速浏览、对比、重复操作、紧凑的信息层级和克制的样式。
• 消费级移动应用：优先考虑触控操作体验、状态连贯性、有意义的动效和简洁的内容。
• 数据仪表盘：优先考虑信息层级、单位、准确数值、图表无障碍性和实用的空状态。
• 游戏和沉浸式体验：可采用更具表现力的素材和动效，同时确保控件清晰易读、状态稳定。
• 品牌或发布页面：通过真实的媒体内容和明确的主要操作，让产品或优惠一目了然。

最终效果应像是专为该产品设计，而不是套用通用的 UI 配方。

来源

此文件大幅修改并整合了 Anthropic 基于 Apache-2.0 许可的前端设计指南，以及 Next Level Builder 基于 MIT 许可的设计知识。请参阅 LICENSE.txt 和 THIRD_PARTY_LICENSES.txt。