ui-ux-designer

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Provided by TippyEntertainment

由TippyEntertainment提供

UI/UX Designer Skill

UI/UX设计师技能

This skill requires following a strict sequence of phases:
  1. Research and Discovery
  2. Define Requirements
  3. Information Architecture (IA)
  4. Wireframing
  5. UI Design
You must never jump directly to UI Design when the earlier phases are missing, unclear, or incomplete. Only move to the next phase when the current one is “good enough” for practical progress.
  • Use
    target
    to document which product or website the skill primarily supports.
  • Keep
    name
    and
    description
    present; other frontmatter keys like
    tags
    or
    priority
    are optional.

本技能要求严格遵循以下阶段顺序:
  1. 研究与探索
  2. 需求定义
  3. 信息架构(IA)
  4. 线框设计
  5. UI设计
当前面的阶段缺失、不明确或未完成时,绝不能直接跳到UI设计阶段。只有当当前阶段达到“足够推进实际工作”的标准时,才能进入下一阶段。
  • 使用
    target
    字段记录该技能主要支持的产品或网站。
  • 保留
    name
    description
    字段;其他前置元数据字段如
    tags
    priority
    为可选。

When to Use This Skill

何时使用本技能

Use this skill when:
  • The user asks for a new feature, screen, flow, or product experience.
  • Requirements are fuzzy, underspecified, or conflict with each other.
  • Existing UX is confusing, inconsistent, or needs a redesign.
  • Other agents need structured UX artifacts (requirements, flows, wireframes, specs).
Do not use this skill for:
  • Small visual tweaks to an already well-specified component (e.g., “make this button blue”).
  • Pure copywriting or content-only tasks.
  • Pixel-perfect Figma implementation details tied to a specific team’s design system.

在以下场景中使用本技能:
  • 用户要求设计新功能、页面、流程或产品体验时。
  • 需求模糊、描述不充分或相互冲突时。
  • 现有UX设计混乱、不一致或需要重新设计时。
  • 其他Agent需要结构化的UX工件(需求、流程、线框、规格说明)时。
请勿在以下场景中使用本技能:
  • 对已明确规格的组件进行微小视觉调整(例如:“将这个按钮改成蓝色”)。
  • 纯文案撰写或仅涉及内容的任务。
  • 与特定团队设计系统绑定的像素级Figma实现细节。

Overall Workflow

整体工作流程

Always work in order. At each step:
  1. State the current phase.
  2. Summarize the inputs you are using.
  3. Produce concrete outputs/deliverables.
  4. List assumptions and open questions.
Only move to the next phase when the current one is “good enough” for practical progress.
Phases:
  1. Research and Discovery
  2. Define Requirements
  3. Information Architecture (IA)
  4. Wireframing
  5. UI Design

始终按顺序执行。在每个步骤中:
  1. 说明当前阶段
  2. 总结你所使用的输入信息
  3. 生成具体的输出/交付物
  4. 列出假设和待解决问题
只有当当前阶段达到“足够推进实际工作”的标准时,才能进入下一阶段。
阶段:
  1. 研究与探索
  2. 需求定义
  3. 信息架构(IA)
  4. 线框设计
  5. UI设计

Phase 1 – Research and Discovery

阶段1 – 研究与探索

Goal: Understand the problem, users, and context well enough to make informed design tradeoffs.
目标:充分理解问题、用户和背景,以便做出合理的设计权衡。

Tasks

任务

  • Clarify business goals and success metrics.
  • Identify primary users/personas and their goals.
  • Understand the current workflow or status quo (what users do today).
  • Capture constraints: platform, technical limits, compliance, brand.
  • 明确业务目标和成功指标。
  • 识别核心用户/用户角色及其目标。
  • 了解当前工作流程或现状(用户当前的操作方式)。
  • 记录约束条件:平台、技术限制、合规要求、品牌规范。

Outputs

输出

Produce a short, structured summary:
  • Problem Statement: 2–4 sentences.
  • Primary Users: bullet list with 1–3 user types.
  • Goals and Jobs-to-be-Done: bullet list.
  • Key Constraints/Assumptions: bullet list.
  • Open Questions: what you would ask a PM/Stakeholder.
If the input is extremely vague, ask for clarification questions instead of guessing wildly.

生成一份简短的结构化总结:
  • 问题陈述:2-4句话。
  • 核心用户:包含1-3种用户类型的项目符号列表。
  • 目标与待完成任务:项目符号列表。
  • 关键约束/假设:项目符号列表。
  • 待解决问题:你会向产品经理/利益相关者提出的问题。
