product-design

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Product Design

产品设计

Decide what the interface should do, then route who builds and verifies it: pick the right interaction, make scope and consequence clear, cover reality beyond the happy path. This skill owns the decision; it routes the build, verification, and copy out (ownership map in Related skills).

IS: the decision layer. From a brief, spec, mockup, intent, or existing UI: choose the right interaction and control, name the object, scope, and consequence of actions, enumerate every reachable state, set resilience expectations, require accessibility as task completion. It decides, then routes build and verification out.
IS NOT:
- building or styling UI, visual direction, palettes, type: use
```
ui-design
```
  .
- auditing the built result (rendered quality, a11y markup, keyboard, layout, performance, type surface, React/Next code-level UX with a ship verdict): use
```
ui-design
```
  Audit mode.
- copy wording, persuasion, or AI-ism removal: use
```
copywriting
```
  .
- deep typography or motion: use
```
typography-audit
```
  or
```
ui-animation
```
  .

确定界面应具备的功能，然后分配对应的构建与验证工作：选择合适的交互方式，明确操作范围与后果，覆盖常规路径之外的实际场景。本技能负责决策，然后将构建、验证和文案工作分配给对应技能（相关技能的职责划分见“相关技能”部分）。

负责范畴： 决策层。基于简报、规格文档、原型图、需求意图或现有UI：选择合适的交互方式与控件，定义操作的对象、范围和后果，列举所有可达状态，设定韧性要求，将可访问性作为任务完成的必备条件。完成决策后，将构建与验证工作分配给对应技能。
不负责范畴：
- UI的构建或样式设计、视觉方向、配色方案、字体选型：请使用
```
ui-design
```
  。
- 审核已完成的成果（渲染质量、无障碍标记、键盘操作、布局、性能、字体呈现、React/Next代码层面的用户体验，并给出发布结论）：请使用
```
ui-design
```
  的Audit模式。
- 文案措辞、说服力优化或AI风格调整：请使用
```
copywriting
```
  。
- 深度字体设计或动效设计：请使用
```
typography-audit
```
  或
```
ui-animation
```
  。

product-design, ui-design, or ui-animation?

product-design、ui-design还是ui-animation？

An interface is a set of states and the passages between them. That decomposition assigns the work.

The question is about	Use
Which states exist, what an action affects, whether it is reversible	this skill
What a state looks like once built: markup, type, colour, layout, hierarchy	`ui-design`
The passage between two states: timing, easing, springs, gesture physics	`ui-animation`

Subject beats artifact. When motion is what the request is about, it is
```
ui-animation
```
whether or not code exists yet.
Artifact is the opening presumption, not the verdict. A brief, spec, mockup, or intent with no code is this skill. Code, a diff, or a running UI in hand presumes
```
ui-design
```
, and the next test can overturn that: this skill reads existing UI whenever the question is what it should do.
Capability beats presentation. With code in hand, ask whether the change alters what a user can do, which objects an action affects, whether it is reversible, or whether a state exists at all. That is a capability, so this skill decides and
```
ui-design
```
implements. If it only changes how the same capability looks, reads, or behaves,
```
ui-design
```
owns it end to end.
A gesture that replaces a control is a capability decision. Swipe-to-delete, hold-to-confirm, and drag-to-reorder change what the user can do and how recoverable it is, so this skill settles the interaction and
```
ui-animation
```
builds its physics.
Motion incidental to a build stays in
ui-design
. A hover transition or a fade added while building a component is a property of that component. It becomes
```
ui-animation
```
's when motion is the subject or its craft is in question.

Two edges the tiebreak does not settle on its own:

Choosing between control patterns with different reachability is a capability, so this skill. Modal against inline, drawer against full page, and dialog against toast each change what stays visible, how the task is dismissed, and where focus lands (
```
rule/inline-before-modal
```
). Styling whichever is chosen is
```
ui-design
```
's.
A missing state nobody would debate is
ui-design
's to detect and build. An empty list, a failed fetch, and a pending submit all obviously need a state, and its
```
states-
```
audit rules find and fix them. This skill decides which states must exist only where that is genuinely open, such as whether a partial or an expired state should exist at all.

Worked: "Delete should be undoable" is this skill. "The undo toast is ugly" is

ui-design

. "The undo toast should slide, not pop" is

ui-animation

One artifact often needs both in sequence: this skill decides the states that must exist,

ui-design

Audit mode verifies the built code and rendered result implement them. This skill reviews the decision and stops at decision altitude; it never writes line-level code fixes.

