Design Systems (Deep Workflow)
A design system is shared UI infrastructure: tokens, components, patterns, and governance so products feel cohesive without freezing innovation.
When to Offer This Workflow
Trigger conditions:
- - Multiple apps diverging visually; mounting accessibility debt
- Launching or rebooting a component library; token refresh
- Figma and production code drifting apart
Initial offer:
Use six stages: (1) strategy & principles, (2) design tokens, (3) components & API, (4) accessibility & content, (5) docs & tooling, (6) governance & adoption). Confirm framework (React/Vue/Svelte) and design tooling.
Stage 1: Strategy & Principles
Goal: Why the system exists (speed, a11y, brand); explicit non-goals (not every pixel must be centralized).
Exit condition: One-page principles: density, tone, motion philosophy.
Stage 2: Design Tokens
Goal: Semantic color, type, space, radius, motion—names like surface.default instead of raw hex everywhere.
Practices
- - Plan light/dark and density themes early
Stage 3: Components & API
Goal: Composable primitives vs bloated “kitchen sink” widgets; stable props API with semver discipline.
Practices
- - Prefer composition / slots over prop explosion
Stage 4: Accessibility & Content
Goal: WCAG baseline per component: focus rings, labels, error patterns, live regions where needed.
Stage 5: Docs & Tooling
Goal: Storybook or equivalent; usage guidelines; code snippets; do/don’t examples.
Stage 6: Governance & Adoption
Goal: Contribution guide; deprecation policy; champions or office hours per product line.
Final Review Checklist
- - [ ] Strategy and principles agreed
- [ ] Token layer semantic and themeable
- [ ] Component APIs stable and composable
- [ ] Accessibility baseline per component
- [ ] Documentation and live examples
- [ ] Contribution and deprecation governance
Tips for Effective Guidance
- - Figma ↔ code parity needs owners and a sync cadence.
- Do not ship a component without keyboard and screen-reader checks.
Handling Deviations
- - Small teams: start with tokens + a few primitives—defer full catalog.
设计系统(深度工作流)
设计系统是共享的UI基础设施:令牌、组件、模式及治理机制,使产品在保持凝聚力的同时不冻结创新。
何时提供此工作流
触发条件:
- - 多个应用视觉风格分化;无障碍债务累积
- 启动或重构组件库;令牌更新
- Figma与生产代码逐渐脱节
初始提供:
使用六个阶段:(1) 策略与原则,(2) 设计令牌,(3) 组件与API,(4) 无障碍与内容,(5) 文档与工具,(6) 治理与采纳。确认框架(React/Vue/Svelte)和设计工具。
阶段1:策略与原则
目标: 系统存在的原因(速度、无障碍、品牌);明确非目标(并非每个像素都必须集中管控)。
退出条件: 一页原则文档:密度、调性、动效理念。
阶段2:设计令牌
目标: 语义化的颜色、字体、间距、圆角、动效——使用如surface.default的命名,而非到处使用原始十六进制值。
实践
阶段3:组件与API
目标: 可组合的原语 vs 臃肿的大杂烩组件;遵循语义化版本规范的稳定props API。
实践
阶段4:无障碍与内容
目标: 每个组件满足WCAG基线:焦点环、标签、错误模式、必要的实时区域。
阶段5:文档与工具
目标: Storybook或等效工具;使用指南;代码片段;正确/错误示例。
阶段6:治理与采纳
目标: 贡献指南;弃用策略;每条产品线的负责人或答疑时间。
最终审查清单
- - [ ] 策略与原则已达成一致
- [ ] 令牌层具备语义化且可主题化
- [ ] 组件API稳定且可组合
- [ ] 每个组件具备无障碍基线
- [ ] 文档与实时示例
- [ ] 贡献与弃用治理机制
有效指导技巧
- - Figma ↔ 代码一致性需要负责人和同步节奏。
- 未经键盘和屏幕阅读器检查的组件不得发布。
偏差处理
- - 小团队:从令牌和少量原语开始——推迟完整目录建设。