如果输入信息极其模糊,请提出澄清问题,而非盲目猜测。

Phase 2 – Define Requirements

阶段2 – 需求定义

Goal: Translate research into explicit, testable product/feature requirements.
目标:将研究结果转化为明确、可测试的产品/功能需求。

Tasks

任务

  • Derive user stories from the problem statement and user goals.
  • Cover “happy path” and common edge cases.
  • Separate must-have vs nice-to-have.
  • Include non-functional requirements relevant to UX (accessibility, responsiveness, performance).
  • 从问题陈述和用户目标中推导用户故事。
  • 覆盖“理想路径”和常见边缘情况。
  • 区分必备需求可选需求
  • 纳入与UX相关的非功能性需求(可访问性、响应式、性能)。

Outputs

输出

Provide:
  • User Stories:
    As a <user>, I want <action> so that <outcome>.
  • Acceptance Criteria: bullet list for each critical story.
  • Constraints: anything that limits the solution (e.g., must reuse existing navigation).
  • Risks / Tradeoffs: where requirements might conflict.
Requirements should be specific enough that a developer could implement and a QA could test.

提供以下内容:
  • 用户故事
    作为<用户角色>,我想要<操作>,以便<达成结果>。
  • 验收标准:每个关键故事对应的项目符号列表。
  • 约束条件:任何限制解决方案的因素(例如:必须复用现有导航)。
  • 风险/权衡:需求可能存在冲突的地方。
需求应足够具体,以便开发人员实现、QA人员测试。

Phase 3 – Information Architecture (IA)

阶段3 – 信息架构(IA)

Goal: Decide how information and screens are organized and how users move between them.
目标:确定信息和页面的组织方式,以及用户在页面间的导航逻辑。

Tasks

任务

  • Define the main entities and sections (e.g., Dashboard, Project, Task, Settings).
  • Decide navigation structure (global nav, subnav, breadcrumbs, etc.).
  • Map primary user flows (e.g., “Create Project”, “Invite Member”, “Checkout”).
  • Consider future extensibility where reasonable.
  • 定义主要实体和板块(例如:仪表盘、项目、任务、设置)。
  • 确定导航结构(全局导航、子导航、面包屑等)。
  • 绘制核心用户流程(例如:“创建项目”、“邀请成员”、“结账”)。
  • 合理考虑未来的扩展性。

Outputs

输出

Provide:
  • IA Outline / Sitemap: indented list of main sections and key screens.
  • Key Entities: short definitions of core objects.
  • Primary Flows: step-by-step text for 1–3 critical journeys.
Keep this high-level but concrete enough that wireframes are obvious next steps.

提供以下内容:
  • IA大纲/站点地图:主要板块和关键页面的缩进列表。
  • 核心实体:核心对象的简短定义。
  • 核心流程:1-3个关键用户旅程的分步文字说明。
保持内容高屋建瓴,但足够具体,以便线框设计成为顺理成章的下一步。

Phase 4 – Wireframing

阶段4 – 线框设计

Goal: Low-fidelity layout and hierarchy without visual polish.
目标:制作低保真度的布局和层级结构,无需视觉润色。

Principles

原则

  • Focus on layout, grouping, hierarchy, and states, not colors or fine typography.
  • Prefer simple, textual/ASCII descriptions that map easily to components.
  • Capture key states: default, empty, loading, error (where relevant).
  • 专注于布局分组层级状态,而非颜色或精细排版。
  • 优先使用简单的文本/ASCII描述,以便轻松映射到组件。
  • 记录关键状态:默认、空状态、加载、错误(相关时)。

Tasks

任务

For each important screen:
  • Identify key regions (e.g., header, left sidebar, main content, right panel).
  • Describe which components live where (cards, tables, forms, filters, CTAs).
  • Call out priority and emphasis (e.g., “primary CTA in top-right of header”).
针对每个重要页面:
  • 识别关键区域(例如:页眉、左侧边栏、主内容区、右侧面板)。
  • 描述各区域包含的组件(卡片、表格、表单、筛选器、CTA等)。
  • 标注优先级和重点(例如:“主CTA位于页眉右上角”)。

Outputs

输出

For each screen, provide:
  • Screen Name and Purpose.
  • Layout Description: 3–8 bullet points describing regions and contents.
  • States: any notable state variations.
  • Navigation Hooks: where users can go next from this screen.
Keep everything implementation-agnostic but mappable to typical web components.

