Back to Details

design-engineering

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Design Engineering

设计工程

Scope

适用范围

Covers
  • Defining a Design Engineering function (hybrid design sensibility + ability to ship production code)
  • Choosing an operating model: embedded vs platform/design-system vs tiger team
  • Creating a prototype → production pipeline (what is throwaway vs shippable)
  • Establishing a design-to-code contract (tokens, components, reviews, quality bar)
  • Planning delivery for UI/UX-heavy work (components/flows, milestones, QA gates)
When to use
  • “We want to create a design engineering function—write the charter and operating model.”
  • “Our prototypes never make it to production—define a prototype→production workflow.”
  • “We need faster UI iteration with high craft—set a design-to-code contract + quality bar.”
  • “We’re building a new UI/component library—create a component delivery plan and reviews.”
When NOT to use
  • You need UX research, discovery, or product strategy (use interviews/surveys/PRD skills)
  • You’re doing mostly backend/platform architecture with minimal UI surface area
  • You only need to ship a single small UI fix (just implement it)
  • You need a brand/visual identity system (separate design/brand process)
涵盖内容
  • 定义Design Engineering职能（兼具设计敏感度与交付生产代码的能力）
  • 选择运营模式：embedded、platform/design-system或tiger team
  • 建立原型→生产流水线（明确可丢弃原型与可交付原型的区别）
  • 制定设计转代码契约（设计令牌、组件、评审、质量标准）
  • 规划UI/UX相关工作的交付（组件/流程、里程碑、QA关卡）
适用场景
  • “我们想要创建Design Engineering职能——撰写章程和运营模式。”
  • “我们的原型永远无法落地到生产环境——定义原型→生产工作流。”
  • “我们需要在保证高工艺水准的前提下加快UI迭代速度——制定设计转代码契约+质量标准。”
  • “我们正在构建新的UI/组件库——创建组件交付计划和评审机制。”
不适用场景
  • 你需要UX研究、发现或产品策略（使用访谈/调研/PRD技能）
  • 你的工作以后端/平台架构为主，UI界面占比极小
  • 你只需要交付一个小型UI修复（直接实现即可）
  • 你需要品牌/视觉识别系统（采用独立的设计/品牌流程）

Inputs

输入信息

Minimum required
  • Product/context: what you’re building and who it’s for
  • Current state: design artifacts (Figma, mockups) + codebase/stack (web/native) + existing design system (if any)
  • Goal: what “better” means (speed, consistency, craft, accessibility, quality, fewer handoff bugs)
  • Constraints: team composition, timeline, quality bar, accessibility/compliance requirements
Missing-info strategy
  • Ask up to 5 questions from references/INTAKE.md, then proceed with explicit assumptions.
  • If the team/stack is unknown, assume a modern web stack (component library + CI) and call out assumptions.
  • Do not request secrets/credentials; use redacted identifiers.
最低要求
  • 产品/背景：你正在构建的产品以及目标用户
  • 当前状态：设计产物（Figma、原型图）+ 代码库/技术栈（Web/原生）+ 现有设计系统（如有）
  • 目标：“更好”的定义（速度、一致性、工艺水准、可访问性、质量、更少的交接bug）
  • 约束条件：团队构成、时间线、质量标准、可访问性/合规要求
缺失信息处理策略
  • 从[references/INTAKE.md]中最多提出5个问题，然后基于明确的假设推进。
  • 如果团队/技术栈未知，假设采用现代Web技术栈（组件库+CI）并明确说明假设条件。
  • 不要请求机密/凭证信息；使用匿名标识符。

Outputs (deliverables)

输出成果（交付物）

Produce a Design Engineering Execution Pack in Markdown (in-chat by default; write to files if requested):
  1. Context snapshot (goals, constraints, success signals)
  2. Design Engineering charter (mission, scope, ownership boundaries, engagement model)
  3. Prototype → production workflow (prototype ladder + decision rules + review gates)
  4. Design-to-code contract (tokens/components/spec handoff, PR review expectations, QA)
  5. Component/flow delivery plan (prioritized backlog + milestones + owners)
  6. Quality bar (checklists + rubric score)
  7. Risks / Open questions / Next steps (always included)
