user-research-synthesis

name: user-research-synthesislanguage: zh-TWdescription: "分析並綜合使用者研究發現，形成結構化、可行動的洞察。當拿到需要分析和總結的使用者研究資料、訪談記錄、問卷結果或使用者反饋時使用。產出按主題整理的綜合報告：普遍程度資料、支撐引語、痛點分析、功能需求優先順序和建議的下一步。專門處理訪談記錄時請使用 user-interview-synthesis。"

user-research-synthesis 的繁體中文翻譯，英文版本為規範版本。

使用者研究綜合

這個技能幫助分析使用者研究資料，並按結構化方法把它轉化為可行動的洞察。

所需輸入

如未提供，請向使用者詢問：

• 研究資料（訪談記錄、筆記、問卷結果或要點摘要）
• 研究方法（訪談、問卷、可用性測試等）
• 參與者人數及畫像（角色、場景）
• 研究要回答的問題

從大腦讀取 / 寫入大腦

如果存在 professional-brain（brain/），先用它再提問：

• 先讀： 開啟 hypotheses/（這次研究可以驗證或推翻哪些假設）和 context.md（使用者是誰）。
• 之後寫： 更新每個涉及到的假設的狀態，把長期有效的洞察加入 knowledge/users.md，把原始筆記保留在 source/。來自訪談的說法標註為 [interview]，絕不把它們洗成 [data]。

綜合框架

1. 資料收集概覽

• 研究型別：訪談、問卷、可用性測試等
• 參與者畫像：人口特徵、細分群體、樣本量
• 研究問題：我們想了解什麼
• 方法：資料如何收集

2. 識別關鍵主題

按以下結構把發現整理成主題：

主題名稱

• 描述：這個主題代表什麼
• 普遍程度：多少參與者提到（例如"12 位中有 8 位"）
• 支撐引語：2 到 3 條有代表性的原話
• 含義：這對我們的產品意味著什麼

每次研究目標是 4 到 8 個主要主題。

3. 痛點分析

對每個識別出的痛點：

• 痛點：清楚的描述
• 嚴重程度：高 / 中 / 低（依據影響和頻率）
• 當前變通辦法：使用者現在怎麼應對
• 證據：研究中的具體例子

4. 功能需求

分類：

• 必須有：阻礙使用者成功的關鍵需要
• 高價值：會顯著改善體驗
• 最好有：漸進式改進

對每個需求：

• 需求：使用者要求了什麼
• 頻率：出現了多少次
• 使用者原話：有代表性的例子
• 背後的需要：他們為什麼想要它（挖得比表面需求更深）

5. 使用者工作流洞察

記錄觀察到的真實工作流：

• 當前狀態：使用者現在如何完成任務
• 痛點：他們在哪裡卡住
• 理想狀態：他們希望能怎麼做
• 機會：我們能在哪裡增加價值

6. 細分群體洞察

如果研究揭示了不同的使用者群體：

• 群體名稱：描述性的標籤
• 特徵：什麼定義了這個群體
• 獨特需要：他們的需要有何不同
• 規模 / 重要性：用於排優先順序的相對權重

7. 競品洞察

如果使用者提到了競品或替代方案：

• 競品 / 替代方案：他們用什麼
• 為什麼用：它做得好的地方
• 缺口：它做不到的地方
• 切換障礙：他們為什麼沒有完全切換

8. 建議

基於洞察的優先順序建議：

高優先順序

• 附支撐證據的建議
• 預期影響

中優先順序

• 附支撐證據的建議
• 預期影響

低優先順序 / 未來考慮

• 附支撐證據的建議
• 預期影響

9. 待解決問題

發現的研究缺口：

• 我們還需要了解什麼
• 建議的後續研究
• 需要驗證的不確定性

分析指南

綜合訪談時：

• 尋找多個參與者之間的規律
• 同時注意使用者說了什麼和做了什麼
• 留意情緒反應
• 識別待完成的任務（jobs-to-be-done），而不只是功能需求

分析引語時：

• 用"引號"標出原話
• 註明出處：[參與者編號，角色，場景]
• 選擇體現規律的引語，而不是個例
• 正面和負面反饋都要包含

識別主題時：

• 用描述性的名稱，而不是籠統的標籤
• 為每個主題提供證據
• 儘可能量化（"10 位使用者中有 7 位……"）
• 把主題與業務目標聯絡起來