界面由一系列状态及状态间的过渡组成，可根据这一分解来分配工作。

问题关注点	使用技能
存在哪些状态、操作会影响什么、操作是否可撤销	本技能
已构建完成的状态外观：标记语言、字体、颜色、布局、层级	`ui-design`
两个状态间的过渡：时长、缓动效果、弹簧动画、手势物理效果	`ui-animation`

核心需求优先于交付物：当请求的核心是动效时，无论是否已有代码，都应使用
```
ui-animation
```
。
交付物只是初始判断依据，而非最终结论：无代码的简报、规格文档、原型图或需求意图，由本技能处理。若提供了代码、差异文件或可运行的UI，初始判断为使用
```
ui-design
```
，但后续可根据问题调整：当问题是“界面应该具备什么功能”时，本技能会读取现有UI进行决策。
功能优先于呈现：若手中已有代码，判断变更是否会改变用户的操作能力、操作影响的对象、操作是否可撤销，或是否新增/移除状态。这类属于功能决策，由本技能负责，
```
ui-design
```
负责实现。若仅改变同一功能的外观、可读性或表现形式，则全程由
```
ui-design
```
负责。
替代控件的手势属于功能决策：滑动删除、长按确认、拖拽排序会改变用户的操作方式及可恢复性，因此由本技能确定交互逻辑，
```
ui-animation
```
负责实现其物理动效。
构建过程中附带的动效由
ui-design
负责：构建组件时添加的悬停过渡或淡入效果属于该组件的属性。只有当动效是核心需求或其实现工艺受到质疑时，才由
```
ui-animation
```
负责。

以下两种边界情况无法仅通过上述规则判断：

选择不同可达性的控件模式属于功能决策，由本技能负责。模态框与内联组件、侧边栏与全屏页面、对话框与提示框的选择，会影响可见内容、任务关闭方式及焦点位置（参考
```
rule/inline-before-modal
```
规则）。选中模式后的样式设计由
```
ui-design
```
负责。
无争议的缺失状态由
ui-design
检测并构建：空列表、请求失败、提交中这些状态显然需要设计，其
```
states-
```
审核规则会发现并修复这些问题。只有当状态是否存在存在真正争议时（比如是否需要部分状态或过期状态），才由本技能决定必须存在哪些状态。

示例：“删除操作应支持撤销”属于本技能的范畴。“撤销提示框太丑”属于

ui-design

的范畴。“撤销提示框应该滑入而非弹出”属于

ui-animation

的范畴。

同一交付物通常需要两个技能依次处理：本技能确定必须存在的状态，

ui-design

的Audit模式验证已构建的代码和渲染结果是否实现了这些状态。本技能仅评审决策，停留在决策层面，绝不编写行级代码修复。

Operating contract

操作约定

Cite a stable rule ID for every finding or non-mechanical decision. Never invent an ID; if none fits, record a coverage gap.
The project's design system and
```
AGENTS.md
```
outrank this skill's defaults. Defer to them.
Never restyle or rebuild. Decide, then route the build to
```
ui-design
```
.
One mode per request, resolved from the user's verb before acting.

每个发现或非机械性决策都必须引用一个稳定的规则ID。绝不能自行创建ID；若没有合适的ID，需记录为规则覆盖缺口。
项目的设计系统和
```
AGENTS.md
```
优先级高于本技能的默认规则。需优先遵循这些内容。
绝不重新设计或重建界面。完成决策后，将构建工作分配给
```
ui-design
```
。
每个请求仅使用一种模式，根据用户的动词确定模式后再执行操作。

Request modes

请求模式

Resolve the mode from the user's verb and artifact, then load that mode's references.

references/rules.md

loads in every mode: the citation contract binds all of them, and you cannot conclude that no existing rule governs a decision without the registry in front of you.

Mode	Dispatch when the user asks for	Load (plus `references/rules.md` )
shape (default)	"design the flow for", "what control here", "how should this work", "is this the right pattern", a brief with no settled UI	`references/product-judgment.md` , `references/surfaces.md`
spec	"spec the right interaction", "define the expected states", judgment applied before or during a build	`references/surfaces.md` , `references/naming-and-copy.md` , `references/product-judgment.md` ; route the build to `ui-design`
review	"review this flow for product correctness", "what's wrong with this UX decision", "is this the right interaction"	`references/interface-quality.md`
action	"what should this action affect", "which object or scope does this action cover", or action reversibility is unsettled	`references/naming-and-copy.md` ; route final wording polish to `copywriting`
harden	"make this resilient", "what breaks here", error, permission, offline, and destructive paths	`references/surfaces.md` , `references/interface-quality.md` , `references/product-judgment.md`

