方法与优势
根据研究问题选择不同流程。旅程图适合找出用户在哪一步缺少信息或遇到衔接问题,可用性测试计划则用于明确让用户完成什么任务、观察哪些行为,从而检查拟议改动是否解决了原来的困难。
把客户访谈和实际行为观察整理成可用于决策的用户画像与用户旅程图。这项 Skill 会帮助助手归纳用户需求、梳理购物过程中的困难,并制定可用性测试计划,让运营与设计团队知道哪些问题有证据支持、应该改哪个环节,以及接下来还需要向用户验证什么。
有用的用户画像应该概括真实观察,而不是凭空编造年龄、职业和偏好。这项 Skill 提供用户画像、旅程图、可用性研究和资料归纳等不同流程,帮助团队从原始反馈中找出具体设计问题。
使用时提供去除身份信息的访谈、相关行为数据和需要改善的路径。附带的画像命令行程序只运行内置示例,未经代码调整不能直接读取你的资料。分析真实用户时,应让助手基于实际观察完成归纳,并保留结论对应的依据。
根据研究问题选择不同流程。旅程图适合找出用户在哪一步缺少信息或遇到衔接问题,可用性测试计划则用于明确让用户完成什么任务、观察哪些行为,从而检查拟议改动是否解决了原来的困难。
把研究发现衔接到具体设计决策和后续验证,避免报告只停留在描述用户。示例程序生成的画像应与真实客户证据分开;如果结果要用于修改店铺,就需要使用实际访谈或行为记录作为判断依据。
脱敏访谈、行为数据、目标旅程、研究问题和设计限制。
使用支持 Skill 且能访问文件的 Agent。随包 Python 辅助工具需要 Python 3;提供数据前先查看样例结构。
随包人物画像 CLI 使用内置样例,没有用户文件输入参数。自动处理真实数据需适配代码,样例画像不等于客户研究。
将指令复制给 Codex 或 Claude Code,让助手从原始仓库下载固定提交,安装完整文件并检查所需依赖。
请在我当前使用的应用中安装 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。文件复制与应用发现分别检查,需要时新建会话。不要执行生产任务,也不要把安装完成说成已确认业务效果。以下为已核对版本未经改写的 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
以下是主要功能的用例提示词,可以直接复制使用。
根据研究证据归纳客户画像 适用于:根据研究证据归纳客户画像。请准备:脱敏访谈、行为数据、目标旅程、研究问题和设计限制。
请使用已安装的 ux-researcher-designer Skill。任务:根据研究证据归纳客户画像。输入:[INPUT]。限制:[CONSTRAINTS]。先检查缺失信息,再输出可审查的结果、依据、假设和下一步。随包人物画像 CLI 使用内置样例,没有用户文件输入参数。自动处理真实数据需适配代码,样例画像不等于客户研究。[INPUT][CONSTRAINTS]绘制购买或上手旅程 适用于:绘制购买或上手旅程。请准备:脱敏访谈、行为数据、目标旅程、研究问题和设计限制。
请使用已安装的 ux-researcher-designer Skill。任务:绘制购买或上手旅程。输入:[INPUT]。限制:[CONSTRAINTS]。先检查缺失信息,再输出可审查的结果、依据、假设和下一步。随包人物画像 CLI 使用内置样例,没有用户文件输入参数。自动处理真实数据需适配代码,样例画像不等于客户研究。[INPUT][CONSTRAINTS]制定以可观察任务成功为标准的可用性研究 适用于:制定以可观察任务成功为标准的可用性研究。请准备:脱敏访谈、行为数据、目标旅程、研究问题和设计限制。
请使用已安装的 ux-researcher-designer Skill。任务:制定以可观察任务成功为标准的可用性研究。输入:[INPUT]。限制:[CONSTRAINTS]。先检查缺失信息,再输出可审查的结果、依据、假设和下一步。随包人物画像 CLI 使用内置样例,没有用户文件输入参数。自动处理真实数据需适配代码,样例画像不等于客户研究。[INPUT][CONSTRAINTS]输入 24 人模拟调查、12 人访谈、6 条客服摘要与可用性记录,问题集中在退货入口、审批状态及费用说明,需要把画像和改版理由连回具体证据。
案例输入资料: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 产生的主要文件,保留实际输出语言。
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.
| Source | Records | How it is used |
|---|---|---|
| brief.users.json | 24 unique U01–U24 | Device segmentation and pain frequency |
| brief.interviews.json | 12, linked to U01–U12 | Goal, route and wording evidence |
| support.json | 6, T1–T6 linked to U01–U06 | Support consequences of navigation and status ambiguity |
| usability_observations.json | 6, P1–P6 | Recorded 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.
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.
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.
| Stage | Current recorded action / touchpoint | Pain and evidence | Design opportunity |
|---|---|---|---|
| Decide to request | Order A100 is unopened, delivered October 20 and requested November 3: 14 elapsed calendar days | merchant.json; within the stated unused 30-day request window, approval still required | Show order-specific eligibility without promising a refund |
| Find the entry | Look at the order page, then the policy | Interview [BEHAVIOR] U01–U12; entry difficulty in U01–U12; T1–T6 | Place Request a return beside the relevant order, with a policy link |
| Understand costs | Seek clarification of shipping fees | Pain codes U01–U06; source does not identify which fee or amount | Distinguish original delivery from return postage; obtain the actual return-postage rule before writing a promise |
| Submit | P1–P4 flagged complete; P5–P6 incomplete; P4–P6 notes describe consulting policy then trying to submit | usability_observations.json P1–P6; no detailed clickstream or screen recording | Test field labels, validation and return-entry discovery separately |
| Interpret confirmation | P1–P3 mistake submission/approval for refund completion | P1–P3 observation text; U01–U09; support T1–T6 | Use separate request, approval and refund-issued states |
| Return / inspection / refund | No supplied observation of these later steps | Merchant requires approval; no refund processing time or return postage supplied | Specify 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.
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.
| Rank | Issue | Frequency | Severity | Solvability | Score | First action and owner |
|---|---|---|---|---|---|---|
| 1 | Return entry unclear | 12 | 3 | 3 | 108 | Designer adds order-level action; support checks wording against actual route |
| 2 | Approval confused with refund | 9 | 3 | 3 | 81 | Designer and operations define distinct statuses and notification copy |
| 3 | Shipping fee unclear | 6 | 2 | 2 | 24 | Operations 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.
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.
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.
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.
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.
案例中的商家经营资料为模拟数据;涉及网站检查时,报告中的页面观察来自所列公开网址。
随包人物画像 CLI 使用内置样例,没有用户文件输入参数。自动处理真实数据需适配代码,样例画像不等于客户研究。
核对源码及随包文件:GitHub 6d2f02ea077e。本次为静态审查,不代表已完成安装运行或业务效果测试。
使用获授权输入,不把密钥贴入提示词。采用前检查面向客户的声明、计算、代码改动及任何拟议的外部操作。
整理人物画像、旅程图、可用性研究和研究归纳。不同流程把已观察到的用户需求连接到设计决策和测试计划。
按实际 Agent 选择方式,安装完整包,不要只复制页面中的 SKILL.md。 脱敏访谈、行为数据、目标旅程、研究问题和设计限制。 开启新 Agent 会话,明确要求使用 ux-researcher-designer。先用小型样本尝试下方一个场景,并检查输出。
根据研究证据归纳客户画像;绘制购买或上手旅程;制定以可观察任务成功为标准的可用性研究
随包人物画像 CLI 使用内置样例,没有用户文件输入参数。自动处理真实数据需适配代码,样例画像不等于客户研究。
核对源码及随包文件:GitHub 6d2f02ea077e。本次为静态审查,不代表已完成安装运行或业务效果测试。
核对源码及随包文件:GitHub 6d2f02ea077e。本次为静态审查,不代表已完成安装运行或业务效果测试。
暂无评论。