Back to Details

design-systems

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Design Systems

设计系统

Scope

适用范围

Covers
  • Creating or upgrading a design system (tokens + components + guidelines)
  • Using blockframes (lo-fi, system-aware wireframes) to lock logic before hi-fi execution
  • Designing a future-ready visual foundation (depth/elevation, motion, texture) without breaking consistency
  • Making the system easy for non-experts to use (guardrails, examples, starter templates)
  • Driving adoption + governance (contribution model, champions, release cadence)
When to use
  • “We need a design system / component library and a plan to build it.”
  • “Our UI is inconsistent—define tokens + components + documentation to standardize.”
  • “We want to refresh our UI style (more depth/texture/motion) without chaos.”
  • “We need to scale design across teams or support enterprise customers with customization.”
  • “We want faster hi-fi output by locking flows in lo-fi first.”
When NOT to use
  • You’re defining a brand identity or logo system (different process).
  • You need user research/discovery to decide what to build.
  • You only need to ship one isolated UI change (just implement it).
  • You’re doing pure front-end architecture unrelated to UI consistency.
涵盖内容
  • 创建或升级设计系统（令牌+组件+指南）
  • 使用blockframes（低保真、系统感知型线框图）在高保真实现前锁定逻辑
  • 设计面向未来的视觉基础（深度/层级、动效、纹理），同时不破坏一致性
  • 让系统便于非专业人士使用（防护规则、示例、入门模板）
  • 推动采用与治理（贡献模式、倡导者、发布节奏）
适用场景
  • “我们需要一套设计系统/组件库以及对应的构建计划。”
  • “我们的UI不一致——定义令牌+组件+文档来实现标准化。”
  • “我们想要刷新UI风格（增加更多深度/纹理/动效），同时避免混乱。”
  • “我们需要跨团队扩展设计能力，或支持企业客户的定制需求。”
  • “我们希望先通过低保真锁定流程，从而更快产出高保真成果。”
不适用场景
  • 你正在定义品牌标识或标志系统（属于不同流程）。
  • 你需要用户研究/探索来决定要构建什么。
  • 你只需要交付一个孤立的UI变更（直接实现即可）。
  • 你正在做与UI一致性无关的纯前端架构工作。

Inputs

输入要求

Minimum required
  • Product + surfaces: web/iOS/Android; key flows
  • Current state: existing UI kit/design system (if any), design tool (e.g., Figma), code stack (if relevant)
  • Goals: speed, consistency, accessibility, scalability, customization, enterprise adoption
  • Constraints: timeline, team ownership, level of engineering support, compliance/a11y needs
Missing-info strategy
  • Ask up to 5 questions from references/INTAKE.md, then proceed with explicit assumptions.
  • If platform/stack is unknown, assume a modern web product with a component library and design tokens.
  • Do not request secrets or credentials.
最低必填项
  • 产品与终端：Web/iOS/Android；核心流程
  • 当前状态：现有UI套件/设计系统（如有）、设计工具（如Figma）、技术栈（如相关）
  • 目标：速度、一致性、可访问性、可扩展性、定制化、企业级采用
  • 约束条件：时间线、团队所有权、工程支持程度、合规性/无障碍需求
缺失信息处理策略
  • 可从references/INTAKE.md中提出最多5个问题，之后基于明确假设推进。
  • 如果平台/技术栈未知，默认假设为带有组件库和设计令牌的现代Web产品。
  • 不得索要机密信息或凭证。

Outputs (deliverables)

输出成果（可交付物）

Produce a Design System Operating Pack in Markdown (in-chat by default; write to files if requested):
  1. Context snapshot (goals, constraints, success signals)
  2. Design system charter (mission, scope, principles, audiences, in/out)
  3. UI audit + operational blockers (what’s slowing teams down; what must standardize first)
  4. Blockframe-to-component map (lo-fi flows + mapping to components/tokens)
  5. Token model (taxonomy, naming rules, and initial token backlog—include elevation/depth)
  6. Component inventory + roadmap (tiers, prioritization, milestones)
  7. Documentation + enablement plan (non-designer-friendly, “teaches by structure”)
  8. Governance + adoption plan (contribution workflow, decision rights, champions, release cadence)
  9. Quality gate (checklists + rubric score) + Risks / Open questions / Next steps
