中级Agent Skill

用户研究与体验设计

把客户访谈和实际行为观察整理成可用于决策的用户画像与用户旅程图。这项 Skill 会帮助助手归纳用户需求、梳理购物过程中的困难,并制定可用性测试计划,让运营与设计团队知道哪些问题有证据支持、应该改哪个环节,以及接下来还需要向用户验证什么。

浏览量
0
复制次数
0
收藏
0
编辑评分
80/100
01

这个 Skill 是做什么的

有用的用户画像应该概括真实观察,而不是凭空编造年龄、职业和偏好。这项 Skill 提供用户画像、旅程图、可用性研究和资料归纳等不同流程,帮助团队从原始反馈中找出具体设计问题。

使用时提供去除身份信息的访谈、相关行为数据和需要改善的路径。附带的画像命令行程序只运行内置示例,未经代码调整不能直接读取你的资料。分析真实用户时,应让助手基于实际观察完成归纳,并保留结论对应的依据。

02

它有什么特色

01

方法与优势

根据研究问题选择不同流程。旅程图适合找出用户在哪一步缺少信息或遇到衔接问题,可用性测试计划则用于明确让用户完成什么任务、观察哪些行为,从而检查拟议改动是否解决了原来的困难。

02

适用任务

把研究发现衔接到具体设计决策和后续验证,避免报告只停留在描述用户。示例程序生成的画像应与真实客户证据分开;如果结果要用于修改店铺,就需要使用实际访谈或行为记录作为判断依据。

03

安装前的特殊要求

需要准备的输入

脱敏访谈、行为数据、目标旅程、研究问题和设计限制。

Agent 与运行环境

使用支持 Skill 且能访问文件的 Agent。随包 Python 辅助工具需要 Python 3;提供数据前先查看样例结构。

需确认的适用边界

随包人物画像 CLI 使用内置样例,没有用户文件输入参数。自动处理真实数据需适配代码,样例画像不等于客户研究。

04

安装与开始使用

将指令复制给 Codex 或 Claude Code,让助手从原始仓库下载固定提交,安装完整文件并检查所需依赖。

  1. 打开能访问本机文件和终端的 Codex 或 Claude Code。
  2. 复制下方指令发给正在使用的应用,由助手选择该应用的安装目录。
  3. 查看返回的安装路径和文件检查结果;需要时新建会话,再要求助手使用已安装的 Skill。
请在我当前使用的应用中安装 ux-researcher-designer,直接执行文件安装,不要只解释步骤。 原始仓库:https://github.com/alirezarezvani/claude-skills.git 固定提交:6d2f02ea077eead1bee5411a31bcc6db5a11a70c Skill 路径:product-team/skills/ux-researcher-designer 1. 将这个版本下载到新目录。执行随包脚本前,先阅读 SKILL.md 和安装参考文件,不替换成其他作者的包。 2. Codex 安装到 ~/.agents/skills/ux-researcher-designer,Claude Code 安装到 ~/.claude/skills/ux-researcher-designer,只安装到我正在使用的应用。安装完整 Skill 文件夹,保留 scripts、references、assets 和随包声明;将仓库根目录许可证一并保留。先检查所有目标目录;已有安装时,说明差异后再决定是否替换。 3. 比较来源和安装目录的文件清单、文件哈希,检查文档要求的运行时、依赖及外部连接。只配置此 Skill 所需的本地依赖,适用时使用隔离环境;账号登录由我在本地完成,不把凭据贴进聊天。 4. 返回来源提交、实际安装路径、文件检查结果及尚未完成的运行环境配置,说明如何调用 ux-researcher-designer。文件复制与应用发现分别检查,需要时新建会话。不要执行生产任务,也不要把安装完成说成已确认业务效果。
05

原始 Skill.md

以下为已核对版本未经改写的 SKILL.md。安装完整包才能保留引用的脚本、素材和指引。下方启动提示词为 EcomAgentTools 编写的示例。

