Back to Details

specify

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Specify — Bridge Design to Engineering

Specify — 搭建设计与工程的桥梁

Overview

概述

This skill transforms design work into actionable, implementation-ready documentation. It produces structured specs, asset packages, test plans, and stakeholder presentations that ensure design intent survives to production. Use this when design needs to move into engineering, when cross-functional clarity is required, or when you must document decisions in a way that prevents rework.
本Skill将设计成果转化为可落地、便于实施的文档。它生成结构化规格说明、资产包、测试计划和利益相关方演示材料，确保设计意图能在生产环节中得以保留。当设计需要移交至工程团队、需要跨职能协作的清晰指引，或者需要以避免返工的方式记录决策时，即可使用本Skill。

Skill family

Skill家族

Specify works alongside the full Intent skill system:
  • /strategize
    : Their briefs and hypotheses provide the "why" behind everything you specify. Every spec should trace back to a strategic intent — why this feature exists, what hypothesis it tests, what user need it serves.
  • /investigate
    : Their research findings ground your use cases in evidence. Real user quotes, observed behaviors, and validated pain points make specs persuasive and accurate, not hypothetical.
  • /blueprint
    : Their system architecture constrains and informs your specs. Service dependencies, data flows, and technical constraints shape what's possible and what needs engineering discussion.
  • /journey
    : Their flows are what you're specifying — screen sequences, interaction transitions, state changes. Journey designs the experience; specify documents it for implementation.
  • /organize
    : Their information architecture informs your navigation specs. Taxonomy, hierarchy, and labeling decisions from organize become the structural backbone of your screen specs.
  • /articulate
    : Their copy work feeds directly into your copy matrices. Voice, tone, and content strategy decisions become specific strings in your spec.
  • /fortify
    : Their edge case analysis becomes part of your spec. Error states, failure modes, boundary conditions, and recovery patterns — all documented screen by screen.
  • /include
    : Their accessibility requirements go into every screen spec. ARIA labels, keyboard navigation, color contrast, screen reader behavior — inclusion is not an appendix, it's woven into every screen.
  • /evaluate
    : Their assessment identifies gaps in your specs. Heuristic violations, usability issues, and anti-pattern flags become items to resolve before handoff.
  • /measure
    : Their success metrics define your test plan criteria. Every feature spec should include what success looks like, how to measure it, and what to instrument.
  • /philosopher
    : A cross-cutting cognitive mode for when specification reveals deeper problems. Invoke when: edge cases keep multiplying, something about the design feels fragile under real conditions, the "pending questions" section keeps growing, or the user says "sit with this", "brainstorm", or "what could go wrong that nobody has imagined?" The philosopher helps think through failure scenarios nobody has considered and whether the spec is documenting the right thing.
Specify与完整的Intent Skill系统协同工作：
  • /strategize
    ：其提供的简报和假设为所有规格说明奠定了“为什么”的基础。每一份规格说明都应追溯至战略意图——该功能为何存在、要验证什么假设、满足用户的什么需求。
  • /investigate
    ：其研究发现让你的用例具备实证支撑。真实用户引用、观察到的行为以及已验证的痛点，让规格说明更具说服力和准确性，而非凭空假设。
  • /blueprint
    ：其系统架构对规格说明形成约束并提供参考。服务依赖关系、数据流和技术限制决定了可行性，以及需要与工程团队讨论的内容。
  • /journey
    ：其设计的流程正是你要记录的内容——屏幕序列、交互过渡、状态变化。Journey负责设计体验，而Specify负责将其文档化以便实施。
  • /organize
    ：其信息架构为导航规格说明提供依据。Organize中确定的分类法、层级结构和标签规则，成为屏幕规格说明的结构核心。
  • /articulate
    ：其撰写的文案直接为文案矩阵提供内容。语气、语调及内容策略决策，会转化为规格说明中的具体文本内容。
  • /fortify
    ：其分析的边缘案例会纳入规格说明。错误状态、故障模式、边界条件和恢复模式——所有内容都会逐屏记录。
  • /include
    ：其提出的无障碍要求会融入每一份屏幕规格说明。ARIA标签、键盘导航、色彩对比度、屏幕阅读器行为——包容性并非附录，而是贯穿每一个屏幕设计。
  • /evaluate
    ：其评估会指出规格说明中的漏洞。启发式违规、可用性问题和反模式标记，会成为交接前需要解决的事项。
  • /measure
    ：其定义的成功指标为测试计划标准提供依据。每一份功能规格说明都应包含成功的定义、衡量方式以及需要监测的内容。
  • /philosopher
    ：这是一种跨领域的认知模式，用于当规格说明暴露出更深层次问题时。触发场景包括：边缘案例不断增加、设计在实际场景中显得脆弱、“待解决问题”部分持续变长，或者用户说出“深入思考一下”“头脑风暴”“有没有什么没人想到的潜在风险？”等指令时。Philosopher有助于梳理没人考虑过的故障场景，以及判断规格说明是否记录了正确的内容。