针对每个页面,提供:
  • 页面名称与用途
  • 布局描述:3-8个项目符号,描述各区域及其内容。
  • 状态:任何值得注意的状态变体。
  • 导航入口:用户从该页面可前往的下一个位置。
保持内容与实现无关,但可映射到典型的Web组件。

Phase 5 – UI Design

阶段5 – UI设计

Goal: Turn wireframes into visually coherent, build-ready UI specs.
目标:将线框转化为视觉连贯、可开发的UI规格说明。

Tasks

任务

  • Apply consistent spacing, typography levels, and radius/shadow tokens.
  • Choose colors that meet contrast guidelines when possible.
  • Map wireframe elements to concrete components (e.g., “PrimaryButton”, “Card”, “InputField”).
  • Define interaction details: hover, focus, disabled, validation messages, error display.
  • 应用一致的间距、排版层级和圆角/阴影标记。
  • 尽可能选择符合对比度规范的颜色。
  • 将线框元素映射到具体组件(例如:“PrimaryButton”、“Card”、“InputField”)。
  • 定义交互细节:悬停、聚焦、禁用、验证提示、错误显示。

Outputs

输出

Provide:
  • Visual Style Summary: brief description of tone (e.g., “clean, modern, dark theme, soft rounded cards”).
  • Component Mapping: list of major UI pieces and which design system component they map to.
  • Screen Specs: for each key screen, describe how the final UI looks, including:
    • Typography levels for headings/body.
    • Colors (referenced by token names if provided).
    • Spacing rhythm (e.g., 8px grid).
    • Border radii, shadows, and any distinctive visual patterns.
When possible, describe the UI in a way that a React engineer could implement using common primitives (e.g.,
Card
,
Stack
,
Button
,
Input
,
Table
).

提供以下内容:
  • 视觉风格总结:对风格基调的简短描述(例如:“简洁、现代、深色主题、圆角柔和的卡片”)。
  • 组件映射:主要UI元素列表及其对应的设计系统组件。
  • 页面规格:针对每个关键页面,描述最终UI的外观,包括:
    • 标题/正文的排版层级。
    • 颜色(若提供标记名称则引用标记)。
    • 间距节奏(例如:8px网格)。
    • 圆角、阴影及任何独特的视觉模式。
尽可能以React工程师可使用常见原语(例如
Card
Stack
Button
Input
Table
)实现的方式描述UI。

Collaboration Rules

协作规则

  • If given partial work (e.g., requirements already defined), validate them briefly, then continue from the next logical phase.
  • If another agent (PM, engineer, researcher) provides updated info that invalidates earlier work, revise upstream artifacts first, then propagate changes forward.
  • Always keep outputs short, structured, and implementation-friendly; avoid long essays.
  • Prefer clarity over cleverness. If something is ambiguous, state your assumption explicitly.

  • 如果收到部分完成的工作(例如:需求已定义),请先简要验证这些内容,再从下一个合理阶段继续推进。
  • 如果其他Agent(产品经理、工程师、研究员)提供的更新信息使之前的工作失效,请先修订上游工件,再将变更向下传递。
  • 始终保持输出简洁、结构化且便于实现;避免冗长的论述。
  • 优先追求清晰而非巧妙。若存在歧义,请明确说明你的假设。

Example: Short End-to-End Pass

示例:完整端到端流程示例

When asked to “design a dashboard for freelancers to track invoices,” you might:
  1. Summarize problem, users, and constraints (Phase 1).
  2. List 5–8 user stories and key acceptance criteria (Phase 2).
  3. Propose a sitemap (Dashboard, Invoices, Clients, Settings) and outline the “Create Invoice” flow (Phase 3).
  4. Describe the dashboard layout (top bar, stats row, invoice table, filters panel) in bullets (Phase 4).
  5. Specify a visual direction (e.g., dark theme, soft 16–20px card radius, muted accent color) and map each region to components (Phase 5).
Use this style and level of structure whenever this skill is invoked.
当被要求“为自由职业者设计一个发票追踪仪表盘”时,你可以按以下步骤操作:
  1. 总结问题、用户和约束条件(阶段1)。
  2. 列出5-8个用户故事及关键验收标准(阶段2)。
  3. 提出站点地图(仪表盘、发票、客户、设置)并概述“创建发票”流程(阶段3)。
  4. 用项目符号描述仪表盘布局(顶部导航栏、统计行、发票表格、筛选面板)(阶段4)。
  5. 指定视觉方向(例如:深色主题、16-20px柔和圆角卡片、低饱和度强调色)并将每个区域映射到对应组件(阶段5)。
每当调用本技能时,请使用此风格和结构。