review mode is about a flow, not an artifact. "Audit this component", "check my UI", or "design QA this page" point at built markup and belong to

ui-design

Audit mode. This skill's review asks whether the decisions behind a flow are right, and stops at decision altitude.

Modes chain: shape leads into spec; review leads into harden. When intent is ambiguous, use the narrowest mode the verb supports. A URL, screenshot, route, or component identifies scope; it does not authorize edits.

A material decision: see

references/product-judgment.md

根据用户的动词和交付物确定模式，然后加载该模式的参考文件。

references/rules.md

在所有模式下都会加载：引用约定适用于所有模式，若不查看规则注册表，无法确定是否有现有规则适用于决策。

模式	适用场景	加载的参考文件（附加 `references/rules.md` ）
shape（默认）	“设计流程”“这里用什么控件”“应该如何工作”“这个模式是否合理”，以及无确定UI的简报	`references/product-judgment.md` 、 `references/surfaces.md`
spec	“规范正确的交互方式”“定义预期状态”，在构建前或构建过程中进行判断	`references/surfaces.md` 、 `references/naming-and-copy.md` 、 `references/product-judgment.md` ；将构建工作分配给 `ui-design`
review	“从产品正确性角度评审这个流程”“这个UX决策有什么问题”“这个交互是否合理”	`references/interface-quality.md`
action	“这个操作会影响什么”“这个操作覆盖哪些对象或范围”，或操作的可撤销性未确定	`references/naming-and-copy.md` ；将最终文案润色工作分配给 `copywriting`
harden	“提升界面韧性”“这里存在什么问题”，错误、权限、离线及破坏性路径相关需求	`references/surfaces.md` 、 `references/interface-quality.md` 、 `references/product-judgment.md`

review模式针对的是流程，而非交付物。“审核这个组件”“检查我的UI”或“对这个页面进行设计QA”指向已构建的标记语言，属于

ui-design

的Audit模式。本技能的review仅判断流程背后的决策是否正确，停留在决策层面。

模式可以链式触发：shape模式可进入spec模式；review模式可进入harden模式。当意图不明确时，使用动词支持的最窄模式。URL、截图、路由或组件用于确定范围；但不授权进行编辑。

重大决策：参考

references/product-judgment.md

。

Decision authority

决策优先级

Conflict order, highest first:

The user's explicit goal and constraints.
Verified user and product evidence, and what the system actually does.
Project-canonical guidance:
```
AGENTS.md
```
or
```
CLAUDE.md
```
, the project's design system, routed sibling skills.
Sibling-skill ownership: route, do not duplicate (ownership map in Related skills).
This skill's product design standards (below).
General interface and platform conventions.

When a request spans authorities, name the owning skill and hand off.

冲突解决优先级从高到低：

用户明确的目标和约束条件。
已验证的用户和产品证据，以及系统的实际行为。
项目规范指导：
```
AGENTS.md
```
或
```
CLAUDE.md
```
、项目的设计系统、相关兄弟技能。
兄弟技能的职责划分：分配工作，不重复处理（职责划分见“相关技能”部分）。
本技能的产品设计标准（如下）。
通用界面和平台惯例。

当请求涉及多个职责范围时，指明负责的技能并移交工作。

Workflow

工作流程

Product design pass:
- [ ] Step 1: Classify the request into one mode
- [ ] Step 2: Locate authority (user constraints, project design system, AGENTS.md)
- [ ] Step 3: Load only that mode's reference files
- [ ] Step 4: Name object, scope, and consequence for each action in scope (spec, action, review)
- [ ] Step 5: Enumerate reachable states and check coverage (shape, spec, harden)
- [ ] Step 6: Apply standards; cite a stable rule ID per finding or decision
- [ ] Step 7: Emit output (review and harden use P0-P3); route follow-on work to siblings
- [ ] Step 8: Run the pass self-check

Steps 4 and 5 are mode-scoped because their references are: a pure

action

pass has no state matrix to enumerate, and a

shape

pass has no built actions to name yet. Run the step that its mode's loaded files support.

For shape, spec, harden, or any material product or flow change, write the compact internal brief specified in

references/product-judgment.md

before proposing UI. If its job, desired outcome, and consequence fields cannot be filled in, stop and ask rather than guessing.

Output length follows the work, not the template. A single settled decision is a short answer; drop the sections a pass did not need rather than filling them.