Core capabilities

核心能力

1. Detailed design specifications

1. 详细设计规格说明

Write comprehensive, screen-by-screen (or state-by-state) specifications that document:
  • Visual design with specific measurements, colors, typography, spacing
  • Interaction logic: what triggers what, in what order, with what conditions
  • Copy: exact text, variants for different contexts/markets/edge cases
  • States: default, hover, active, error, loading, empty, success — all documented visually and logically
  • Constraints: device sizes, performance requirements, accessibility needs
Output should be a living spec document (HTML or markdown) that engineers can reference during implementation without guessing.
撰写全面的、逐屏（或逐状态）的规格说明，记录以下内容：
  • 视觉设计：具体尺寸、颜色、排版、间距
  • 交互逻辑：触发条件、顺序、前置条件
  • 文案：精确文本，以及针对不同场景/市场/边缘案例的变体
  • 状态：默认、悬停、激活、错误、加载、空态、成功——所有状态均需可视化和逻辑化记录
  • 约束条件：设备尺寸、性能要求、无障碍需求
输出应为可动态更新的规格说明文档（HTML或markdown格式），供工程师在实施过程中参考，无需自行猜测。

2. Organized engineering handoff packages

2. 结构化工程交接包

Structure deliverables so engineering knows exactly what to build and why:
  • Clear ownership: who decided what and when
  • Problem context: what user need or business problem does this solve
  • Design approach: constraints considered, alternatives rejected and why
  • Use cases: specific, not generic — real user scenarios that expose edge cases
  • Assets: all files organized, named, versioned, with usage notes
  • Test criteria: success metrics and audience-specific test plans
整理交付物，让工程团队明确知道要构建什么以及原因：
  • 清晰的所有权：谁在何时做出了什么决策
  • 问题背景：解决了用户的什么需求或业务问题
  • 设计思路：考虑过的约束条件、被否决的方案及原因
  • 用例：具体而非泛化——能暴露边缘案例的真实用户场景
  • 资产：所有文件均已整理、命名、版本化，并附有使用说明
  • 测试标准：成功指标及针对特定受众的测试计划

3. Copy and variant matrices

3. 文案与变体矩阵

Document all copy variations in one place:
  • Primary copy vs. secondary copy vs. microcopy (labels, hints, errors, empty states)
  • Market variants: tone shifts, cultural considerations, regulatory language
  • Edge cases: character limits, long strings, very short strings, numeric edge cases
  • A/B test variations: explicit copy changes being tested, with success criteria
在一处集中记录所有文案变体：
  • 主文案、次要文案与微文案（标签、提示、错误提示、空态文本）
  • 市场变体：语气调整、文化考量、合规性语言
  • 边缘案例：字符限制、长文本、极短文本、数值边界情况
  • A/B测试变体：明确记录测试的文案变更及成功标准

4. Interactive HTML specification documentation

4. 交互式HTML规格说明文档

When appropriate, produce interactive HTML specs that:
  • Show designs inline with explanatory text
  • Link related screens and decisions
  • Include collapsible reference sections (component specs, copy matrices, test plans)
  • Are self-contained and viewable in any browser without external dependencies
在合适情况下，生成交互式HTML规格说明，具备以下特性：
  • 设计内容与解释性文本内联展示
  • 关联相关屏幕和决策
  • 包含可折叠的参考章节（组件规格说明、文案矩阵、测试计划）
  • 独立封装，可在任何浏览器中查看，无需外部依赖

5. Use case and edge case documentation

5. 用例与边缘案例文档

Write out specific, not generic use cases:
  • "First-time user creating an account" vs. "User logs in"
  • "Network timeout during payment" vs. "Error state"
  • "User has 200+ items in cart" vs. "User has items in cart"
  • Document how the design behaves in each case, what copy appears, what happens next
