文章類型
方法文 / 概念校準文
這篇想解的誤會
很多 PM 聽到「定性」和「定量」,腦中浮出的不是研究問題,而是立場。
有人會說自己偏 data-driven,所以先看量化。 也有人會說真正理解使用者一定要做定性。 這兩種說法聽起來都很熟,但其實都容易把問題講歪。
因為 PM 真正該問的不是:
- 我要站哪一邊?
- 這次要做定性還是定量?
而是:
- 我現在到底想回答什麼問題?
- 我缺的是模式、規模、信心,還是脈絡、動機、語義?
- 我需要知道多少人這樣,還是需要知道他們為什麼會這樣?
這一篇就是要先把方法邊界切乾淨。 不然後面你去做訪談、fieldwork、recruiting、analysis,很容易從起點就歪掉。
先講一個我很在意的判準
我覺得最有用的分法,不是把 qualitative 理解成「開放式問題」,把 quantitative 理解成「有數字」。
更好的分法是:
- qualitative:你直接觀察或聽到行為、經驗、態度
- quantitative:你透過量測工具或 instrument,間接收集那些行為或態度的訊號
這個差別看起來小,其實非常重要。
因為它會直接影響你怎麼判斷方法適不適合。
例如:
- 訪談,是直接聽使用者描述經驗
- field study,是直接看他在真實環境中做事
- diary study,是讓他在一段時間裡記錄經驗
- survey,通常是透過設計好的 instrument 蒐集大量回答
- analytics,通常是透過事件與量測系統看 aggregate behaviour
這樣切之後,你就比較不會再說出這種話:
- 開放式 survey 也是定性,所以等於訪談
- 有五個人講同一句,就算定量
- GA 上有數字,所以一定比較硬
- 做過訪談就代表真的理解市場
這些都太快了。
Qualitative 到底擅長什麼
如果把話講白一點,qualitative 最擅長的是:
- 找出語義
- 補上脈絡
- 拆開動機
- 看見使用者怎麼描述問題
- 看見 workaround、猶豫、誤解、風險感
它特別適合用在你還在探索問題、拆原因、建立假設的時候。
例如你想知道:
- 新手為什麼沒有走到 aha moment
- 某一段 onboarding 為什麼讓人停住
- 為什麼某些用戶會說產品有價值,但最後沒有留下來
- 使用者口中的「太麻煩」到底是在說哪種麻煩
- 你的 value prop 為什麼看起來沒打到人
這些問題都有一個共同點: 你不是只想知道比例,而是想拆開原因的結構。
定性最容易給你的,不是結論,而是線索
這點很重要。
很多人對 qualitative 的期待太滿,覺得只要訪談五個人,就應該得到產品方向。 其實更合理的期待通常是:
- 找到你原本看不到的原因
- 聽到使用者怎麼命名這個問題
- 發現你事件定義裡誤判的地方
- 生出更好的 segmentation 維度
- 逼你把假設寫得更準
它比較像把地圖補齊,不是直接替你蓋章定案。
Quantitative 到底擅長什麼
quantitative 的強項則完全不同。
它擅長的是:
- 看 pattern
- 看規模
- 看趨勢
- 看差異是不是穩定存在
- 看變化是不是值得 prioritise
例如你想知道:
- 問題到底是少數人抱怨,還是大族群都在發生
- 哪個 funnel step 掉得最嚴重
- 某個 segment 是否真的特別差
- 某次改動之後,activation 或 retention 有沒有動
- 哪個問題最值得先排進 roadmap
這些問題的共同點是: 你要的是廣度、頻率、程度、比較。
定量最容易給你的,不是原因,而是信心邊界
quantitative 很適合告訴你:
- 這件事不只是兩三個人的抱怨
- 這個 drop-off 不是錯覺
- 這個 segment 真的比較差
- 這次改動不是只有體感變好
但它通常不會自己把 why 補完。
所以當 PM 說「我先看數字再說」,這句話本身沒有錯。 問題是很多人看完數字後,太快把 pattern 當成 explanation。
Mixed methods 不是折衷,而是刻意設計
很多團隊嘴上會說「我們定性定量一起做」,但實際做法常常只是:
- 先訪談幾個人
- 再順手發一份 survey
- 最後把結果排在同一份 deck 裡
這種做法不是完全沒用,但它不一定算得上真的 mixed methods。
比較像樣的 mixed methods,重點不在於你有沒有湊齊兩種方法,而在於:
這兩種證據是不是在回答同一個核心問題,而且彼此之間有設計過怎麼接。
我覺得這裡最實用的,是先理解三種常見接法。
1. 先 quant,再 qual
這很適合用在:
- 你先看到數據異常
- 你知道哪裡有 pattern
- 但你不知道 pattern 背後的原因
例如:
你看到某個 acquisition source 的新用戶 D7 特別差。 這時候你可以先用數據確認差異存在,再去訪談這一群人,拆開是承諾不對、情境不對、還是價值還沒到。
2. 先 qual,再 quant
這適合用在:
- 你剛開始探索問題
- 你還不知道應該怎麼定義事件、分群、問卷選項
- 你想先把語言和假設長出來
例如:
你想研究某個 B2B 流程裡,使用者口中的「太麻煩」到底是指權限、審批、還是跨工具搬運。 先做 qualitative,通常能幫你長出比較準的 survey 選項、tracking 補點、或 segmentation 維度。
3. 兩條同時跑,再回頭對照
這適合用在:
- 問題本來就跨兩層
- 你既需要 pattern,也需要 context
- 你有足夠的時間和資源
例如:
你在做大改版前,先跑量化 benchmark 看任務成功率與完成時間,再配 qualitative session 看使用者在哪些點遲疑、誤解、繞路。 這樣最後不是只有一張分數表,而是知道分數背後到底在發生什麼。
PM 最常犯的三種方法錯配
這一段我覺得很值得寫,因為它比名詞定義更接近真實現場。
錯配一:想知道 why,卻只看 dashboard
這最常見。
團隊看到 activation 掉,就一直加事件、一直切 funnel、一直看 cohort。 做這些不是錯,但如果你真正想回答的是:
- 使用者在想什麼
- 他覺得哪裡不值得
- 他誤會了哪件事
- 他在哪個情境下根本做不下去
那單靠 dashboard 常常會越看越精細,卻還是在原地繞圈。
錯配二:想知道規模,卻只做訪談
訪談可以幫你找到問題,但不適合單獨拿來決定排序。
如果你聽了五個人都提到某個痛點,合理的下一步通常不是馬上 all-in,而是問:
- 這是不是大族群都在發生?
- 它對哪個 segment 最嚴重?
- 它是不是實際影響轉換、留存或 adoption?
- 這個問題和別的問題比,哪個值得先救?
這時候就該回到 quantitative。
錯配三:把 mixed methods 當成資料拼盤
有些團隊同時做了很多東西,看起來很完整:
- 訪談
- survey
- analytics
- support tickets
- session replay
但最後它們只是被放在同一份文件裡,沒有被設計成互相解釋。 這種情況下,資訊很多,判斷反而更亂。
給 PM 的一張簡單選法
如果你現在正在想「那我到底該先用哪一種」,我會建議先不要從方法名稱開始,而是從問題型態開始。
當你在問這種問題,先偏 qualitative
- 為什麼新手停在這裡?
- 他怎麼理解這個流程?
- 他在擔心什麼?
- 他用什麼 workaround 在完成工作?
- 他口中的「麻煩」到底是哪種麻煩?
當你在問這種問題,先偏 quantitative
- 問題有多常發生?
- 影響哪個 segment 最大?
- 哪一步 drop-off 最嚴重?
- 這個問題有沒有真的變好?
- 這個方向值不值得排到前面?
當你在問這種問題,用 mixed methods 最合理
- 這個 pattern 為什麼存在?
- 我該怎麼把原因拆得更準,再變成可驗證的假設?
- 這個抱怨是真的大問題,還是只是高聲量小族群?
- 我想同時知道是否存在、影響多大、為什麼會發生
什麼時候不要硬做 mixed methods
這也值得先講,不然 mixed methods 很容易聽起來像高級標配。
有幾種情況,我不會硬上。
1. 研究問題其實很單純
如果你只是要確認某個 flow 有沒有 obvious usability issue,小規模 qualitative usability test 可能就夠。 不用為了看起來完整,再補一份不會真的改變決策的 survey。
2. 你連核心問題都還沒定義好
如果團隊目前連「到底想學什麼」都很模糊,混兩種方法只會讓混亂變成雙倍。
3. 你沒有能力把兩種證據接起來
Mixed methods 最怕的不是成本高,而是做完之後沒有 integration。 這樣最後就只剩一份比較厚的資料包。
這篇真正想留下來的判斷
我希望 PM 讀完這篇,不是背到更多方法名,而是記住三件事。
第一,qualitative 跟 quantitative 的差別,不只是有沒有數字,而是你是在直接接觸行為與經驗,還是透過量測工具間接推論。
第二,qualitative 比較擅長拆原因與脈絡,quantitative 比較擅長看規模與排序。
第三,mixed methods 的價值不在於你一次用了兩種方法,而在於它們有沒有被設計成一起回答同一個問題。
如果這三件事站穩了,你後面在決定要做 interview、field study、diary study、survey、analytics deep dive 時,會少走很多冤枉路。
下一篇會接什麼
下一篇我會繼續往前走,但不會立刻跳到訪綱細節。
我會先把一個更常見的混亂拆開: 不是所有研究都叫訪談。
因為很多 PM 其實手上只有一把 interview 的錘子,最後看到什麼都想敲成訪談題。 但 user interview、usability test、field study、diary study,解的根本不是同一種問題。
這個邊界先切乾淨,後面你才知道到底該出門、該觀察、該追時間軸,還是該坐下來深挖經驗。