延伸材料

這個技能附帶支援檔案，可用時請使用：

• references/theme-validity.md：什麼時候主題才算真實？綜合有效性規則。在產出時應用它；它包含上面方法摘要壓縮掉的校準和判斷。
• templates/synthesis-report.md：可填寫的成果模板，品質關卡寫在裡面。當使用者想自己完成文件而不是生成時提供。

評分量表（0 到 40）

交付前給這個技能的任何產出打分；32 分以上才算可以交付。

品質檢查

• 主題識別的是多個參與者之間的規律，而不是個別回答
• 洞察與具體的產品決策掛鉤，而不只是觀察
• 每個說法都有支撐證據（引語、人數或例子）
• 觀察和解讀清楚分開
• 發現按影響排序，而不只是羅列

反模式

• 不要羅列每一條個人評論：綜合必須識別參與者之間的規律
• 不要在沒有資料支撐的情況下做解讀上的跳躍
• 不要在理解背後的問題之前就關注功能需求：永遠先識別待完成的任務
• 不要忽視矛盾的資料：衝突的發現必須擺出來並記錄
• 不要在不量化普遍程度的情況下呈現結果：寫明每種觀點有多少參與者持有

主題示例

**主題：引導過程中資訊過載**

**描述**：使用者一致表示，初始設定時呈現的資訊量讓人不知所措，導致引導沒有完成、獲得價值的時間推遲。

**普遍程度**：12 位參與者中有 9 位在沒有提示的情況下提到了這個問題

**支撐引語**：
- "我只想趕緊開始用，但感覺得先讀一本說明書"［P3，市場經理］
- "到第三屏說明的時候，我已經開始不看就點'下一步'了"［P7，銷售代表］
- "真希望有個'快速開始'，給我這種只想試一試的人"［P11，產品設計師］

**含義**：我們現在的引導流程重視完整性勝過參與度。應考慮漸進式展示：讓使用者能很快開始使用產品，在具體場景中再學習高階功能。

**建議行動**：
- 設計一條"快速開始"路徑，讓使用者在 3 分鐘內獲得第一份價值
- 把高階配置移到 App 內的場景化幫助中
- 全量上線前先用 5 到 10 名新使用者測試
- 預期影響：啟用率提升 20% 到 30%

模板輸出結構

綜合研究時，使用這個結構：

# 使用者研究綜合：[研究主題]

## 研究概覽
- **日期**：[日期範圍]
- **方法**：[訪談 / 問卷 / 測試]
- **參與者**：[人數] [使用者型別]
- **研究問題**：
  1. [問題 1]
  2. [問題 2]
  3. [問題 3]

## 執行摘要
[2 到 3 句話概述關鍵發現和含義]

## 關鍵主題

### 主題 1：[主題名稱]
[按上面示例完整記錄主題]

### 主題 2：[主題名稱]
[完整記錄主題]

[繼續寫滿 4 到 8 個主題]

## 痛點彙總

| 痛點 | 嚴重程度 | 頻率 | 當前變通辦法 |
|------------|----------|-----------|-------------------|
| [痛點 1] | 高 | 10/12 位使用者 | [他們怎麼應對] |
| [痛點 2] | 中 | 7/12 位使用者 | [他們怎麼應對] |

## 功能需求

### 必須有
1. **[需求]**：[X] 位參與者提到
   - 原話："[代表性原話]"
   - 背後的需要：[他們為什麼想要]

### 高價值
[類似結構]

### 最好有
[類似結構]

## 建議

### 高優先順序（0 到 3 個月）
1. **[建議]**
   - 支撐證據：[研究資料]
   - 預期影響：[會改善什麼]
   - 工作量估計：[粗略規模]

### 中優先順序（3 到 6 個月）
[類似結構]

### 未來考慮（6 個月以上）
[類似結構]

## 待解決問題
1. [需要更多研究的問題]
2. [需要驗證的不確定性]
3. [需要的後續研究]

## 附錄
- 使用的訪談提綱
- 完整的參與者資訊
- 原始筆記或記錄（連結）

示例觸發語

• “整理這些訪談紀錄。”
• “分析我們的問卷結果。”
• “從使用者回饋裡找主題。”
• “總結這次使用者研究。”