IntermediateAgent Skill

UX Researcher Designer

Turn customer interviews and observed behavior into UX research personas and journey maps your team can use. This Skill guides your assistant through research synthesis, shopping-journey analysis and usability study planning, helping connect what customers struggle with to design decisions and the next questions worth testing.

Views
0
Copies
0
Favorites
0
Editorial Score
80/100
01

What this Skill does

A useful persona should summarize evidence about customers, not invent a demographic profile. This Skill provides separate workflows for personas, journey maps, usability studies and synthesis, so the team can move from raw observations to a specific design question.

Supply redacted interviews, relevant behavior data and the journey you want to improve. The bundled persona CLI demonstrates the method using built-in sample data; it does not accept your own file without code changes. For real research, keep the source observations attached to the assistant's analysis.

02

What makes it different

01

Approach and advantage

Separate research workflows make the output fit the question. A journey map can expose handoff or information gaps, while a usability study plan can define the tasks and observations needed to check whether a proposed change helps.

02

What you can use it for

The workflow connects research findings to design decisions and follow-up tests. Keep sample-generated personas separate from customer evidence, and use actual interviews or behavior records when the output will guide a storefront change.

03

Before you install

Inputs to prepare

Redacted interviews, behavior data, target journeys, research questions, and design constraints.

Agent and runtime

Use a Skill-capable agent with file access. Python 3 is required for the bundled Python helpers; inspect their sample schemas before supplying data.

Scope to confirm

The bundled persona CLI runs built-in sample data and exposes no user-file input argument. Real-data automation needs code adaptation; sample personas are not customer research.

04

Install and get started

Copy this request into Codex or Claude Code. The assistant downloads the original repository at the specified commit, installs the complete files and checks required dependencies.

  1. Open Codex or Claude Code with local file and terminal access.
  2. Copy the request below into the app you are using. The assistant will select that app’s installation directory.
  3. Check the returned path and file checks. Start a new session if needed, then ask the assistant to use the installed Skill.
Install ux-researcher-designer in the app I am using and carry out the file installation, not just explain it. Original repository: https://github.com/alirezarezvani/claude-skills.git Commit: 6d2f02ea077eead1bee5411a31bcc6db5a11a70c Skill folder: product-team/skills/ux-researcher-designer 1. Download this exact source into a new directory. Read SKILL.md and its setup references before running any bundled scripts. Do not substitute another author’s package. 2. For Codex, use ~/.agents/skills/ux-researcher-designer; for Claude Code, use ~/.claude/skills/ux-researcher-designer. Install only for my current app. Install the complete Skill folder, including scripts, references, assets and bundled notices. Keep any root license with the installed folder. Check all destination folders first; if any already exist, report differences before replacing them. 3. Compare the source and installed file lists and hashes. Inspect documented runtimes, dependencies and required connections. Configure only the local dependencies needed for this Skill; use an isolated environment when appropriate. Ask me to complete any account login locally, without putting credentials in chat. 4. Report the source commit, actual installation path, file-check results and any remaining runtime setup. Explain how to invoke ux-researcher-designer in this app. Check discovery separately from file copying; start a new session if needed. Do not run production tasks or claim a successful business outcome from installation alone.
05

Original Skill.md

This is the unchanged source SKILL.md for the reviewed version. Install the complete package to retain referenced scripts, assets, and instructions. Starter prompts below are EcomAgentTools examples.

---
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

Get started

Starter prompts for the main use cases—copy and use them directly.

01

Synthesize research-backed customer personas

Synthesize research-backed customer personas Use for: Synthesize research-backed customer personas. Prepare: Redacted interviews, behavior data, target journeys, research questions, and design constraints.

Show prompt and variablesHide prompt and variables
Use the installed ux-researcher-designer Skill. Task: Synthesize research-backed customer personas. Inputs: [INPUT]. Constraints: [CONSTRAINTS]. Check missing information first. Produce a reviewable result with evidence, assumptions, and next steps. The bundled persona CLI runs built-in sample data and exposes no user-file input argument. Real-data automation needs code adaptation; sample personas are not customer research.

