frontend-ui-design

前端 UI 设计

概述

指导前端用户界面的设计与实现，确保架构一致、无障碍、响应式且高性能。本技能涵盖组件模式、设计系统集成、状态管理方案选择和 WCAG 合规，帮助打造可测试、无障碍且高性能的组件。

开始时宣布：“我正在使用 frontend-ui-design 技能来设计 UI。”

阶段 1：需求调研

提出以下问题，了解 UI 需求：

#	问题	确定内容
1	我们要构建什么组件或页面？	范围和复杂度
2	使用什么框架/库？（React、Vue、Svelte 等）	代码模式
3	是否已有设计系统或组件库？	约束条件
4	必须支持哪些设备？（手机、平板、桌面）	响应式策略
5	有哪些无障碍要求？（WCAG 等级）	无障碍标准
6	这个组件需要什么数据？	状态管理方案

需求调研后停止——在设计前先总结约束条件和方案。

阶段 2：选择组件架构

架构模式决策表

模式	适用场景	不适用场景
原子设计	从零构建组件库	向现有系统添加单个组件
复合组件	由多个部分组成且需要布局灵活性的组件	简单的单一用途组件
Hooks 模式	在不同 UI 中复用相同逻辑	与某个特定组件绑定的逻辑
容器/展示组件	组件需要隔离测试或多个数据源	逻辑很少的简单组件

原子设计层级

层级	描述	示例
原子	最小的构建单元，单一用途	Button、Input、Label、Icon
分子	组合在一起协同工作的原子	SearchBar（Input + Button）、FormField（Label + Input + Error）
有机体	由分子组成的复杂部分	Header（Logo + Nav + SearchBar）、ProductCard
模板	使用占位内容的页面布局	DashboardLayout、AuthLayout
页面	填充真实数据的模板	HomePage、SettingsPage

复合组件示例

<Select value={selected} onChange={setSelected}>
  <Select.Trigger />
  <Select.Options>
    <Select.Option value="a">Option A</Select.Option>
    <Select.Option value="b">Option B</Select.Option>
  </Select.Options>
</Select>

适用场景：组件包含多个必须协同工作的子部分，但使用者需要灵活安排布局。

Hooks 模式示例

function useDialog() {
  const [isOpen, setIsOpen] = useState(false);
  const open = () => setIsOpen(true);
  const close = () => setIsOpen(false);
  return { isOpen, open, close };
}

适用场景：多个 UI 不同的组件需要使用相同逻辑。

架构选择后停止——继续之前，先确认所选模式。

阶段 3：响应式设计

移动优先断点

断点	目标设备	最小宽度
sm	手机横屏	640px
md	平板	768px
lg	桌面	1024px
xl	大屏桌面	1280px
2xl	超宽桌面	1536px

响应式策略决策表

需求	使用	不使用
布局随视口尺寸变化	媒体查询	容器查询
组件随父容器尺寸变化	容器查询	媒体查询
文本在断点之间平滑缩放	clamp() 流式排版	固定字号
图片适配视口	srcset + sizes	单张固定图片

流式排版

font-size: clamp(1rem, 0.5rem + 1.5vw, 1.5rem);

阶段 4：无障碍（WCAG 2.1 AA）

语义化 HTML 决策表

需求	使用	不使用
导航	<nav>	<div class="nav">
按钮操作	<button>	<div onClick>
页面区块	<main>、<section>、<aside>	<div>
标题	按顺序使用 <h1>-<h6>	<div class="heading">
项目列表	<ul>、<ol>	嵌套的 <div>
表单标签	<label for="...">	仅使用占位文本

ARIA 使用规则

规则	适用时机
优先使用语义化 HTML	始终如此 — ARIA 是后备方案
aria-label	为没有可见文本的元素提供标签
aria-describedby	将描述性文本与元素关联
aria-live	播报动态内容更改
aria-expanded	可切换的区域（手风琴、菜单）
role	仅在没有语义化元素时使用

键盘导航要求

• 所有交互元素都可聚焦（原生支持或使用 tabindex="0"）
• 可通过键盘操作（Enter、Space、Escape、方向键）
• 显示可见的焦点指示器（没有替代样式时，绝不使用 outline: none）
• Tab 顺序符合逻辑，并与视觉顺序一致
• 为模态框和对话框设置焦点陷阱

颜色对比度要求

元素	最低比例
普通文本	4.5:1
大号文本（18px+ 或 14px+ 粗体）	3:1
UI 组件	与相邻颜色的对比度为 3:1
通过颜色传达的信息	还必须使用图标、图案或文本

屏幕阅读器测试

至少使用一种屏幕阅读器进行测试：

