UX 研究员与设计师
根据研究数据生成用户画像、创建用户旅程地图、规划可用性测试以及综合研究结果形成可操作的设计建议。
目录
触发词
当您需要执行以下任务时，请使用此技能：
- "创建用户画像"
- "从数据生成画像"
- "构建客户旅程地图"
- "绘制用户旅程"
- "规划可用性测试"
- "设计可用性研究"
- "分析用户研究"
- "综合访谈结果"
- "识别用户痛点"
- "定义用户原型"
- "计算研究样本量"
- "创建共情地图"
- "识别用户需求"
事先澄清
在生成研究工件之前，请先确定以下输入。当某项信息缺失或模糊且会影响结果时，请主动询问；若不会影响结果，则使用合理的默认值并说明您使用了哪个默认值。
- 可交付成果： 画像、旅程地图、可用性测试计划或研究综合（这决定了要使用哪个工作流程和模板）。
- 可用数据及数量： 分析数据/访谈/调查以及用户数量（影响画像可信度以及是原型画像还是数据驱动画像）。
- 用户目标与范围： 画像、要映射的目标以及起点/终点（影响旅程地图阶段和研究问题）。
请仅询问与当前请求最相关的两三个输入，而非整个列表。如果用户希望立即得到结果，请直接生成并在一开始说明您的假设。
工作流程
工作流 1：生成用户画像
场景： 您拥有用户数据（分析数据、调查、访谈），需要创建一个基于研究结果的画像。
步骤：
-
准备用户数据
所需格式（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"] } ] -
运行画像生成器
# 人类可读输出 python scripts/persona_generator.py # JSON 输出，便于集成 python scripts/persona_generator.py json -
审查生成的组件
组件 检查要点 原型 是否与数据模式匹配？ 人口统计特征 是否源自实际数据？ 目标 是否具体且可操作？ 挫折感 是否包含频率计数？ 设计含义 设计师能否据此采取行动？ -
验证画像
- 向 3-5 位真实用户展示：“这听起来像你吗？”
- 与支持工单交叉核对
- 对照分析数据验证
-
参考： 参见
references/persona-methodology.md了解有效性标准
原型画像画布（轻量级替代方案）
当您缺乏研究数据但需要基于假设的画像来统一团队方向时，请使用原型画像画布。原型画布是假设工具——并非经过验证的事实——旨在供后续测试和改进。
何时使用： 在没有研究预算的情况下启动新项目，快速协调跨职能团队，或创建关于用户的可测试假设。
原型画像画布模板：
### [名称]（例如：“谨慎的卡罗尔”）
**个人简介与人口统计特征：**
- 年龄、地理位置、社会地位、职业阶段
- 在线形象、休闲活动、伴侣状况
**引述**（他们所说、所感、所想）：
- "[直接引用，捕捉他们的视角]"
- "[揭示挫折或愿望的引用]"
**痛点：**
- [与问题空间相关的痛点]
- [与当前变通方案相关的痛点]
**他们试图完成什么：**
- [可观察的行为 1]
- [可观察的行为 2]
**目标**（愿望、需求、梦想）：
- [短期目标]
- [长期抱负]
**态度与影响力：**
- 决策权： [他们能否购买/采纳您的解决方案？]
- 决策影响者： [谁影响他们的决策？]
- 信念与态度： [哪些信念影响他们的选择？]
**待验证的假设：**
- [该画像成立必须成立的首要假设]
- [第二个假设]
- [第三个假设]
原型画像之后的下一步：
- 生成用于验证假设的访谈问题（推荐）
- 生成反画像以界定范围边界
- 转换为单页利益相关者简报
工作流 2：创建旅程地图
场景： 您需要可视化针对特定目标的端到端用户体验。
步骤：
-
定义范围
元素 描述 画像 哪种用户类型 目标 他们要达成什么 起点 触发旅程的事件 终点 成功标准 时间跨度 小时/天/周 -
收集旅程数据
来源：
- 用户访谈（询问“请带我走一遍……”）
- 会话录制
- 分析数据（漏斗、流失点）
- 支持工单
-
绘制阶段
典型的 B2B SaaS 阶段：
认知 → 评估 → 上手 → 采用 → 拥护 -
为每个阶段填写层级
阶段：[名称] ├── 操作：用户在做什么？ ├── 接触点：他们在哪里互动？ ├── 情绪：他们感觉如何？(1-5) ├── 痛点：什么让他们感到沮丧？ └── 机会：我们可以在哪些方面改进？ -
绘制三种体验路径（不仅仅是快乐路径）
阶段 快乐路径 失败路径 困难路径 认知 通过搜索找到产品 从未发现产品 先找到竞争对手 考虑 明确的价值主张 被定价搞糊涂 需要经理批准 决策 简单的注册流程 表单错误，放弃 法务审查延迟 交付与使用 顺利上手 无法导入数据 需要变通方案 忠诚 成为拥护者 静默流失 留下但抱怨 - 快乐路径： 一切按设计运行。
- 失败路径： 用户无法完成目标并流失。
- 困难路径： 用户完成了目标，但遇到摩擦、变通方案或挫折感。
-
为每个阶段添加 KPI 和负责人
阶段 领先指标 滞后指标 团队负责人 认知 网站访问量、广告展示量 品牌回忆度 市场部 考虑 演示请求、定价页面浏览量 MQL 转化率 市场/销售部 决策 试用开始、合同发出 成交率 销售部 使用 功能采纳、DAU 留存率 产品部 忠诚 NPS、推荐数量 LTV、扩展收入 客户成功部 -
识别关键摩擦点及干预措施
对于每个摩擦点，记录：
摩擦点 为何重要 干预措施 预期影响 工作量 信心 [描述] [用户/业务影响] [建议的修复] 高/中/低 小/中/大 高/中/低 优先级分数 = 频率 x 严重程度 x 可解性
-
参考： 参见
references/journey-mapping-guide.md了解模板
工作流 3：规划可用性测试
场景： 您需要与真实用户一起验证设计。
步骤：
-
定义研究问题
将模糊的目标转化为可测试的问题：
模糊 可测试 “它容易用吗？” “用户能否在 3 分钟内完成结账？” “用户喜欢它吗？” “用户会选择设计 A 还是 B？” “它有意义吗？” “用户能否在不提示的情况下找到设置？” -
选择方法
方法 参与者 时长 最适合 有主持远程测试 5-8 45-60 分钟 深入洞察 无主持远程测试 10-20 15-20 分钟 快速验证 游击式测试 3-5 5-10 分钟 快速反馈 -
设计任务
良好的任务格式：
场景：“假设你正在计划一次巴黎之旅……” 目标：“在你的预算内预订一家酒店，住 3 晚。” 成功：“你看到确认页面。”任务进展：热身 → 核心 → 次要 → 边缘案例 → 自由探索
-
定义成功指标
指标 目标 完成率 >80% 任务用时 <2 倍预期时间 错误率 <15% 满意度 >4/5 -
准备主持指南
- 出声思考指示
- 非引导性提示
- 任务后问题
-
参考： 参见
references/usability-testing-frameworks.md了解完整指南
工作流 4：综合研究数据
场景： 您拥有原始研究数据（访谈、调查、观察），需要获得可操作的见解。
步骤：
-
编码数据
为每个数据点添加标签：
[GOAL]- 他们想要达成什么[PAIN]- 什么让他们感到沮丧[BEHAVIOR]- 他们实际做了什么[CONTEXT]- 何时/何地使用产品[QUOTE]- 用户的直接原话
-
聚类相似模式
用户 A：每天使用，高级功能，快捷键 用户 B：每天使用，复杂工作流，自动化 用户 C：每周使用，基本需求，偶尔使用 聚类 1：A, B（高级用户） 聚类 2：C（普通用户） -
计算细分群体规模
聚类 用户数 % 可行性 高级用户 18 36% 主要画像 商业用户 15 30% 主要画像 普通用户 12 24% 次要画像 -
提取关键发现
对于每个主题：
- 发现陈述
- 支持证据（引用、数据）
- 频率（X/Y 参与者）
- 业务影响
- 建议
-
确定机会优先级
因素 评分 1-5 频率 这种情况多久发生一次？ 严重程度 它有多大损害？ 广度 会影响多少用户？ 可解性 我们能解决吗？ -
参考： 参见
references/persona-methodology.md了解分析框架
工具参考
persona_generator.py
根据用户研究数据生成数据驱动的画像。
| 参数 | 值 | 默认值 | 描述 |
|---|---|---|---|
| format | (无), json | (无) | 输出格式 |
示例输出：
============================================================
画像：高级用户 Alex
============================================================
📝 主要出于工作目的每天使用产品的用户
原型：高级用户
引述：“我需要能跟上我工作流程的工具”
👤 人口统计特征：
• 年龄范围：25-34
• 地点类型：城市
• 技术熟练度：高级
🎯 目标与需求：
• 高效完成任务
• 自动化工作流
• 访问高级功能
😤 挫折感：
• 加载速度慢 (14/20 名用户)
• 没有键盘快捷键
• API 访问受限
💡 设计含义：
→ 针对速度和效率优化
→ 提供键盘快捷键和高级功能
→ 开放 API 和自动化能力
📈 数据：基于 45 名用户
置信度：高
生成的原型：
| 原型 | 信号 | 设计重点 |
|---|---|---|
| power_user | 每天使用，10+ 功能 | 效率，定制化 |
| casual_user | 每周使用，3-5 功能 | 简单性，引导 |
| business_user | 工作场景，团队使用 | 协作，报告 |
| mobile_first | 主要使用移动设备 | 触控，离线，速度 |
输出组件：
| 组件 | 描述 |
|---|---|
| demographics | 年龄范围、地点、职业、技术等级 |
| psychographics | 动机、价值观、态度、生活方式 |
| behaviors | 使用模式、功能偏好 |
| needs_and_goals | 主要、次要、功能性、情感性 |
| frustrations | 有证据的痛点 |
| scenarios | 情境使用故事 |
| design_implications | 可操作的建议 |
| data_points | 样本量、置信水平 |
快速参考表
研究方法选择
| 问题类型 | 最佳方法 | 样本量 |
|---|---|---|
| “用户做了什么？” | 分析数据、观察 | 100+ 事件 |
| “他们为什么这么做？” | 访谈 | 8-15 名用户 |
| “他们做得如何？” | 可用性测试 | 5-8 名用户 |
| “他们更喜欢什么？” | 调查、A/B 测试 | 50+ 名用户 |
| “他们感觉如何？” | 日记研究、访谈 | 10-15 名用户 |
画像置信度等级
| 样本量 | 置信度 | 用例 |
|---|---|---|
| 5-10 名用户 | 低 | 探索性 |
| 11-30 名用户 | 中 | 方向性 |
| 31+ 名用户 | 高 | 生产级 |
可用性问题严重程度
| 严重程度 | 定义 | 行动 |
|---|---|---|
| 4 - 关键 | 阻止任务完成 | 立即修复 |
| 3 - 重大 | 显著困难 | 在发布前修复 |
| 2 - 次要 | 引起犹豫 | 在可能时修复 |
| 1 - 外观 | 被注意到但不影响使用 | 低优先级 |
访谈问题类型
| 类型 | 示例 | 用途 |
|---|---|---|
| 背景 | “带我走一遍你典型的一天” | 了解环境 |
| 行为 | “给我看看你是怎么做的” | 观察实际动作 |
| 目标 | “你试图达成什么？” | 揭示动机 |
| 痛点 | “最难的部分是什么？” | 识别挫折感 |
| 反思 | “你会改变什么？” | 产生想法 |
知识库
详细的参考指南位于 references/ 目录中：
references/persona-methodology.md- 画像有效性标准和综合框架references/journey-mapping-guide.md- 完整的旅程地图模板和提示references/usability-testing-frameworks.md- 可用性测试方法和主持指南references/research-synthesis-framework.md- 的数据分析和优先级排序技术
这些文件包含更深入的模板、清单以及每个工作流的最佳实践。