产品设计流程：
- [ ] 步骤1：将请求分类为一种模式
- [ ] 步骤2：确定决策依据（用户约束、项目设计系统、AGENTS.md）
- [ ] 步骤3：仅加载该模式对应的参考文件
- [ ] 步骤4：定义范围内每个操作的对象、范围和后果（spec、action、review模式）
- [ ] 步骤5：列举可达状态并检查覆盖情况（shape、spec、harden模式）
- [ ] 步骤6：应用标准；每个发现或决策都引用一个稳定的规则ID
- [ ] 步骤7：输出结果（review和harden模式使用P0-P3优先级）；将后续工作分配给兄弟技能
- [ ] 步骤8：执行流程自我检查

步骤4和5是模式专属的，因为它们的参考文件不同：纯

action

模式无需列举状态矩阵，

shape

模式尚无已定义的操作需要描述。仅执行该模式加载的参考文件支持的步骤。

对于shape、spec、harden模式，或任何重大产品/流程变更，在提出UI方案前，需按照

references/product-judgment.md

中的要求编写简洁的内部简报。如果无法填写简报中的任务、预期结果和后果字段，请停止操作并询问用户，不要猜测。

输出长度取决于工作内容，而非模板。单一确定的决策只需简短回答；无需填充流程中未涉及的部分。

Pass self-check

流程自我检查

Close every pass with these, and label it

INCOMPLETE

if any fails:

Every finding and non-mechanical decision carries a rule ID from
```
references/rules.md
```
.
Every decision no existing rule governs is recorded inline as a coverage gap.
No cited ID was invented: each one appears verbatim in
```
references/rules.md
```
.
The internal brief is present with job, desired outcome, and consequence filled, for shape, spec, and harden.

每个流程结束时执行以下检查，若有任何一项未通过，标记为

INCOMPLETE

：

每个发现和非机械性决策都带有
```
references/rules.md
```
中的规则ID。
所有无现有规则可遵循的决策都已内联记录为规则覆盖缺口。
未引用任何自行创建的ID：每个引用的ID都与
```
references/rules.md
```
中的内容完全一致。
对于shape、spec和harden模式，已提供填写完整任务、预期结果和后果字段的内部简报。

Product design standards

产品设计标准

Five pillars, each naming the rule IDs in

references/rules.md

that govern it and the reference that details it. Resilience shares

rule/cover-reachable-states

with state coverage rather than adding an ID of its own: it is the same requirement pointed at adverse inputs, which is where reachable states are most often left undesigned.

Right interaction. Pick the control from the choice's shape; keep options visible and reversible; prefer inline disclosure over a modal; choose the smallest coherent intervention.
```
rule/control-matches-cardinality
```
,
```
rule/navigation-vs-action
```
,
```
rule/inline-before-modal
```
,
```
rule/smallest-intervention
```
. See
```
references/product-judgment.md
```
.
Action naming. Name the object, scope, and consequence; destructive CTAs use Verb plus Noun, never "Confirm" or "OK"; make friction proportional to impact and offer undo when honest.
```
rule/name-object-scope-consequence
```
,
```
rule/destructive-names-action
```
,
```
rule/destructive-proportional
```
. See
```
references/naming-and-copy.md
```
.
State coverage. Design every reachable state, not just the populated one; empty states name the object and a first action; errors explain and offer recovery; preserve user input.
```
rule/cover-reachable-states
```
,
```
rule/empty-state-action
```
,
```
rule/error-states-recovery
```
,
```
rule/preserve-user-input
```
. See
```
references/surfaces.md
```
.
Resilience. Require that overflow, extreme data, localization and RTL, and network-failure states be designed; every fetch lands in a designed state.
```
rule/cover-reachable-states
```
. See
```
references/surfaces.md
```
. Whether the built UI renders them correctly is
```
ui-design
```
Audit mode's check.
Accessibility as a product concern. Every control has an accessible name; the primary flow is completable by keyboard with visible focus; state and consequence are understandable, not just labeled.
```
rule/accessible-name-required
```
,
```
rule/keyboard-complete-flow
```
,
```
rule/no-custom-focus-bypass
```
. Route axe-style markup checks to
```
ui-design
```
Audit mode. See
```
references/interface-quality.md
```
.

五大支柱，每个支柱列出

references/rules.md

中对应的规则ID及详细参考文件。韧性与状态覆盖共享

rule/cover-reachable-states

规则，无需新增ID：它是针对不利输入的同一要求，而可达状态最常在此类场景下被遗漏设计。

