用户研究工具包

状态：尚未执行。 这是一套可以直接拿去用的材料：访谈提纲、可用性测试任务和记录模板。目前没有任何真实访谈或测试记录，因此本文不包含研究结论。完成研究后，请把结论写进 用户与场景分析，并在那里更新各条假设的状态。

研究目标

验证 用户与场景分析 里的六条假设（H1–H6），回答三个问题：

1. 目标用户现在怎么处理反馈，最痛的环节是哪里？
2. FeedLens 的四个字段和现有准确率，对他们够不够用？
3. 他们愿不愿意把它放进现有流程，卡点在哪？

招募

访谈提纲（约 30 分钟）

开场说明：这次聊天是想了解你平时怎么处理用户反馈，没有标准答案。会做笔记，内容只用于改进一个学生项目，不会公开你的个人信息和公司数据。

第一部分：现状（10 分钟）

第二部分：痛点（10 分钟）

第三部分：对方案的反应（10 分钟）

先不展示产品，口头描述：“有个工具，贴进去一批反馈，它给每条标上类别、情绪、紧急度，再写一句摘要。”

收尾：还有什么我没问到、但你觉得重要的？能否介绍一位同样在处理反馈的朋友？

可用性测试（约 25 分钟）

准备：启动应用，确认顶栏显示模型已加载。请参与者共享屏幕，边做边说出想法。主持人不提示、不解释，只记录。

测试后问三个问题：

1. 用 1–5 分打分：这个工具对你的工作有多大帮助？为什么是这个分数？
2. 如果只能改一个地方，你希望改什么？
3. 什么情况下你会把它推荐给同事？

记录模板

访谈记录

## 访谈 #__

- 日期 / 时长：
- 受访者代号（不记真名）：        角色：        团队规模：
- 负责的产品类型：                反馈主要来源：
- 每周反馈量（估）：              整理频率：

### 现状（Q1–Q4）
- 流程（原话或接近原话）：
- 使用的工具：

### 痛点（Q5–Q8）
- 最近一次漏掉重要反馈的经历：
- 判断紧急度的依据：
- 最不想做的步骤：

### 对方案的反应（Q9–Q12）
- 是否有用 / 何时会用：
- 可接受的错误率与最不能接受的错误：
- 数据外发限制：
- 对类别体系的意见：

### 假设检验
| 假设 | 支持 / 反对 / 无关 | 证据（原话） |
|---|---|---|
| H1 |  |  |
| H2 |  |  |
| H3 |  |  |
| H4 |  |  |
| H5 |  |  |
| H6 |  |  |

### 意外发现

可用性测试记录

## 测试 #__

- 日期：        参与者代号：        设备 / 浏览器：
- 带来的反馈条数：        模型版本（顶栏显示）：

| 任务 | 完成情况（独立完成 / 提示后完成 / 未完成） | 用时 | 卡点与原话 |
|---|---|---|---|
| T1 |  |  |  |
| T2 |  |  |  |
| T3 |  |  |  |
| T4 |  |  |  |
| T5 |  |  |  |
| T6 |  |  |  |
| T7 |  |  |  |
| T8 |  |  |  |

### T5 逐条不同意记录
| 反馈原文（脱敏） | 模型结果 | 参与者认为应是 | 字段 | 理由 |
|---|---|---|---|---|

- 参与者核对的总条数：        不同意的条数：        一致率：

### T7 摘要修改
- 10 条中未修改：    小改（≤3 字）：    重写：

### 测后三问
1. 帮助程度（1–5）与理由：
2. 最希望改的一处：
3. 推荐条件：

结果怎么用

伦理与数据处理

• 开始前明确告知用途，取得口头同意；不录音时也要告知在做笔记。
• 不记录真实姓名和公司名，用代号。
• 参与者带来的反馈在测试前由对方自行脱敏；测试在本地运行的应用上进行，数据不离开其设备。
• 未经明确同意，不把参与者的反馈数据加入训练集或公开测试集。

本页由 docs/11-user-research-kit.md 生成。