Replace these variables

[INPUT]
Redacted interviews, behavior data, target journeys, research questions, and design constraints.
[CONSTRAINTS]
Scope, allowed actions, output format, and review requirements.
02

Map a purchase or onboarding journey

Map a purchase or onboarding journey Use for: Map a purchase or onboarding journey. Prepare: Redacted interviews, behavior data, target journeys, research questions, and design constraints.

Show prompt and variablesHide prompt and variables
Use the installed ux-researcher-designer Skill. Task: Map a purchase or onboarding journey. Inputs: [INPUT]. Constraints: [CONSTRAINTS]. Check missing information first. Produce a reviewable result with evidence, assumptions, and next steps. The bundled persona CLI runs built-in sample data and exposes no user-file input argument. Real-data automation needs code adaptation; sample personas are not customer research.

Replace these variables

[INPUT]
Redacted interviews, behavior data, target journeys, research questions, and design constraints.
[CONSTRAINTS]
Scope, allowed actions, output format, and review requirements.
03

Plan a usability study with observable task success

Plan a usability study with observable task success Use for: Plan a usability study with observable task success. Prepare: Redacted interviews, behavior data, target journeys, research questions, and design constraints.

Show prompt and variablesHide prompt and variables
Use the installed ux-researcher-designer Skill. Task: Plan a usability study with observable task success. Inputs: [INPUT]. Constraints: [CONSTRAINTS]. Check missing information first. Produce a reviewable result with evidence, assumptions, and next steps. The bundled persona CLI runs built-in sample data and exposes no user-file input argument. Real-data automation needs code adaptation; sample personas are not customer research.

Replace these variables

[INPUT]
Redacted interviews, behavior data, target journeys, research questions, and design constraints.
[CONSTRAINTS]
Scope, allowed actions, output format, and review requirements.
07

Worked example: Turn user records into a returns-UX brief

Inputs include 24 synthetic user records, 12 interviews, six support summaries and usability observations about the return entry point, approval state and fees.

Steps and prompt

  1. Prepare the attached business materials, preserving amounts, units, dates and metric definitions.
  2. 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.
  3. Submit the exact prompt below. Read the primary deliverable on the right and download all deliverables for the team handoff.

Case input files: 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.

What the run produced

The primary file produced by this prompt is shown below in its original language.

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.

Merchant business data is synthetic. Website observations, when present, come from the public URLs listed in the report.

08

Risks and operating notes

Known limits

The bundled persona CLI runs built-in sample data and exposes no user-file input argument. Real-data automation needs code adaptation; sample personas are not customer research.

Evidence and review

Source and package files reviewed: GitHub 6d2f02ea077e. This is a static review, not an installation or business-outcome test.

Before acting on the result

Use authorized inputs and keep secrets out of prompts. Review customer-facing claims, calculations, code changes, and any proposed external action before applying them.

Frequently asked questions

What does it do, and what is the advantage?

Structure personas, journey maps, usability studies, and research synthesis. Separate workflows connect observed user needs to design decisions and test plans.

How do I install it and start?

Choose the method for your agent and install the complete package, not just the displayed SKILL.md. Redacted interviews, behavior data, target journeys, research questions, and design constraints. Start a new agent session and explicitly ask to use ux-researcher-designer. Try one use case below with a small sample and review the output.

Which situations is it useful for?

Synthesize research-backed customer personas; Map a purchase or onboarding journey; Plan a usability study with observable task success

What limitations should I know?

The bundled persona CLI runs built-in sample data and exposes no user-file input argument. Real-data automation needs code adaptation; sample personas are not customer research.

What was checked for this page?

Source and package files reviewed: GitHub 6d2f02ea077e. This is a static review, not an installation or business-outcome test.

No reviews yet.

Leave a review

Rate every dimension, then share your real experience.

Task effectiveness
Setup and ease of use
Reliability and guardrails
Documentation clarity
Time to first useful result
Author / maintainer

Alireza Rezvani

Source and package files reviewed: GitHub 6d2f02ea077e. This is a static review, not an installation or business-outcome test.