撰写具体而非泛化的用例：
  • “首次用户创建账户”而非“用户登录”
  • “支付过程中网络超时”而非“错误状态”
  • “购物车中有200+商品”而非“购物车中有商品”
  • 记录每种场景下的设计表现、显示的文案以及后续流程

6. Stakeholder presentations

6. 利益相关方演示材料

Structure presentations that align cross-functional teams:
  • Problem statement (from 
    /strategize
    )
  • Design approach and constraints considered
  • Key decisions and what was intentionally NOT done
  • Test plan: what we're measuring and why (from 
    /measure
    )
  • Open questions: what we still need to resolve
  • Timeline and dependencies
构建用于协调跨职能团队的演示材料：
  • 问题陈述（来自
    /strategize
    ）
  • 设计思路及考虑的约束条件
  • 关键决策及有意未做的事项
  • 测试计划：要衡量的内容及原因（来自
    /measure
    ）
  • 待解决问题：仍需明确的事项
  • 时间线与依赖关系

7. Test plans with success criteria

7. 带成功标准的测试计划

Write test plans that pair observations with decision-makers:
  • Who needs to see this work (PM, engineering lead, CEO?)
  • What success looks like: specific, measurable outcomes (connected to 
    /measure
    GSM chains)
  • What we're learning and why we're learning it
  • How results feed back into design iteration
撰写将观察结果与决策人关联的测试计划：
  • 需要查看成果的人员（产品经理、工程负责人、CEO等）
  • 成功的定义：具体、可衡量的结果（与
    /measure
    的GSM链条关联）
  • 要学习的内容及原因
  • 结果如何反馈至设计迭代

Output format template

输出格式模板

Follow this structure for comprehensive handoffs:
undefined
遵循以下结构完成全面交接：
undefined

Ownership & Context

所有权与背景

  • Owner: [Name, role]
  • Created: [Date]
  • Status: [Draft/Ready for Engineering/In Implementation]
  • Design document version: [v0.1, etc.]
  • 负责人：[姓名，角色]
  • 创建日期：[日期]
  • 状态：[草稿/待工程团队接收/实施中]
  • 设计文档版本：[v0.1等]

Problem & User Need

问题与用户需求

[1-2 paragraphs: what problem does this solve, for whom, why now]
[1-2段：解决了什么问题、面向谁、为何此时解决]

Design Approach

设计思路

  • Constraints considered: [device, performance, accessibility, brand, etc.]
  • Design strategy: [how we approached the problem]
  • What we did NOT do (and why): [alternatives considered and rejected]
  • 考虑的约束条件：[设备、性能、无障碍、品牌等]
  • 设计策略：[解决问题的方式]
  • 未做的事项及原因：[考虑过但被否决的方案]

UX Questions Answered

已解答的UX问题

[List specific design questions this spec resolves, e.g.:
  • How does the user know this action succeeded?
  • What happens if the API returns no results?
  • How do we handle very long titles?]
[列出本规格说明解决的具体设计问题，例如：
  • 用户如何知道操作成功？
  • API无结果返回时怎么办？
  • 如何处理超长标题？]

Ethical Review

伦理审查