Templates: references/TEMPLATES.md
生成Markdown格式的设计系统操作包（默认在对话中输出；如有需求可写入文件）：
  1. 环境快照（目标、约束条件、成功指标）
  2. 设计系统章程（使命、范围、原则、受众、包含/排除项）
  3. UI审计与运营障碍（拖慢团队效率的问题；必须优先标准化的内容）
  4. 框架到组件的映射（低保真流程+与组件/令牌的对应关系）
  5. 令牌模型（分类体系、命名规则、初始令牌待办事项——包含深度/层级）
  6. 组件清单与路线图（层级划分、优先级、里程碑）
  7. 文档与赋能计划（面向非设计师，“通过结构实现教学”）
  8. 治理与采用计划（贡献工作流、决策权限、倡导者、发布节奏）
  9. 质量校验（检查清单+评分标准）+ 风险/未解决问题/下一步行动
模板：references/TEMPLATES.md

Workflow (7 steps)

工作流程（7个步骤）

1) Intake + success definition (who is this for?)

1) 需求收集与成功定义（面向谁？）

  • Inputs: User context; references/INTAKE.md.
  • Actions: Confirm primary users of the system (designers, engineers, PMs, “non-designers”). Define success signals (cycle time, consistency, adoption, fewer UI bugs, faster onboarding).
  • Outputs: Context snapshot (draft).
  • Checks: Success is measurable or at least falsifiable (e.g., “80% of new screens use system components”).
  • 输入：用户上下文；references/INTAKE.md。
  • 行动：确认系统的核心用户（设计师、工程师、产品经理、“非设计师”）。定义成功指标（周期时间、一致性、采用率、UI bug减少、入职速度）。
  • 输出：环境快照（草稿）。
  • 校验：成功指标可衡量或至少可证伪（如“80%的新页面使用系统组件”）。

2) Audit the current UI and find the operational “hook”

2) 审计当前UI并找到运营“突破口”

  • Inputs: Screens/flows, existing components, pain points, enterprise needs (if any).
  • Actions: Inventory inconsistencies (spacing/type/color/components), identify the operational blocker the system will remove (e.g., slow production, inconsistent UI, customization needs). Choose the first high-leverage slice.
  • Outputs: UI audit + operational blockers list; initial scope slice.
  • Checks: The first slice is narrow enough to ship but broad enough to set patterns.
  • 输入：页面/流程、现有组件、痛点、企业需求（如有）。
  • 行动：盘点不一致之处（间距/字体/颜色/组件），识别系统将解决的运营障碍（如生产速度慢、UI不一致、定制需求）。选择首个高价值切入点。
  • 输出：UI审计与运营障碍清单；初始范围切入点。
  • 校验：首个切入点范围足够窄以便快速交付，同时足够宽以奠定模式基础。

3) Lock logic with blockframes (separate thinking from styling)

3) 用blockframes锁定逻辑（将思考与样式分离）

  • Inputs: Key flows; current IA; constraints.
  • Actions: Create or specify “blockframes” (lo-fi, system-aware wireframes). Map each block to intended components and token usage so hi-fi execution becomes faster and more consistent.
  • Outputs: Blockframe-to-component map (v1).
  • Checks: A reviewer can validate flow/IA without debating visual details.
  • 输入：核心流程；当前信息架构；约束条件。
  • 行动：创建或指定“blockframes”（低保真、系统感知型线框图）。将每个模块映射到对应的组件和令牌使用方式，让高保真实现更快速、更一致。
  • 输出：框架到组件的映射（v1版本）。
  • 校验：审核者无需讨论视觉细节即可验证流程/信息架构。

4) Define the token model (make the future style changeable)