Templates: references/TEMPLATES.md
生成Markdown格式的设计工程执行包（默认在对话中展示；如有需求可写入文件）：
  1. 背景快照（目标、约束条件、成功指标）
  2. Design Engineering章程（使命、范围、所有权边界、协作模式）
  3. 原型→生产工作流（原型阶梯+决策规则+评审关卡）
  4. 设计转代码契约（设计令牌/组件/规范交接、PR评审要求、QA标准）
  5. 组件/流程交付计划（优先级排序的待办事项+里程碑+负责人）
  6. 质量标准（检查清单+评分准则）
  7. 风险/未解决问题/下一步计划（必须包含）
模板：[references/TEMPLATES.md]

Workflow (7 steps)

工作流（7个步骤）

1) Intake + success definition

1) 信息收集 + 成功定义

  • Inputs: User context; references/INTAKE.md.
  • Actions: Confirm scope (product area), stakeholders, and what “design engineering” means here (role vs function vs project). Define success signals (e.g., faster UI iteration, fewer handoff bugs, higher consistency, improved accessibility).
  • Outputs: Context snapshot (draft).
  • Checks: The team can answer in one sentence: “What will change if we do this well?”
  • 输入：用户背景信息；[references/INTAKE.md]
  • 行动：确认范围（产品领域）、利益相关者，以及此处的“Design Engineering”指的是什么（角色vs职能vs项目）。定义成功指标（例如，更快的UI迭代、更少的交接bug、更高的一致性、提升的可访问性）。
  • 输出：背景快照（草稿）
  • 检查项：团队可以用一句话回答：“如果我们做好这件事，会有什么变化？”

2) Choose the operating model (and boundaries)

2) 选择运营模式（及边界）

  • Inputs: Team org, roadmap pressures, existing design/engineering capabilities.
  • Actions: Select an engagement model (embedded, platform/design system, tiger team). Define responsibilities and boundaries vs Design and Engineering (who owns interaction design, component implementation, accessibility, visual QA, performance).
  • Outputs: Design Engineering charter (draft) with explicit boundaries.
  • Checks: No “two owners” ambiguity for components, tokens, and UI quality sign-off.
  • 输入：团队组织架构、路线图压力、现有设计/工程能力
  • 行动：选择协作模式（embedded、platform/design-system、tiger team）。明确与设计团队和工程团队的职责与边界（谁负责交互设计、组件实现、可访问性、视觉QA、性能）。
  • 输出：Design Engineering章程（草稿），包含明确的边界定义
  • 检查项：组件、设计令牌和UI质量验收的所有权没有“双重归属”的模糊性

3) Map the UI surface area + constraints

3) 梳理UI界面范围 + 约束条件

  • Inputs: Key flows/screens; existing components; constraints (devices, browsers, perf, a11y, localization).
  • Actions: Inventory the highest-leverage UI areas (top flows, shared components). Identify reuse opportunities and risk hotspots (complex interactions, animations, data density, edge cases).
  • Outputs: UI surface map + initial component/flow backlog.
  • Checks: Backlog is prioritized by user impact and reuse (not just what’s loudest).
  • 输入：核心流程/界面；现有组件；约束条件（设备、浏览器、性能、a11y、本地化）
  • 行动：盘点最高价值的UI区域（核心流程、共享组件）。识别复用机会和风险点（复杂交互、动画、数据密度、边缘情况）。
  • 输出：UI界面地图 + 初始组件/流程待办事项
  • 检查项：待办事项根据用户影响和复用优先级排序（而非仅根据呼声高低）

4) Define the prototype ladder (prototype → production)