---
name: "ux-researcher-designer"
description: UX research and design toolkit for Senior UX Designer/Researcher including data-driven persona generation, journey mapping, usability testing frameworks, and research synthesis. Use when conducting user research, creating personas, mapping user journeys, planning usability tests, or validating designs.
---

# UX Researcher & Designer

Generate user personas from research data, create journey maps, plan usability tests, and synthesize research findings into actionable design recommendations.

---

## Table of Contents

- [Trigger Terms](#trigger-terms)
- [Workflows](#workflows)
  - [Workflow 1: Generate User Persona](#workflow-1-generate-user-persona)
  - [Workflow 2: Create Journey Map](#workflow-2-create-journey-map)
  - [Workflow 3: Plan Usability Test](#workflow-3-plan-usability-test)
  - [Workflow 4: Synthesize Research](#workflow-4-synthesize-research)
- [Tool Reference](#tool-reference)
- [Quick Reference Tables](#quick-reference-tables)
- [Knowledge Base](#knowledge-base)

---

## Trigger Terms

Use this skill when you need to:

- "create user persona"
- "generate persona from data"
- "build customer journey map"
- "map user journey"
- "plan usability test"
- "design usability study"
- "analyze user research"
- "synthesize interview findings"
- "identify user pain points"
- "define user archetypes"
- "calculate research sample size"
- "create empathy map"
- "identify user needs"

---

## Workflows

### Workflow 1: Generate User Persona

**Situation:** You have user data (analytics, surveys, interviews) and need to create a research-backed persona.

**Steps:**

1. **Prepare user data**

   Required format (JSON):
   ```json
   [
     {
       "user_id": "user_1",
       "age": 32,
       "usage_frequency": "daily",
       "features_used": ["dashboard", "reports", "export"],
       "primary_device": "desktop",
       "usage_context": "work",
       "tech_proficiency": 7,
       "pain_points": ["slow loading", "confusing UI"]
     }
   ]
   ```

2. **Run persona generator**
   ```bash
   # Human-readable output
   python scripts/persona_generator.py

   # JSON output for integration
   python scripts/persona_generator.py json
   ```

3. **Review generated components**

   | Component | What to Check |
   |-----------|---------------|
   | Archetype | Does it match the data patterns? |
   | Demographics | Are they derived from actual data? |
   | Goals | Are they specific and actionable? |
   | Frustrations | Do they include frequency counts? |
   | Design implications | Can designers act on these? |

4. **Validate persona**

   - Show to 3-5 real users: "Does this sound like you?"
   - Cross-check with support tickets
   - Verify against analytics data

5. **Reference:** See `references/persona-methodology.md` for validity criteria

---

### Workflow 2: Create Journey Map

**Situation:** You need to visualize the end-to-end user experience for a specific goal.

**Steps:**

1. **Define scope**

   | Element | Description |
   |---------|-------------|
   | Persona | Which user type |
   | Goal | What they're trying to achieve |
   | Start | Trigger that begins journey |
   | End | Success criteria |
   | Timeframe | Hours/days/weeks |

2. **Gather journey data**

   Sources:
   - User interviews (ask "walk me through...")
   - Session recordings
   - Analytics (funnel, drop-offs)
   - Support tickets

3. **Map the stages**

   Typical B2B SaaS stages:
   ```
   Awareness → Evaluation → Onboarding → Adoption → Advocacy
   ```

4. **Fill in layers for each stage**

   ```
   Stage: [Name]
   ├── Actions: What does user do?
   ├── Touchpoints: Where do they interact?
   ├── Emotions: How do they feel? (1-5)
   ├── Pain Points: What frustrates them?
   └── Opportunities: Where can we improve?
   ```

5. **Identify opportunities**

   Priority Score = Frequency × Severity × Solvability

6. **Reference:** See `references/journey-mapping-guide.md` for templates

---

### Workflow 3: Plan Usability Test

**Situation:** You need to validate a design with real users.

**Steps:**

1. **Define research questions**

   Transform vague goals into testable questions:

   | Vague | Testable |
   |-------|----------|
   | "Is it easy to use?" | "Can users complete checkout in <3 min?" |
   | "Do users like it?" | "Will users choose Design A or B?" |
   | "Does it make sense?" | "Can users find settings without hints?" |

2. **Select method**

   | Method | Participants | Duration | Best For |
   |--------|--------------|----------|----------|
   | Moderated remote | 5-8 | 45-60 min | Deep insights |
   | Unmoderated remote | 10-20 | 15-20 min | Quick validation |
   | Guerrilla | 3-5 | 5-10 min | Rapid feedback |

3. **Design tasks**

   Good task format:
   ```
   SCENARIO: "Imagine you're planning a trip to Paris..."
   GOAL: "Book a hotel for 3 nights in your budget."
   SUCCESS: "You see the confirmation page."
   ```

   Task progression: Warm-up → Core → Secondary → Edge case → Free exploration

4. **Define success metrics**

   | Metric | Target |
   |--------|--------|
   | Completion rate | >80% |
   | Time on task | <2× expected |
   | Error rate | <15% |
   | Satisfaction | >4/5 |

5. **Prepare moderator guide**

   - Think-aloud instructions
   - Non-leading prompts
   - Post-task questions

6. **Reference:** See `references/usability-testing-frameworks.md` for full guide

---

### Workflow 4: Synthesize Research

**Situation:** You have raw research data (interviews, surveys, observations) and need actionable insights.

**Steps:**

1. **Code the data**

   Tag each data point:
   - `[GOAL]` - What they want to achieve
   - `[PAIN]` - What frustrates them
   - `[BEHAVIOR]` - What they actually do
   - `[CONTEXT]` - When/where they use product
   - `[QUOTE]` - Direct user words

2. **Cluster similar patterns**

   ```
   User A: Uses daily, advanced features, shortcuts
   User B: Uses daily, complex workflows, automation
   User C: Uses weekly, basic needs, occasional

   Cluster 1: A, B (Power Users)
   Cluster 2: C (Casual User)
   ```

3. **Calculate segment sizes**

   | Cluster | Users | % | Viability |
   |---------|-------|---|-----------|
   | Power Users | 18 | 36% | Primary persona |
   | Business Users | 15 | 30% | Primary persona |
   | Casual Users | 12 | 24% | Secondary persona |

4. **Extract key findings**

   For each theme:
   - Finding statement
   - Supporting evidence (quotes, data)
   - Frequency (X/Y participants)
   - Business impact
   - Recommendation

5. **Prioritize opportunities**

   | Factor | Score 1-5 |
   |--------|-----------|
   | Frequency | How often does this occur? |
   | Severity | How much does it hurt? |
   | Breadth | How many users affected? |
   | Solvability | Can we fix this? |

6. **Reference:** See `references/persona-methodology.md` for analysis framework

---

## Tool Reference

### persona_generator.py

Generates data-driven personas from user research data.

| Argument | Values | Default | Description |
|----------|--------|---------|-------------|
| format | (none), json | (none) | Output format |

**Sample Output:**

```
============================================================
PERSONA: Alex the Power User
============================================================

📝 A daily user who primarily uses the product for work purposes

Archetype: Power User
Quote: "I need tools that can keep up with my workflow"

👤 Demographics:
  • Age Range: 25-34
  • Location Type: Urban
  • Tech Proficiency: Advanced

🎯 Goals & Needs:
  • Complete tasks efficiently
  • Automate workflows
  • Access advanced features

😤 Frustrations:
  • Slow loading times (14/20 users)
  • No keyboard shortcuts
  • Limited API access

💡 Design Implications:
  → Optimize for speed and efficiency
  → Provide keyboard shortcuts and power features
  → Expose API and automation capabilities

📈 Data: Based on 45 users
    Confidence: High
```

**Archetypes Generated:**

| Archetype | Signals | Design Focus |
|-----------|---------|--------------|
| power_user | Daily use, 10+ features | Efficiency, customization |
| casual_user | Weekly use, 3-5 features | Simplicity, guidance |
| business_user | Work context, team use | Collaboration, reporting |
| mobile_first | Mobile primary | Touch, offline, speed |

**Output Components:**

| Component | Description |
|-----------|-------------|
| demographics | Age range, location, occupation, tech level |
| psychographics | Motivations, values, attitudes, lifestyle |
| behaviors | Usage patterns, feature preferences |
| needs_and_goals | Primary, secondary, functional, emotional |
| frustrations | Pain points with evidence |
| scenarios | Contextual usage stories |
| design_implications | Actionable recommendations |
| data_points | Sample size, confidence level |

---

## Quick Reference Tables

### Research Method Selection

| Question Type | Best Method | Sample Size |
|---------------|-------------|-------------|
| "What do users do?" | Analytics, observation | 100+ events |
| "Why do they do it?" | Interviews | 8-15 users |
| "How well can they do it?" | Usability test | 5-8 users |
| "What do they prefer?" | Survey, A/B test | 50+ users |
| "What do they feel?" | Diary study, interviews | 10-15 users |

### Persona Confidence Levels

| Sample Size | Confidence | Use Case |
|-------------|------------|----------|
| 5-10 users | Low | Exploratory |
| 11-30 users | Medium | Directional |
| 31+ users | High | Production |

### Usability Issue Severity

| Severity | Definition | Action |
|----------|------------|--------|
| 4 - Critical | Prevents task completion | Fix immediately |
| 3 - Major | Significant difficulty | Fix before release |
| 2 - Minor | Causes hesitation | Fix when possible |
| 1 - Cosmetic | Noticed but not problematic | Low priority |

### Interview Question Types

| Type | Example | Use For |
|------|---------|---------|
| Context | "Walk me through your typical day" | Understanding environment |
| Behavior | "Show me how you do X" | Observing actual actions |
| Goals | "What are you trying to achieve?" | Uncovering motivations |
| Pain | "What's the hardest part?" | Identifying frustrations |
| Reflection | "What would you change?" | Generating ideas |

---

## Knowledge Base

Detailed reference guides in `references/`:

| File | Content |
|------|---------|
| `persona-methodology.md` | Validity criteria, data collection, analysis framework |
| `journey-mapping-guide.md` | Mapping process, templates, opportunity identification |
| `example-personas.md` | 3 complete persona examples with data |
| `usability-testing-frameworks.md` | Test planning, task design, analysis |

---

## Validation Checklist

### Persona Quality
- [ ] Based on 20+ users (minimum)
- [ ] At least 2 data sources (quant + qual)
- [ ] Specific, actionable goals
- [ ] Frustrations include frequency counts
- [ ] Design implications are specific
- [ ] Confidence level stated

### Journey Map Quality
- [ ] Scope clearly defined (persona, goal, timeframe)
- [ ] Based on real user data, not assumptions
- [ ] All layers filled (actions, touchpoints, emotions)
- [ ] Pain points identified per stage
- [ ] Opportunities prioritized

### Usability Test Quality
- [ ] Research questions are testable
- [ ] Tasks are realistic scenarios, not instructions
- [ ] 5+ participants per design
- [ ] Success metrics defined
- [ ] Findings include severity ratings

### Research Synthesis Quality
- [ ] Data coded consistently
- [ ] Patterns based on 3+ data points
- [ ] Findings include evidence
- [ ] Recommendations are actionable
- [ ] Priorities justified

## Related Skills

- **UI Design System** (`product-team/ui-design-system/`) — Research findings inform design system decisions
- **Product Manager Toolkit** (`product-team/product-manager-toolkit/`) — Customer interview analysis complements persona research
06

开始使用

以下是主要功能的用例提示词,可以直接复制使用。

01

根据研究证据归纳客户画像

根据研究证据归纳客户画像 适用于:根据研究证据归纳客户画像。请准备:脱敏访谈、行为数据、目标旅程、研究问题和设计限制。

查看 Prompt 和变量收起 Prompt 和变量
请使用已安装的 ux-researcher-designer Skill。任务:根据研究证据归纳客户画像。输入:[INPUT]。限制:[CONSTRAINTS]。先检查缺失信息,再输出可审查的结果、依据、假设和下一步。随包人物画像 CLI 使用内置样例,没有用户文件输入参数。自动处理真实数据需适配代码,样例画像不等于客户研究。

需要替换的变量

[INPUT]
脱敏访谈、行为数据、目标旅程、研究问题和设计限制。
[CONSTRAINTS]
任务范围、允许的操作、输出格式和审核要求。
02

绘制购买或上手旅程

绘制购买或上手旅程 适用于:绘制购买或上手旅程。请准备:脱敏访谈、行为数据、目标旅程、研究问题和设计限制。

查看 Prompt 和变量收起 Prompt 和变量
请使用已安装的 ux-researcher-designer Skill。任务:绘制购买或上手旅程。输入:[INPUT]。限制:[CONSTRAINTS]。先检查缺失信息,再输出可审查的结果、依据、假设和下一步。随包人物画像 CLI 使用内置样例,没有用户文件输入参数。自动处理真实数据需适配代码,样例画像不等于客户研究。

需要替换的变量

[INPUT]
脱敏访谈、行为数据、目标旅程、研究问题和设计限制。
[CONSTRAINTS]
任务范围、允许的操作、输出格式和审核要求。
03

制定以可观察任务成功为标准的可用性研究

制定以可观察任务成功为标准的可用性研究 适用于:制定以可观察任务成功为标准的可用性研究。请准备:脱敏访谈、行为数据、目标旅程、研究问题和设计限制。

查看 Prompt 和变量收起 Prompt 和变量
请使用已安装的 ux-researcher-designer Skill。任务:制定以可观察任务成功为标准的可用性研究。输入:[INPUT]。限制:[CONSTRAINTS]。先检查缺失信息,再输出可审查的结果、依据、假设和下一步。随包人物画像 CLI 使用内置样例,没有用户文件输入参数。自动处理真实数据需适配代码,样例画像不等于客户研究。

需要替换的变量

[INPUT]
脱敏访谈、行为数据、目标旅程、研究问题和设计限制。
[CONSTRAINTS]
任务范围、允许的操作、输出格式和审核要求。
07

实际使用案例:把用户资料整理成退货入口改版依据

输入 24 人模拟调查、12 人访谈、6 条客服摘要与可用性记录,问题集中在退货入口、审批状态及费用说明,需要把画像和改版理由连回具体证据。

使用步骤与 Prompt

  1. 准备下方案例输入资料,保留商品、政策和经营记录中的金额、单位及时间口径。
  2. 把调查、访谈、客服和可用性记录连到画像与旅程,计算任务完成情况,安排下一轮有明确问题的用户观察。
  3. 提交下方完整 Prompt,查看右侧主要产物;需要交接给同事时,下载包含全部交付文件的压缩包。

案例输入资料:business-inputs.zip

Use the ux-researcher-designer Skill.

Use our survey, interview, support and usability records to brief a redesign of the returns journey. Produce evidence-based personas, a current journey map, prioritized pain points and task-completion calculations. Connect every quotation and finding to a source record, then prepare the next moderated usability study.

The attached business materials are:
- inputs/brief.interviews.json
- inputs/brief.users.json
- inputs/merchant.json
- inputs/support.json
- inputs/usability_observations.json

Deliver a complete result.md report that the operations team can read, plus any finished files needed for this task. Keep supporting calculations and evidence with the deliverables. Write the report in English; use the requested target language for customer-facing copy. The business datasets are fictional examples unless the brief explicitly names a live public website.

运行结果

下方直接展示本次 Prompt 产生的主要文件,保留实际输出语言。

Returns journey redesign brief

Decision for the next design iteration

Put Request a return on the order detail page and distinguish request received, under review, return instructions sent, and refund issued. Explain return postage before submission after the merchant supplies that rule. The supplied records support prioritizing those changes; they do not establish that a redesigned interface improves customer outcomes.

This is an executed analysis of fictional merchant research records. No interviews or participant sessions were conducted during this exercise. All quoted speech below comes from the supplied synthetic records.

Evidence inventory and calculation results

SourceRecordsHow it is used
brief.users.json24 unique U01–U24Device segmentation and pain frequency
brief.interviews.json12, linked to U01–U12Goal, route and wording evidence
support.json6, T1–T6 linked to U01–U06Support consequences of navigation and status ambiguity
usability_observations.json6, P1–P6Recorded completion, time, errors and comprehension flags

The 12 interviewees and six support contacts overlap the 24 surveyed users; they are not 42 independent people. No identifier maps P1–P6 to the survey, so the usability records are a separate analysis set, not an additional six confirmed unique customers. Every interview repeats the same authored sentence; repetition cannot be treated as independent corroboration.

Survey counts: 18/24 mobile (75%), 6/24 desktop (25%); return-entry difficulty 12/24 (50%, U01–U12); approval/refund confusion 9/24 (37.5%, U01–U09); unclear shipping fee 6/24 (25%, U01–U06). Themes overlap. No pain recorded for U13–U24 does not prove a friction-free experience.

Recorded interface completion is 4/6 = 66.7% (P1–P4). Recorded errors are 2/6 = 33.3% (P5–P6). Mean and median duration across all attempts are both 140 seconds; among successful records they are both 120 seconds. Mean supplied satisfaction is 3.0; its scale anchors are not documented. P5 and P6 both take 180 seconds, but the file does not say whether that is a timeout, so no timeout is inferred.

P1–P3 have success=true and error=false while their notes say they mistook approval submission for a completed refund. Therefore 66.7% measures the input file's interface-completion flag, not correct understanding or a successful refund. P4 is the only completed record without that flag, but absence of a note does not verify comprehension. Strict end-to-end success cannot be calculated from this dataset.

The original persona generator was run against these supplied records rather than its bundled sample. Its automatic names, generic lifestyle statements and default recommendations were removed wherever they lacked supporting records. The reviewed profiles below retain only evidence and explicit design hypotheses.

Behavioral profiles

Primary: the mobile order-page return requester

Evidence: U01–U18 use mobile, all 24 records say monthly usage and personal context. U01–U12's interview codes describe checking an order on a phone, looking first at the order page and then the policy, and wanting to submit a return and understand the next step. This supports an order-specific entry point; it does not support assumptions about income, occupation, urgency or offline use.

Representative source quotation: “我找不到退货入口。” — brief.interviews.json, U01, quotes[0]. English translation: “I can't find where to request a return.” This is a supplied synthetic quotation, not a real customer testimonial. U02–U12 contain the same text.

Design needs: a clear order-level action, readable eligibility before form entry, and a confirmation that names the next actor and separates request receipt from approval and refund. The 12 interview records explicitly state the goal of submitting a request and knowing what comes next. U01–U09's pain codes and T1–T6's summaries support the status distinction. Whether a persistent navigation entry is also needed should be tested, not presumed.

Secondary comparison group: desktop order-page users

Evidence: U19–U24 use desktop, report monthly personal use and the same four features. They have no supplied interview or support records and no recorded pain points. This is a six-person comparison group, not a richly validated persona. Keep the same policy meaning and status model across devices; recruit desktop users in the next round to determine whether order-entry visibility and status understanding differ. Do not invent a quote or a desktop-specific frustration.

Current journey, with evidence boundaries

StageCurrent recorded action / touchpointPain and evidenceDesign opportunity
Decide to requestOrder A100 is unopened, delivered October 20 and requested November 3: 14 elapsed calendar daysmerchant.json; within the stated unused 30-day request window, approval still requiredShow order-specific eligibility without promising a refund
Find the entryLook at the order page, then the policyInterview [BEHAVIOR] U01–U12; entry difficulty in U01–U12; T1–T6Place Request a return beside the relevant order, with a policy link
Understand costsSeek clarification of shipping feesPain codes U01–U06; source does not identify which fee or amountDistinguish original delivery from return postage; obtain the actual return-postage rule before writing a promise
SubmitP1–P4 flagged complete; P5–P6 incomplete; P4–P6 notes describe consulting policy then trying to submitusability_observations.json P1–P6; no detailed clickstream or screen recordingTest field labels, validation and return-entry discovery separately
Interpret confirmationP1–P3 mistake submission/approval for refund completionP1–P3 observation text; U01–U09; support T1–T6Use separate request, approval and refund-issued states
Return / inspection / refundNo supplied observation of these later stepsMerchant requires approval; no refund processing time or return postage suppliedSpecify and research these states; do not depict them as observed or completed

No emotion curve is supplied. “Reduce uncertainty” is an interview motivation, not a measured frustration score. A journey diagram should show unknown emotions as unmeasured rather than drawing an invented low point.

Prioritized pain points

Priority score = survey frequency × proposed severity (1–3) × proposed solvability (1–3). Severity and solvability are analyst judgments for this planning exercise, not research measurements. Frequency is counted once per survey user.

RankIssueFrequencySeveritySolvabilityScoreFirst action and owner
1Return entry unclear1233108Designer adds order-level action; support checks wording against actual route
2Approval confused with refund93381Designer and operations define distinct statuses and notification copy
3Shipping fee unclear62224Operations confirms original-delivery and return-postage rules before copy approval

The second issue can be fixed alongside the first and is a release gate because a financial-status misunderstanding can generate avoidable contacts. These scores order work; they do not estimate saved revenue or support deflection.

Proposed interface language

Order action: Request a return

Eligibility note: “You can request a return for an unused item within 30 days of delivery. We will review your request before confirming the next step.”

Request confirmation: “Return request received for order A100. Your request is awaiting review. This does not mean a refund has been issued. We will send the next instructions after review.”

Approval state: “Your return request has been approved. Follow the return instructions provided for your order. Approval of the request is not confirmation that your refund has been issued.”

Refund state: Use “Refund issued” only after the payment record confirms it; display the verified amount and method from that record. The input does not supply an amount or method for this event, so no fictional completed refund is shown.

Postage copy decision: Do not reuse the $5 outbound-delivery fee as a return-postage fee. Operations must supply who pays, when exceptions apply, where the item goes and how any label charge is calculated. This blocks the postage paragraph, not the navigation prototype.

Next moderated usability study

Purpose: determine whether shoppers can find the return route, submit an eligible request and accurately explain its status. Recruit eight consenting adult participants for an exploratory round: six primarily mobile and two primarily desktop, matching the directional 75/25 split. Include a mixture of previous return experience. Use fictional order A100 and a non-production prototype; do not ask for real account, address, payment or order details. Recruit new participants if prior exposure would reveal the solution.

Run 35-minute sessions: consent and context (5 minutes), unassisted tasks (15), comprehension probes (10), debrief (5). Obtain separate permission before recording and define access and deletion before recruitment. Log observations by P01–P08, not names. A second observer records timestamps, help, route, errors and exact statements. No study has been scheduled or conducted by this exercise.

  1. Find and request: “You received this unopened mug two weeks ago and have decided you no longer want it. Show what you would do next.” Start at the order history. Do not mention a return button or its location. Record first route, time to relevant entry, submission and any assistance.
  2. Interpret status: After the prototype displays request receipt, ask “What has happened so far? What do you expect to happen next?” Probe “What, if anything, has happened to your payment?” after the initial answer. Do not tell the participant whether their first answer is correct.
  3. Understand approval: Present the approved-request state. Ask “What would you do now?” Record whether they distinguish sending the item from receiving money.
  4. Understand cost: Once the merchant supplies and the prototype implements the actual postage rule, ask “What would this return cost you, and where did you find that information?” Do not run this task against a prototype containing an invented fee.
  5. Recognize refund: Present a separate, clearly fictional confirmed-refund record. Ask what evidence supports saying a refund was issued. Keep this scenario separate from A100's currently pending request.

Completion definitions are fixed before sessions: entry found without a hint; eligible request submitted without moderator help; status correctly described as received/under review, with no claim that funds were returned. Report interface completion and comprehension separately and jointly. Allow 180 seconds for the entry/submission task, then record a timeout and offer help; assisted completion is not unassisted success. Report all-attempt times with timeout treatment and successful-attempt times separately.

Capture task outcome, path, elapsed seconds, critical error, help count, verbatim comprehension answer and confidence on a defined 1–5 scale (1 not confident, 5 very confident). Suggested iteration criteria: at least 7/8 find the route and submit without help, at least 7/8 distinguish request from refund, and zero participants leave believing funds have been returned at request receipt. These are design gates, not statistically reliable population estimates. Any critical financial-status confusion triggers a copy/state revision and another round even if a numeric gate passes.

Deliver a findings table linked to participant/task/time, a severity-ranked issue list and a revised prototype. Keep observed evidence, interpretation and recommendations in separate columns. Do not claim conversion or support-volume improvement without a later measured rollout.

Handoff

Design owns the order entry and state prototype. Operations supplies postage, return routing, inspection and refund timing. Support reviews language against actual customer questions. Research owns recruitment, consent, task scoring and source-linked notes. Engineering implements only after these rules are approved. The supporting source-calculations.json contains the executed counts, exact contributing IDs and explicit unresolved end-to-end-success field.

案例中的商家经营资料为模拟数据;涉及网站检查时,报告中的页面观察来自所列公开网址。

08

风险与使用注意事项

已知限制

随包人物画像 CLI 使用内置样例,没有用户文件输入参数。自动处理真实数据需适配代码,样例画像不等于客户研究。

证据与复核

核对源码及随包文件:GitHub 6d2f02ea077e。本次为静态审查,不代表已完成安装运行或业务效果测试。

采用结果前

使用获授权输入,不把密钥贴入提示词。采用前检查面向客户的声明、计算、代码改动及任何拟议的外部操作。

常见问题

它能做什么,有什么优势?

整理人物画像、旅程图、可用性研究和研究归纳。不同流程把已观察到的用户需求连接到设计决策和测试计划。

如何安装和开始使用?

按实际 Agent 选择方式,安装完整包,不要只复制页面中的 SKILL.md。 脱敏访谈、行为数据、目标旅程、研究问题和设计限制。 开启新 Agent 会话,明确要求使用 ux-researcher-designer。先用小型样本尝试下方一个场景,并检查输出。

适合哪些使用场景?

根据研究证据归纳客户画像;绘制购买或上手旅程;制定以可观察任务成功为标准的可用性研究

使用前需要了解哪些限制?

随包人物画像 CLI 使用内置样例,没有用户文件输入参数。自动处理真实数据需适配代码,样例画像不等于客户研究。

本页核对了什么?

核对源码及随包文件:GitHub 6d2f02ea077e。本次为静态审查,不代表已完成安装运行或业务效果测试。

暂无评论。

发表评论

请先为每一项打分,再分享你的真实使用体验。

任务有效性
安装与使用难度
稳定性与边界
文档清晰度
首次获得有效结果
作者 / 维护者

Alireza Rezvani

核对源码及随包文件:GitHub 6d2f02ea077e。本次为静态审查,不代表已完成安装运行或业务效果测试。