合理的交互方式：根据选项数量选择控件；保持选项可见且可撤销；优先使用内联展示而非模态框；选择最小的合理干预方式。对应规则：
```
rule/control-matches-cardinality
```
、
```
rule/navigation-vs-action
```
、
```
rule/inline-before-modal
```
、
```
rule/smallest-intervention
```
。参考文件：
```
references/product-judgment.md
```
。
操作命名：明确对象、范围和后果；破坏性操作的CTA使用“动词+名词”格式，绝不能使用“Confirm”或“OK”；摩擦程度与影响成正比，必要时提供撤销选项。对应规则：
```
rule/name-object-scope-consequence
```
、
```
rule/destructive-names-action
```
、
```
rule/destructive-proportional
```
。参考文件：
```
references/naming-and-copy.md
```
。
状态覆盖：设计所有可达状态，而非仅填充状态；空状态需明确对象并提供首个操作指引；错误状态需说明原因并提供恢复方式；保留用户输入内容。对应规则：
```
rule/cover-reachable-states
```
、
```
rule/empty-state-action
```
、
```
rule/error-states-recovery
```
、
```
rule/preserve-user-input
```
。参考文件：
```
references/surfaces.md
```
。
韧性：要求设计溢出、极端数据、本地化与RTL（从右到左）、网络失败等状态；每个请求都需对应到已设计的状态。对应规则：
```
rule/cover-reachable-states
```
。参考文件：
```
references/surfaces.md
```
。已构建的UI是否正确渲染这些状态，由
```
ui-design
```
的Audit模式负责检查。
作为产品需求的可访问性：每个控件都有可访问名称；主流程可通过键盘完成操作且焦点可见；状态和后果可被理解，而非仅添加标签。对应规则：
```
rule/accessible-name-required
```
、
```
rule/keyboard-complete-flow
```
、
```
rule/no-custom-focus-bypass
```
。axe风格的标记检查工作分配给
```
ui-design
```
的Audit模式。参考文件：
```
references/interface-quality.md
```
。

Review output

评审输出

In review and harden modes, lead with findings ordered by user impact (P0-P3), each with location, verification status, rule ID, user consequence, and the smallest concrete fix with the skill that owns it. Keep findings at decision altitude; a line-level code or framework fix is

ui-design

Audit mode's output. Full severity rubric and finding format in

references/interface-quality.md

> Severity rubric.

在review和harden模式下，按用户影响优先级（P0-P3）排序展示发现结果，每个结果需包含位置、验证状态、规则ID、用户影响及最小的具体修复方案和负责技能。发现结果需停留在决策层面；行级代码或框架修复属于

ui-design

的Audit模式的输出内容。完整的严重程度标准和发现结果格式见

references/interface-quality.md

> 严重程度标准。

Linters vs agent guidance

代码检查器与Agent指引

Deterministic, structural, single-file checks (control selection by option count, nested modals, missing accessible names) belong in the consuming project's linter, wired to that project's components; judgment that needs product context (which object, what consequence) stays here. See

references/lint-patterns.md

for the decision tree and the rules worth encoding.

确定性、结构化、单文件检查（根据选项数量选择控件、嵌套模态框、缺失可访问名称）应集成到项目的代码检查器中，与项目组件关联；需要产品上下文的判断（涉及哪些对象、什么后果）由本技能负责。参考

references/lint-patterns.md

中的决策树及值得编码的规则。

Gotchas

注意事项

Emitting a line-level fix (a prop, a hook, a
```
className
```
) instead of the decision. It arrives without the rendered check that would validate it, and the product decision it was supposed to carry goes unstated. Route it to
```
ui-design
```
Audit mode.
Proposing UI when the internal brief's job, desired outcome, or consequence field cannot be filled. Every finding after that rests on a guessed job, so stop and ask (
```
references/product-judgment.md
```
).
Citing a plausible-sounding rule ID that does not exist (
```
rule/clear-labels
```
). The citation resolves to nothing, so the finding cannot be deduped against a sibling audit or traced to a rule. Record a coverage gap instead.

输出行级修复方案（属性、钩子、
```
className
```
）而非决策。这类修复缺乏渲染验证，且未明确其背后的产品决策。应将其分配给
```
ui-design
```
的Audit模式。
当内部简报的任务、预期结果或后果字段无法填写时，仍提出UI方案。后续所有发现都基于猜测的任务，因此请停止操作并询问用户（参考
```
references/product-judgment.md
```
）。
引用看似合理但不存在的规则ID（如
```
rule/clear-labels
```
）。这类引用无实际依据，无法与兄弟技能的审核结果去重或追溯到规则。应记录为规则覆盖缺口。