4) 定义原型阶梯（原型→生产）

  • Inputs: Timeline, iteration speed needs, risk tolerance.
  • Actions: Define a “prototype ladder” (lo-fi → hi-fi → coded prototype → production). For each rung, set purpose, expected fidelity, and whether it is disposable. Add decision rules for when to “graduate” a prototype.
  • Outputs: Prototype → production workflow (ladder + rules + gates).
  • Checks: Every prototype has an explicit label: throwaway vs shippable.
  • 输入：时间线、迭代速度需求、风险容忍度
  • 行动：定义“原型阶梯”（低保真→高保真→代码化原型→生产环境）。为每个层级设定目标、预期保真度，以及是否可丢弃。添加原型“升级”到下一层级的决策规则。
  • 输出：原型→生产工作流（阶梯+规则+关卡）
  • 检查项：每个原型都有明确标签：可丢弃 vs 可交付

5) Write the design-to-code contract (handoff + reviews)

5) 撰写设计转代码契约（交接+评审）

  • Inputs: Design artifacts; code conventions; QA expectations.
  • Actions: Define the contract: design tokens, component API expectations, states, a11y requirements, and review gates (design review, engineering review, QA). Specify what must be in a PR (screenshots, storybook links, test plan, a11y notes).
  • Outputs: Design-to-code contract (v1).
  • Checks: A developer can implement a component without back-and-forth on states, spacing/typography, and acceptance criteria.
  • 输入：设计产物；代码规范；QA预期
  • 行动：定义契约内容：设计令牌、组件API预期、状态、a11y要求，以及评审关卡（设计评审、工程评审、QA）。明确PR中必须包含的内容（截图、storybook链接、测试计划、a11y说明）。
  • 输出：设计转代码契约（v1版本）
  • 检查项：开发人员无需反复确认状态、间距/排版和验收标准即可实现组件

6) Plan delivery (milestones + ownership)

6) 规划交付（里程碑+所有权）

  • Inputs: Backlog + constraints + team capacity.
  • Actions: Convert backlog into milestones (thin slices) with owners, dependencies, and acceptance criteria. Define how work is tracked (board columns) and how design engineering work is staffed.
  • Outputs: Component/flow delivery plan (milestones).
  • Checks: First milestone is small enough to ship within 1–2 weeks and sets patterns for the rest.
  • 输入：待办事项 + 约束条件 + 团队产能
  • 行动：将待办事项转化为里程碑（小步迭代），明确负责人、依赖关系和验收标准。定义工作追踪方式（看板列）以及Design Engineering工作的人员配置方式。
  • 输出：组件/流程交付计划（里程碑）
  • 检查项：第一个里程碑足够小，可在1-2周内交付，并为后续工作设定模式

7) Quality gate + alignment + finalization

7) 质量关卡 + 对齐 + 最终定稿

  • Inputs: Draft pack.
  • Actions: Run references/CHECKLISTS.md and score with references/RUBRIC.md. Add stakeholder cadence and a lightweight decision log (what was chosen, why). Finalize Risks / Open questions / Next steps.
  • Outputs: Final Design Engineering Execution Pack.
  • Checks: Quality bar is explicit; ownership is unambiguous; risks and open questions are not hidden.
  • 输入：执行包草稿
  • 行动：使用[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

示例

Example 1 (stand up the function): “Use 
design-engineering
. We’re a 12-person product team. Web app. Designers ship Figma but engineering struggles with UI polish. Create a Design Engineering Execution Pack with an embedded model and a prototype→production workflow.”
Example 2 (design system delivery): “Create a design engineering plan for building a component library (buttons, inputs, tables, modals). Include the design-to-code contract, PR review checklist, and a 6-week milestone plan.”
Boundary example: “What is design engineering?”
Response: explain this skill produces an execution pack; ask for context (team, product, goals). If they only want a definition, give a brief definition and point them to the intake questions to proceed.
示例1（建立职能）：“使用
design-engineering
。我们是一个12人的产品团队，开发Web应用。设计师交付Figma文件，但工程团队在UI打磨上存在困难。创建一份采用embedded模式和原型→生产工作流的设计工程执行包。”
示例2（设计系统交付）：“为构建组件库（按钮、输入框、表格、模态框）创建设计工程计划。包含设计转代码契约、PR评审清单和6周里程碑计划。”
边界示例：“什么是Design Engineering？”
回复：说明本技能可生成执行包；询问背景信息（团队、产品、目标）。如果用户只需要定义，给出简短定义并引导他们查看输入问题以继续推进。