• macOS：VoiceOver（内置）
• Windows：NVDA（免费）或 JAWS
• 验证：内容按逻辑顺序播报，表单错误与输入框关联，动态更新会被播报

阶段 5：状态管理与性能

状态管理决策表

状态类型	方案	适用时机
本地	useState、useReducer	状态仅由一个组件或其直接子组件使用
共享	Context、Zustand、Jotai	状态由多个互不相关的组件共享
服务端	TanStack Query、SWR	从 API 获取数据，需要缓存或重新验证
表单	React Hook Form、Formik	需要验证和提交的复杂表单
URL	搜索参数、路由器状态	应可加入书签或分享的状态

选择启发式

1. 从 useState 开始 — 只有遇到实际限制时才升级
2. 如果属性逐层传递超过 2 层，考虑使用 Context 或状态库
3. 如果要缓存 API 响应，请使用服务端状态库（不要用 Redux 管理服务端状态）
4. 对于字段数超过 3 个且需要验证的表单，请使用表单库

性能优化清单

技术	适用时机
React.lazy() + Suspense	路由级代码拆分
在图像上使用 loading="lazy"	首屏以下的图像
虚拟化	项目数超过 50 的列表
useMemo	开销较大的计算
useCallback	传递给已记忆子组件的回调
动态 import()	按条件加载的大型库
WebP/AVIF 图像	所有图像资源
为图像明确指定 width/height	防止布局偏移

设计系统集成

设计令牌 — 定义基础值，而非硬编码：

const tokens = {
  color: { primary: '#2563eb', secondary: '#64748b', error: '#dc2626' },
  spacing: { xs: '0.25rem', sm: '0.5rem', md: '1rem', lg: '1.5rem', xl: '2rem' },
  typography: { fontFamily: { sans: 'Inter, system-ui, sans-serif' } },
};

组件变体 — 保持变体 API 一致：

<Button variant="primary" size="md">Save</Button>
<Button variant="outline" size="sm">Cancel</Button>

主题支持：

• 使用 CSS 自定义属性支持运行时主题切换
• 至少支持浅色和深色主题
• 默认遵循 prefers-color-scheme
• 允许用户覆盖，并将设置存储在 localStorage 中

设计完成后停止 — 提交完整的组件规格说明以供审核。

反模式 / 常见错误

错误	错误原因	应采取的做法
使用 <div onClick> 而不是 <button>	无法通过键盘访问，也没有屏幕阅读器语义	使用语义化 HTML 元素
使用 outline: none，但不提供替代样式	键盘用户看不到焦点	换成可见的焦点样式
使用固定字号（px）	无法根据用户偏好缩放	使用 rem 和 clamp()
通过 4 层以上逐层传递 props	维护起来十分困难	使用 Context 或状态库
使用 useEffect + useState 获取数据	没有缓存、不会去重，还可能出现竞态条件	使用 TanStack Query 或 SWR
过早进行记忆化	未经测量便增加了复杂性	先进行性能分析，再优化测得的瓶颈
采用桌面优先的响应式设计	移动端体验成了事后考虑	从移动端优先开始，再逐步增加复杂性
只用颜色传达信息	色盲用户无法获取信息	添加图标、图案或文字标签
没有加载 / 错误状态	用户会看到空白屏幕或难以理解的错误	设计加载、错误和空状态

防止自我合理化

• 不要忽略无障碍要求 —— WCAG 2.1 AA 是最低标准，不是可选项
• 不要使用带有 onClick 的 <div>，而不使用语义化元素
• 不要跳过键盘导航测试
• 不要在了解实际需求之前选择状态管理方案
• 不要跳过发现阶段 —— 先了解约束条件
• 不要在测量之前优化性能

集成点

技能	关系
api-design	上游：API 响应结构决定组件的数据需求
spec-writing	上游：规格定义组件的行为要求
planning	下游：组件设计转化为实现任务
test-driven-development	下游：组件规格驱动测试优先的实现
senior-frontend	并行：提供 React/Next.js 专项知识
ui-ux-pro-max	上游：UX 设计为组件需求提供依据
ui-design-system	并行：设计系统令牌用于组件样式设计
performance-optimization	下游：实现后进行性能分析和优化

验证关卡

在宣称 UI 设计已完成之前：

1. 验证已明确选择组件架构模式并说明理由
2. 验证已为所有目标断点定义响应式行为
3. 验证已明确无障碍要求（WCAG 级别、键盘、颜色对比度）
4. 验证已根据实际需求选择状态管理方案
5. 验证已设计加载、错误和空状态
6. 验证用户已批准组件规格

技能类型

灵活 — 根据项目框架和约束调整组件模式、响应式策略和状态管理，同时满足无障碍要求，并坚持先发现后设计的方法。