4) 定义令牌模型（让未来风格可修改）

  • Inputs: Brand constraints, accessibility targets, desired direction (e.g., depth/texture/motion).
  • Actions: Define token taxonomy + naming; include elevation/depth and state tokens. If doing a visual refresh, design the token model so style can evolve without rewriting components.
  • Outputs: Token model + token backlog (v1).
  • Checks: Tokens support theming and states; accessibility constraints are addressed (contrast, focus, motion).
  • 输入：品牌约束、无障碍目标、期望方向（如深度/纹理/动效）。
  • 行动：定义令牌分类体系与命名规则；包含深度/层级和状态令牌。如果是视觉刷新，设计令牌模型以便无需重写组件即可迭代风格。
  • 输出：令牌模型+令牌待办事项（v1版本）。
  • 校验：令牌支持主题切换和状态变化；满足无障碍约束（对比度、焦点、动效）。

5) Define the component model + delivery plan

5) 定义组件模型与交付计划

  • Inputs: Audit + blockframes + token model; engineering constraints.
  • Actions: Tier components (primitives → composites → patterns). Prioritize by reuse and user impact. Define milestones, owners, and acceptance criteria.
  • Outputs: Component inventory + roadmap (milestones).
  • Checks: Milestone 1 ships within 1–2 weeks and establishes “golden path” patterns.
  • 输入：审计结果+blockframes+令牌模型；工程约束条件。
  • 行动：对组件进行层级划分（基础组件→复合组件→模式组件）。按复用率和用户影响优先级排序。定义里程碑、负责人和验收标准。
  • 输出：组件清单与路线图（里程碑）。
  • 校验：第一个里程碑可在1-2周内交付，并确立“黄金路径”模式。

6) Make it easy to use (guardrails for non-experts)

6) 提升易用性（为非专业人士提供防护规则）

  • Inputs: Target user types; common mistakes; documentation needs.
  • Actions: Design documentation and component guidelines so they “teach by structure”: sensible defaults, constrained options, examples, do/don’t. Provide starter templates for common layouts.
  • Outputs: Documentation + enablement plan (v1).
  • Checks: A non-expert can assemble a consistent screen using templates with minimal training.
  • 输入：目标用户类型；常见错误；文档需求。
  • 行动：设计文档和组件指南，通过“结构实现教学”：合理默认值、受限选项、示例、注意事项。提供常见布局的入门模板。
  • 输出：文档与赋能计划（v1版本）。
  • 校验：非专业人士可使用模板组装出一致的页面，且只需极少培训。

7) Governance + adoption + quality gate

7) 治理、采用与质量校验

  • Inputs: Draft pack; stakeholder map; toolchain (Figma/Storybook/etc.).
  • Actions: Define decision rights, contribution workflow, review gates, and release cadence. Create a champion/office-hours plan to drive adoption. Run references/CHECKLISTS.md and score with references/RUBRIC.md. Finalize Risks / Open questions / Next steps.
  • Outputs: Final Design System Operating Pack.
  • Checks: Ownership is unambiguous; adoption plan exists; quality bar is explicit and repeatable.
  • 输入：草稿包；利益相关者图谱；工具链（Figma/Storybook等）。
  • 行动：定义决策权限、贡献工作流、审核关卡和发布节奏。制定倡导者/办公时间计划以推动采用。使用references/CHECKLISTS.md并通过references/RUBRIC.md评分。最终确定风险/未解决问题/下一步行动。
  • 输出：最终版设计系统操作包。
  • 校验：所有权明确；存在采用计划；质量标准清晰且可重复。

Quality gate (required)

质量校验（必填）

  • Use references/CHECKLISTS.md and references/RUBRIC.md.
  • Always include: Risks, Open questions, Next steps.
  • 使用references/CHECKLISTS.md和references/RUBRIC.md。
  • 必须包含：风险、未解决问题、下一步行动。

Examples

示例

See references/EXAMPLES.md.
详见references/EXAMPLES.md。