文章類型
分析方法文 / 研究 synthesis 文
這篇想先講的一句話
很多團隊其實不是沒做研究，而是研究做完之後，分析像沒有真的開始過。
訪談錄了、筆記也有、Miro 牆貼滿了，最後輸出的卻常常只剩這幾種東西：
- 幾句很有戲的 quote
- 一些「大家都有提到」的印象
- 幾個看起來很合理，但不知道證據多硬的推論
- 一張寫著「pain points」的大白板
這種材料有時能用來帶氣氛，但很難支撐真正的產品判斷。
因為研究分析不是把材料整理得比較好看。
它真正要做的是：
把零散、厚重、充滿情境的 qualitative data，轉成可比較、可追溯、可形成判斷的 evidence structure。
這也是為什麼我很在意一件事：
如果訪談後只剩金句，通常不是使用者不夠真實，而是分析還沒被認真做完。
先分清楚 analysis 和 synthesis，不然很容易一開始就混掉
我很常看到團隊把這兩件事混在一起：
- analysis
- synthesis
混在一起的結果，就是大家一打開逐字稿就開始下結論，然後很快進入 solution mode。
比較穩的順序應該是：
Analysis
先把材料拆開，標記、切分、整理，確認到底有哪些 observation、行為、語句、脈絡反覆出現。
Synthesis
再把這些已經拆開的 evidence 重新組起來，形成主題、結構、pattern、解釋與下一步判斷。
這個差別很重要。
因為很多所謂的「洞察」，其實只是 synthesis 太快、analysis 太薄。
為什麼 qualitative data 這麼容易讓人失真？
因為它很厚，也很誘惑。
你不像在 dashboard 裡面看到一個乾淨數字。
你拿到的是：
- 長逐字稿
- 片段式筆記
- 場景 observation
- participant 自己的語言
- 自己當下的 impression
- observer 的補充
這種資料的難點，不是沒有內容，而是內容太多，而且每一份都很像有故事。
所以最常見的分析偏誤，其實不是技術不夠，而是這幾種：
- 被最會講的人帶走
- 被最戲劇化的案例吸走注意力
- 先有結論，再去找 support quote
- 把自己當下的 interpretation 當 observation
- 很快收斂成幾個痛點標籤，但不知道裡面混了多少不同問題
所以你如果問我 qualitative analysis 最重要的第一步是什麼，我會說：
先讓自己不要太快覺得「我已經懂了」。
Thematic analysis 真正幫你的，不是「做 coding」本身，而是讓模式浮出來
很多人一聽到 thematic analysis，就覺得那是研究員的專業術語，離 PM 有點遠。
但如果把它講白一點，它其實是在做一件很 PM 的事：
把一堆混在一起的原始訊號，拆開、標記，再看哪些 pattern 值得形成判斷。
這裡有三個層次很值得分開：
1. Observation
具體發生了什麼。
例如：
- participant 在比較房源時反覆切到外部聊天工具
- participant 在付款前停住，開始找取消規則
- ops 人員處理例外訂單時會先看 Excel，再回到後台
2. Code
你用比較短、可重複的標籤，去描述一類現象。
例如：
- 外部確認
- 付款前風險檢查
- 後台不足以支撐例外流程
3. Theme
比 code 再高一層，能把多個 code 串成比較有解釋力的 pattern。
例如：
- 高風險決策前，使用者會主動補安全感
- 核心流程以外的例外情境，其實被人工 workaround 吸收
- 系統沒有提供足夠的比較與確認支點
如果沒有這三層，你很容易把一句原話直接升級成洞察。
那其實很危險。
Coding 不是把每句話貼標籤，而是幫後面比較建立最小單位
這裡有個很常見的誤會：
很多人以為 coding 就是很勤勞地幫逐字稿上色。
不是。
比較有用的 coding，不是為了「看起來研究做得很扎實」，而是為了讓你能：
- 比較不同 participant 之間的共同點
- 看出某個問題是在什麼情境下才出現
- 分辨哪些 friction 其實不是同一種 friction
- 回頭追證據時，不用整份逐字稿重看一遍
所以 code 的品質，通常比數量重要。
如果 code 太鬆，最後所有東西都叫「痛點」「不方便」「想確認」。
如果 code 太細，最後一百多個 code 彼此之間完全不能比較。
我自己會用一個很簡單的標準來修 code：
這個標籤能不能幫我跟其他 session 比？
如果不能，多半還不夠好。
Affinity mapping 真正的價值，不是貼滿白板，而是讓 pattern 被看見
Affinity mapping 常常被誤用成一種儀式感：
大家把便利貼貼上牆，開始分群，拍照，結束。
看起來很有 workshop 的味道，但不一定真的有 synthesis。
比較有用的 affinity mapping，重點通常不是牆有多滿，而是這幾件事：
- 你拿去貼的，是 observation / quote / code，不是 solution idea
- 你分群的依據，是 pattern，不是字面相似
- 你會保留「不太合群」的材料，而不是硬塞進最大堆
- 你最後形成的是可以回頭追到證據的 cluster
我自己很在意一件事：
不要太早把 affinity mapping 做成共識機器。
因為很多團隊一看到便利貼分群，就很想快速命名、快速收斂、快速決定下一步。
但如果在 evidence 還不夠穩時就這樣做，很容易把看起來最順的說法誤認為最真的 pattern。
好的洞察，不是金句，而是能同時回答這四個問題
我自己判斷 qualitative insight 有沒有站穩，會看它能不能同時回答這四件事：
1. 現象是什麼？
具體看到什麼 pattern？
2. 它在什麼情境下發生？
不是誰都這樣，不是每次都這樣。
那到底是在什麼時候、什麼流程段、什麼任務、什麼風險感下發生？
3. 證據是什麼？
有哪些 observation、quote、行為脈絡支撐它？
4. 它會改變什麼判斷？
它是改變 priority、改變 framing、改變 target user、改變 problem definition，還是改變 research next step？
如果一個 insight 只回答第一題，看起來通常像漂亮句子。
四題都答得出來，才比較像可以拿去做決策的材料。
不要只找共通點，也要找 negative case
這點很重要，但很少被認真做。
很多分析會自然地往「大家都提到什麼」靠。
這當然有價值，但 qualitative research 不能只看最大公約數。
因為有時真正讓你修正判斷的，反而是：
- 明明同一流程，有一群人完全不卡
- 明明大家都在抱怨某件事，但真正流失的人不是因為這個
- 明明大部分人都有 workaround，只有某一類用戶會直接放棄
- 明明同一句話大家都會講，但背後指的不是同一種問題
這種 negative case 很重要，因為它會逼你把 theme 變得更精確。
不然你很容易做出一種又大又安全、但其實不夠有用的結論。
Qualitative 分析最後不是要產出「研究感」，而是要產出 decision-ready evidence
我很不喜歡那種看起來很厚、但實際上很難用的研究交付物。
像是：
- 五十張 quote 卡片
- 一整牆 pain point sticky notes
- 很長的逐字稿附錄
- 十幾個寫得很漂亮但無法行動的 insight statement
這些不是完全沒用，但如果最後無法幫團隊做判斷，研究就會慢慢被看成「有趣，但不進決策」。
所以分析的最後一步，不只是整理出 theme，而是要回答：
- 這個 pattern 代表的問題層級是什麼
- 它會影響誰
- 它跟哪些數據訊號可以互相驗證
- 它應該推動哪一類下一步
- 再追研究
- 改 tracking
- 修 problem framing
- 做 solution test
- 調整 priority
這樣研究才不會停在牆上。
一個比較穩的分析流程，可以長這樣
如果你要的是 PM 可以真的照著跑的最低配，我會建議這個順序：
- session 後先做短 debrief
- 整理 observation、quote、recording 與 field notes
- 先做第一輪粗 code，不急著命大主題
- 回頭比不同 participant、不同情境、不同用戶類型
- 把相關 code 聚成 cluster
- 找出 pattern，也刻意找 negative case
- 把 cluster 提升成 theme
- 把每個 theme 接回產品問題與決策
- 最後才寫成 insight memo 或 share-out
你會發現，這整條線其實不是「從筆記走到報告」，而是從材料走到判斷。
什麼時候不要太快做 affinity workshop？
這也是我踩過坑後很有感的一點。
有些團隊太愛 workshop，於是資料一收完就直接揪一群人進會議室貼便利貼。
這不一定錯，但有幾個情境我會比較保守：
- session 還太少，材料不夠厚
- 團隊裡很多人沒有看過原始資料
- 大家很急著往 solution 收斂
- 權力差很明顯，某些人一講話就會決定分類方式
- sticky note 上寫的是 interpretation，不是 evidence
這種情況下，先做一輪小範圍 analysis，再開 workshop，通常比較穩。
結語：研究分析不是把故事講漂亮，而是把判斷做紮實
從逐字稿走到洞察，最難的不是工具，也不是 Miro 模板。
難的是你願不願意多花一點時間，讓 evidence 自己長出結構，而不是急著把它收進你原本的結論裡。
這也是我對 qualitative analysis 最核心的看法：
它不是為了讓研究看起來專業。
它是為了讓團隊在做產品判斷時，不只是抓住最會講的那一句。
下一篇，我會接著往前走到問題定義最關鍵、也最容易口號化的一段：
PM 怎麼用研究去確認 JTBD、切換時刻和痛苦指數，並且在還沒搞清楚問題前，不要太早跳進解法。