[Before handoff, check the design against Intent's anti-pattern catalog:]
  • Patterns reviewed: [list specific interaction patterns checked]
  • Potential concerns: [any patterns that could be perceived as manipulative]
  • Design intent documentation: [for each concern, document the intent behind the decision and why it serves user interest]
  • Dark pattern clearance: [explicit statement that the design was reviewed and does not employ deceptive, coercive, or manipulative patterns]
[交接前，对照Intent的反模式目录检查设计：]
  • 已审查模式：[列出检查的具体交互模式]
  • 潜在问题：[任何可能被视为操纵性的模式]
  • 设计意图记录：[针对每个问题，记录决策背后的意图及为何符合用户利益]
  • 反模式清除确认：[明确说明设计已通过审查，未采用欺骗、强制或操纵性模式]

Measurement

度量标准

[Connected to /measure's success criteria:]
  • Primary success metric: [from GSM mapping]
  • Counter-metrics: [what must NOT get worse]
  • Instrumentation needs: [what events/data engineering needs to capture]
  • Learning plan: [when to check metrics post-launch — day 1, week 1, month 1]
[与/measure的成功标准关联：]
  • 主要成功指标：[来自GSM映射]
  • 反向指标：[哪些指标不能恶化]
  • 监测需求：[工程团队需要捕获的事件/数据]
  • 学习计划：[上线后何时检查指标——第1天、第1周、第1个月]

Design Specification

设计规格说明

Screen [Name/ID]

屏幕[名称/ID]

Intent: [Why does this screen exist? What user need does it serve? What happens if we remove it?]
Behavior: [What does the user see and what can they do?]
Layout & Styling:
  • [Specific measurements, spacing, colors, fonts]
  • [Visual hierarchy and grid placement]
Copy:
  • Headline: "[Exact copy]"
  • Description: "[Exact copy]"
  • Button label: "[Exact copy]"
  • Error state: "[Exact copy]"
  • Empty state: "[Exact copy]"
Interaction Logic:
  • On load: [what happens]
  • On user action [X]: [expected outcome]
  • On error [Y]: [fallback behavior and messaging]
Accessibility:
  • ARIA labels: [if needed]
  • Keyboard navigation: [if needed]
  • Color contrast: [ratios if non-standard]
States: [Visual and copy documentation for default, hover, active, error, loading, empty states]
[Repeat for each screen/state]
意图：[该屏幕为何存在？满足用户什么需求？移除它会有什么影响？]
行为：[用户看到什么、可以做什么？]
布局与样式：
  • [具体尺寸、间距、颜色、字体]
  • [视觉层级与网格位置]
文案：
  • 标题："[精确文案]"
  • 描述："[精确文案]"
  • 按钮标签："[精确文案]"
  • 错误状态："[精确文案]"
  • 空态："[精确文案]"
交互逻辑：
  • 加载时：[发生的操作]
  • 用户执行操作[X]时：[预期结果]
  • 出现错误[Y]时：[ fallback行为及提示信息]
无障碍：
  • ARIA标签：[如有需要]
  • 键盘导航：[如有需要]
  • 色彩对比度：[非标准情况需标注比例]
状态：[默认、悬停、激活、错误、加载、空态的可视化及文案记录]
[为每个屏幕/状态重复上述内容]

Use Cases & Variants

用例与变体

Use Case 1: [Specific scenario]

用例1：[具体场景]

[Describe the user journey, what they see at each step, what copy appears, what happens on success/failure]
[描述用户旅程、每一步看到的内容、显示的文案、成功/失败后的流程]

Use Case 2: [Specific scenario]

用例2：[具体场景]

[Repeat as needed; be specific, not generic]
[按需重复；需具体，避免泛化]

Copy Matrix

文案矩阵

ElementPrimaryEdge Case 1Edge Case 2Market Variant (DE)A/B Test Variant
Headline"[Copy]""[Copy]".........
[Repeat for each copy element]
元素主文案边缘案例1边缘案例2市场变体（德国）A/B测试变体
标题"[文案]""[文案]".........
[为每个文案元素重复]

Test Plan

测试计划

Audience 1: [PM / Engineering / End User]

受众1：[产品经理/工程团队/终端用户]

What we're testing: [Specific behavior] Success looks like: [Measurable outcome, connected to Measurement section] How we measure it: [method/tool]
测试内容：[具体行为] 成功标准：[可衡量的结果，与度量标准部分关联] 衡量方式：[方法/工具]

Audience 2: [Different audience]

受众2：[不同受众]

[Repeat as needed]
[按需重复]

Pending Questions

待解决问题

Design Questions

设计问题

  • [Question 1: impacts design decision]
  • [Question 2: impacts design decision]
  • [问题1：影响设计决策]
  • [问题2：影响设计决策]

Engineering Questions

工程问题

  • [Question 1: impacts implementation approach]
  • [Question 2: impacts implementation approach]
  • [问题1：影响实施方式]
  • [问题2：影响实施方式]

Assets & Deliverables

资产与交付物

Design files:
  • [Figma file name and link]
  • [Specific artboards/pages to reference]
Handoff package contents:
  • Design spec (this document)
  • Design files (Figma link)
  • Copy matrix (separate or embedded)
  • Test plan (separate or embedded)
  • [Any other assets]
File naming & organization:
  • [How files are named and organized in assets/]
  • [Version control approach if applicable]
设计文件：
  • [Figma文件名及链接]
  • [需参考的具体画板/页面]
交接包内容：
  • 设计规格说明（本文档）
  • 设计文件（Figma链接）
  • 文案矩阵（单独文件或嵌入本文档）
  • 测试计划（单独文件或嵌入本文档）
  • [其他资产]
文件命名与整理：
  • [资产文件夹中文件的命名及整理方式]
  • [适用的版本控制方法]

Appendix

附录

[Reference material: component specs referenced, design system tokens, brand guidelines excerpts, accessibility standards applied, etc.]

---
[参考材料：引用的组件规格说明、设计系统令牌、品牌指南节选、应用的无障碍标准等]

---

Quality checklist

质量检查清单

Before marking a handoff as complete, verify:
  • Every screen has a documented intent — why it exists and what user need it serves (no real estate tours)
  • All screens and states are visually documented
  • All copy is written out (no placeholders like "TBD")
  • All variants (markets, edge cases, A/B tests) are documented
  • Edge cases are addressed (empty states, errors, long content, network delays)
  • Pending questions are explicitly flagged (design + engineering)
  • Ownership is stated (who, when, status)
  • Test plan is included with specific success criteria
  • Assets are organized and named; their locations are documented
  • Open questions don't block engineering; they're flagged for parallel resolution
  • Copy matrix includes all variations needed for implementation
  • Interaction timing is specified where relevant (e.g., toast duration, animation speed, debounce intervals)
  • For A/B tests: both variants are documented side-by-side with explicit differences called out
  • Ethical review completed: design checked against anti-pattern catalog
  • Measurement section completed: success metrics, counter-metrics, and instrumentation needs documented
标记交接完成前，需验证以下内容：
  • 每个屏幕都有记录的意图——为何存在、满足用户什么需求（避免仅描述屏幕内容）
  • 所有屏幕和状态均已可视化记录
  • 所有文案均已明确写出（无“待确定”等占位符）
  • 所有变体（市场、边缘案例、A/B测试）均已记录
  • 边缘案例已处理（空态、错误、长内容、网络延迟）
  • 待解决问题已明确标记（设计+工程）
  • 已说明所有权（负责人、时间、状态）
  • 包含带具体成功标准的测试计划
  • 资产已整理并命名；其位置已记录
  • 待解决问题不会阻碍工程进展；已标记为并行解决事项
  • 文案矩阵包含实施所需的所有变体
  • 相关交互时序已明确（如提示框显示时长、动画速度、防抖间隔）
  • A/B测试：两个变体已并排记录，明确标注差异
  • 伦理审查已完成：对照反模式目录检查设计
  • 度量标准部分已完成：成功指标、反向指标及监测需求已记录

Voice and approach

语气与方法

Intent over inventory.
  • The biggest anti-pattern in design documentation is the "real estate tour" — describing what's on screen without explaining why it's there. "There's a button with rounded corners in the top left" is inventory. "The primary CTA is positioned at the top of the viewport because research showed 68% of users abandon this flow before scrolling — the action needs to be visible on arrival" is design rationale.
  • Every element in a spec should answer: why is this here? What problem does it solve for the user? What happens if we remove it?
  • Bad: "On load, display 'Create your first project' in Headline 2 (24px, Inter Medium)."
  • Good: "On load, display 'Create your first project' — new users in usability testing couldn't identify the starting action. This headline serves as the primary onboarding cue, using Headline 2 to establish it as the page's core instruction."
  • If you can't articulate the intent behind a design decision, flag it as an open question rather than documenting it as settled.
Structured and thorough, never bloated.
  • Say what matters. Omit generic descriptions that don't connect to user needs or design intent.
Clear cross-functional ownership.
  • Explicitly state who made each decision and why.
  • Call out constraints as design inputs, not limitations.
Raise open questions explicitly.
  • Don't hide uncertainty; flag it.
  • Distinguish between "design needs to decide" vs. "engineering needs to decide" vs. "requires data/research."
Visual + logical rules.
  • Show designs, then explain the reasoning behind them.
  • Make copy testable and implementable.
Treat constraints as design inputs.
  • Performance requirements, accessibility needs, brand guidelines — these shape the spec, so make them visible.
优先记录意图而非内容清单。
  • 设计文档中最大的反模式是“内容罗列”——仅描述屏幕上的元素，却不解释其存在的原因。“左上角有一个圆角按钮”属于内容罗列。“主要CTA按钮位于视口顶部，因为研究显示68%的用户在滚动前就会放弃该流程——操作需在用户进入页面时即可见”才是设计依据。
  • 规格说明中的每个元素都应回答：为何存在？为用户解决什么问题？移除它会有什么影响？
  • 反面示例：“加载时，显示‘创建你的第一个项目’，使用标题2样式（24px，Inter Medium）。”
  • 正面示例：“加载时，显示‘创建你的第一个项目’——可用性测试中，新用户无法识别起始操作。该标题作为主要引导提示，使用标题2样式以确立其为页面核心指令。”
  • 若无法清晰阐述设计决策的意图，应将其标记为待解决问题，而非当作已确定事项记录。
结构化且全面，避免冗余。
  • 只说重要内容。省略与用户需求或设计意图无关的泛化描述。
明确跨职能所有权。
  • 明确说明每个决策的制定者及原因。
  • 将约束条件视为设计输入，而非限制。
明确提出待解决问题。
  • 不要隐藏不确定性；要标记出来。
  • 区分“设计团队需决策”“工程团队需决策”“需数据/研究支持”。
视觉+逻辑规则。
  • 先展示设计，再解释背后的逻辑。
  • 让文案可测试、可实施。
将约束条件视为设计输入。
  • 性能要求、无障碍需求、品牌指南——这些都会影响规格说明，因此要明确呈现。

Scope boundaries

范围边界

This skill does:

本Skill可完成：

  • Document design decisions (don't make them)
  • Organize and structure existing design work for implementation
  • Write comprehensive specs, test plans, and asset packages
  • Produce cross-functional presentations and alignment documents
  • Flag open questions and dependencies transparently
  • Map edge cases and write copy variations
  • Conduct ethical review against Intent's anti-pattern catalog
  • Connect specs to measurement frameworks from 
    /measure
  • 记录设计决策（不制定决策）
  • 整理结构化现有设计成果以便实施
  • 撰写全面的规格说明、测试计划和资产包
  • 生成跨职能演示材料和对齐文档
  • 透明标记待解决问题和依赖关系
  • 梳理边缘案例并撰写文案变体
  • 对照Intent的反模式目录进行伦理审查
  • 将规格说明与
    /measure
    的度量框架关联

This skill does NOT:

本Skill不可完成：

  • Make design decisions (that's the designer's work)
  • Write code or implementation details
  • Conduct user research or validation (
    /investigate
    )
  • Design new features (that requires 
    /strategize
    or 
    /journey
    )
  • Provide implementation estimates (that's engineering's role)
  • Define success metrics from scratch (
    /measure
    owns metric selection)
  • Assess UX quality or heuristic compliance (
    /evaluate
    )
  • 制定设计决策（这是设计师的工作）
  • 编写代码或实施细节
  • 开展用户研究或验证（
    /investigate
    负责此部分）
  • 设计新功能（需要
    /strategize
    或
    /journey
    ）
  • 提供实施估算（这是工程团队的职责）
  • 从零定义成功指标（
    /measure
    负责指标选择）
  • 评估UX质量或启发式合规性（
    /evaluate
    负责此部分）

When to use this skill

使用时机

Trigger Specify when:
  • "Write the spec" — Comprehensive design specification needed
  • "Prepare the handoff" — Engineering needs everything ready to build
  • "Document this for engineering" — Translate design into actionable specs
  • "What do we need for the design review?" — Prepare materials for alignment meetings
  • "Build the test plan" — Define success criteria and test audiences
  • "Write the copy matrix" — Document all variations in one place
  • "What are the edge cases?" — Design scenarios and copy for unusual situations
  • "Create a design package" — Assemble spec, assets, and documentation
  • "For engineering" or "for implementation" — Any handoff context
Not all sections are required for every handoff. Use what serves the project and audience.
在以下场景触发Specify：
  • “撰写规格说明”——需要全面的设计规格说明
  • “准备交接材料”——工程团队需要所有可用于开发的材料
  • “为工程团队撰写文档”——将设计转化为可落地的规格说明
  • “设计评审需要准备什么？”——准备对齐会议材料
  • “制定测试计划”——定义成功标准和测试受众
  • “撰写文案矩阵”——在一处集中记录所有变体
  • “边缘案例有哪些？”——为特殊场景设计流程和文案
  • “创建设计包”——整理规格说明、资产和文档
  • “供工程团队使用”或“用于实施”——任何交接场景
并非所有部分都适用于每次交接。根据项目和受众需求选择使用即可。