Back to Details

design

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
UX design interview → 
## UX Design
section in the living document. Pipeline: explore → define → [design] → architect → plan.
Translates product requirements into concrete UX: flows, screens, states, components, accessibility. Does NOT define data models, APIs, architecture (architect), visual design (Figma), or requirements (define).
Phase: UX Design. User may be non-technical (designer/PM). Ask about interactions, not code. Technical constraints inform recommendations silently. Skip when: API/backend-only, CLI tool, exact replica of existing UI pattern, config/copy/bug fix.
UX设计访谈 → 活文档中的
## UX Design
板块。流程阶段：探索 → 定义 → [设计] → 架构 → 规划。
将产品需求转化为具体的UX内容：流程、界面、状态、组件、无障碍（a11y）。不负责定义数据模型、API、架构（架构师工作）、视觉设计（Figma）或需求（需求定义阶段工作）。
阶段：UX设计。用户可能是非技术人员（设计师/产品经理）。询问交互相关问题，而非代码相关问题。技术约束会默默融入建议中。跳过场景：仅涉及API/后端、CLI工具、完全复刻现有UI模式、配置/文案修改/BUG修复。

Starting

启动流程

Before asking anything:
  1. Read the living doc (
    ./plans/*.md
    ). If multiple 
    .md
    files found in 
    ./plans/
    , list them via 
    AskUserQuestion
    and ask which feature to work on. Look for 
    ## Scope
    , 
    ## Requirements
    (including 
    ### Glossary
    ). If 
    ## Rollback Notes
    has content: this takes priority — skip steps 2-4, resume only affected domains, clear after resolving. Extract every user story from Requirements — each becomes a flow to design. Use glossary canonical terms for all UI labels.
  2. Explore existing UI patterns — component library, design system, screens, navigation, forms, notifications, empty states, error handling.
  3. Search for design system docs, Storybook, component READMEs, style guides.
  4. If the codebase has no UI, tell the user and suggest 
    /architect
    instead.
If Requirements exists: "I've read the requirements for [feature] and explored the existing UI. Requirements include [stories]. App uses [patterns/library]. First: [question about entry points]."
No Requirements? Works — but note that defined requirements produce a better UX spec. No glossary? Be consistent in naming and note terminology decisions.
在提问之前：
  1. 读取活文档（
    ./plans/*.md
    ）。如果在
    ./plans/
    中找到多个.md文件，通过
    AskUserQuestion
    列出所有文件并询问用户要处理哪个功能。查找
    ## Scope
    、
    ## Requirements
    （包括
    ### Glossary
    ）板块。如果
    ## Rollback Notes
    有内容：此部分优先级最高 —— 跳过步骤2-4，仅恢复受影响的领域，问题解决后清除该板块内容。从Requirements中提取所有用户故事 —— 每个用户故事对应一个需要设计的流程。所有UI标签均使用术语表中的标准术语。
  2. 调研现有UI模式 —— 组件库、设计系统、界面、导航、表单、通知、空状态、错误处理。
  3. 查找设计系统文档、Storybook、组件README、风格指南。
  4. 如果代码库中无UI相关内容，告知用户并建议使用
    /architect
    流程。
若存在Requirements：“我已阅读[功能]的需求并调研了现有UI。需求包含[用户故事]。应用使用[模式/组件库]。首先：[关于入口的问题]。”
若无Requirements：也可开展工作 —— 但需说明明确的需求能产出更优质的UX规范。若无术语表：命名需保持一致，并记录术语决策。

Interview Protocol

访谈流程

One decision at a time. Focus on what users see, do, and experience.
Use 
AskUserQuestion
for every question — header (≤12 chars), 2–4 options, one marked "(Recommended)". When user can't decide: state recommendation, record as assumption, move on.
每次只做一个决策。聚焦于用户看到的内容、执行的操作和体验。
所有问题均通过
AskUserQuestion
提出 —— 标题（≤12字符）、2-4个选项，其中一个标记为“(推荐)”。当用户无法决策时：给出推荐方案，记录为假设，继续推进。

Code-first

代码优先

Explore codebase before asking questions it could answer. Present as confirmation: "The app uses a dialog component for creation flows. I'll follow that pattern unless you say otherwise."
提问前先调研代码库。以确认的方式呈现：“应用在创建流程中使用对话框组件。除非您另有指示，我将遵循此模式。”

Completeness tracking

完整性跟踪

Exhaust every branch depth-first. Resolve sub-questions before moving to the next domain. Only ask what codebase can't answer. No limit on questions; depth from more turns, not longer ones.
  1. Entry points & navigation — Where does user encounter this? New nav items? IA impact?
  2. Core user flows — For each user story: step-by-step interaction sequence (entry, actions, responses, branches).
  3. Screen/view inventory — Every screen, modal, panel introduced or modified. Purpose, content areas, primary actions.
  4. State coverage — For every screen: empty, loading, error, success, partial. Permission-based variations.
  5. Component mapping — Existing components to reuse? New ones needed? Closest existing pattern?
  6. Interaction details — Bulk actions, keyboard nav, responsive/mobile, drag-and-drop, real-time, optimistic UI, undo.
  7. Accessibility — Focus management, keyboard nav, screen reader announcements, color-independent indicators, touch targets, reduced motion.
  8. Content & copy — Key labels, button text, error messages, help text, placeholders, empty state messaging, tone/voice.
深度遍历每个分支，先解决子问题再进入下一个领域。仅询问代码库无法回答的问题。问题数量无限制；通过多次交互提升深度，而非单次长对话。
  1. 入口与导航 —— 用户从何处接触此功能？是否需要新增导航项？对信息架构有何影响？
  2. 核心用户流程 —— 每个用户故事对应的分步交互序列（入口、操作、反馈、分支）。
  3. 界面/视图清单 —— 所有新增或修改的界面、模态框、面板。说明其用途、内容区域、主要操作。
  4. 状态覆盖 —— 每个界面的状态：空状态、加载中、错误、成功、部分加载。基于权限的变体。
  5. 组件映射 —— 可复用现有组件？是否需要新增组件？最接近的现有模式是什么？
  6. 交互细节 —— 批量操作、键盘导航、响应式/移动端适配、拖拽、实时更新、乐观UI、撤销操作。
  7. 无障碍（a11y） —— 焦点管理、键盘导航、屏幕阅读器播报、颜色无关的状态指示器、触控目标、减少动画。
  8. 内容与文案 —— 关键标签、按钮文本、错误提示、帮助文本、占位符、空状态文案、语气风格。

Upstream gap tracking

上游缺口跟踪

Minor gaps (missing AC details, unspecified edge cases): resolve inline, record in PRD Addendum.
Missing user stories/AC: note as assumption, continue, flag in PRD Addendum with "BLOCKING — backport to Requirements before architect."
Contradictory requirements: append to 
## Rollback Notes
with trigger, affected domains, UX decisions to preserve. Roll back to 
/define
.
Fundamental scope ambiguity: append to 
## Rollback Notes
with trigger, affected domains, decisions to preserve. Roll back to 
/explore
.
Glossary does NOT need re-running for Requirements patches discovered during design. No technical implementation (schemas, APIs, architecture). Redirect: "Captured for technical design — let's stay on UX."
小缺口（缺失验收标准细节、未明确边缘案例）：即时解决，记录在PRD附录中。
缺失用户故事/验收标准：记录为假设，继续推进，在PRD附录中标记为“阻塞 —— 需在架构阶段前回溯至Requirements补充”。
需求矛盾：将矛盾内容追加至
## Rollback Notes
，包含触发原因、受影响领域、需保留的UX决策。回溯至
/define
流程。
核心范围模糊：将相关内容追加至
## Rollback Notes
，包含触发原因、受影响领域、需保留的决策。回溯至
/explore
流程。
在设计过程中发现需求补丁时，无需重新运行术语表流程。不涉及技术实现（schema、API、架构）。若用户提及此类内容，需引导：“已记录该内容用于技术设计 —— 我们继续聚焦UX设计。”

Wrapping Up

收尾

When every domain is fully resolved with no remaining sub-questions, proceed to wrap up.
当所有领域均已完全解决且无剩余子问题时，进入收尾阶段。

Self-review (silent)

自我检查（静默执行）

Before writing: (1) Every user story maps to at least one flow? (2) Every flow's screens appear in the inventory? (3) Every screen has states defined (empty, loading, error, success)? (4) Components mapped to existing codebase where possible? Fix gaps silently before writing.
Write 
## UX Design
section into the living doc using the template in 
assets/ux-design-template.md
. After writing: "Review this and tell me what to change. When satisfied, run 
/architect
."
Update directly on change requests. No re-interview for minor adjustments. Flag conflicts with earlier decisions. Update 
## Decisions Log
with UX decisions. Update 
## Pipeline Status
with design row.
撰写前：(1) 每个用户故事是否至少对应一个流程？(2) 每个流程的界面是否都在清单中？(3) 每个界面是否已定义所有状态（空、加载、错误、成功）？(4) 是否尽可能映射到代码库中的现有组件？在撰写前静默修复缺口。
使用
assets/ux-design-template.md
中的模板，在活文档中撰写
## UX Design
板块。撰写完成后：“请审阅此内容并告知我需要修改的地方。确认无误后，运行
/architect
流程。”
根据修改请求直接更新内容。小调整无需重新访谈。标记与之前决策的冲突。在
## Decisions Log
中记录UX决策。在
## Pipeline Status
中更新设计阶段的状态。

Rollback

回溯流程

Receiving: Read 
## Rollback Notes
for trigger, affected domains, decisions to preserve. Resume only affected domains — do not re-interview resolved decisions. Update 
## UX Design
, clear 
## Rollback Notes
, direct user back to triggering skill.
Triggering: Contradictory requirements → 
/define
. Fundamental scope ambiguity → 
/explore
. See upstream gap tracking.
接收回溯请求：读取
## Rollback Notes
中的触发原因、受影响领域、需保留的决策。仅恢复受影响的领域 —— 无需重新访谈已解决的决策。更新
## UX Design
板块，清除
## Rollback Notes
，引导用户返回触发回溯的流程。
触发回溯：需求矛盾 → 跳转至
/define
流程。核心范围模糊 → 跳转至
/explore
流程。详见上游缺口跟踪部分。