文章類型

概念校準文 / 系列入口

這篇想先講的一句話

很多 PM 不是沒有數據，而是太習慣把數據當成答案。

dashboard 很會告訴你哪裡掉了、哪裡變慢了、哪個 cohort 比較差，但它通常不會自己把使用者腦中的權衡、現場的限制、流程外的 workaround，一併翻譯給你。那一段空白，就是用戶研究存在的理由。

如果要把這件事講得更精準一點，我會這樣說：

數據擅長指出模式。用戶研究擅長補上脈絡。真正能幫 PM 做出好決策的，不是二選一，而是知道什麼時候哪一種證據剛好不夠。

先從一個很常見的錯覺開始

假設你在做一個訂房產品。

某週你打開 dashboard，看到 Start Booking Rate 沒什麼變，但 Payment Success Rate 突然掉了一截。你第一反應很可能是：

  • 支付流程壞了
  • 價格太高
  • 優惠券失效
  • 支援某些卡別的邏輯出了問題
  • 行動版 UI 有 bug

這些猜測都合理，但它們還只是猜測。

因為同一個「付款成功率下降」，背後可能是完全不同的現實：

  • 使用者到了最後一步才發現總價和預期不一樣
  • 公司旅客需要報帳資訊，但流程裡沒有發票欄位
  • 家人共用一張卡，臨時刷不過
  • 行動網路不穩，OTP 跳出來太慢
  • 使用者其實不是不想買，而是不敢在陌生平台刷卡

你會發現，事件紀錄看得到 drop-off，卻看不到這些人當下在猶豫什麼、切去做了什麼、原本拿什麼替代方案在完成工作。 這不是 analytics 不夠強，而是它原本就不是拿來回答所有問題的。

我會把數據盲點分成三種

這是我認為最值得先建立的判準。因為很多團隊把「再去訪談一下」講得太模糊，結果研究不是太早做，就是太晚做。

1. 語義盲點

你記錄到了事件，卻不確定事件到底代表什麼。

例如：

  • clicked_share
  • saved_listing
  • started_checkout

這些事件在圖上都很好看，但它們不一定真的代表價值、意圖或承諾。

有人按分享，是想推薦朋友，還是想把連結傳給自己晚點看？ 有人收藏房源，是準備回來訂，還是只是拿來比價？ 有人開始結帳，是認真要買，還是想先看總價和取消政策？

這時候問題不是資料量不夠，而是你對事件的語義想得太滿。

2. 脈絡盲點

你知道使用者做了什麼，但不知道他是在什麼情境下做的。

這一種常常最容易被 PM 低估。 因為很多產品上的摩擦，根本不是畫面上那個按鈕本身，而是：

  • 他身旁還有誰
  • 他在通勤、工作、櫃台、車上，還是在家裡
  • 他切去別的工具抄資料
  • 他是不是被另一個內部流程卡住
  • 他是不是要先問主管、問伴侶、問財務

如果你只看 session replay 或事件流，常常只能看到手指怎麼滑，卻看不到環境怎麼逼著他繞路。 這也是為什麼 field research 或 context research 有時候非常值得做，因為你需要看的是使用情境，不只是產品介面。

3. 決策盲點

你看得到流失，卻看不到使用者是怎麼權衡之後才離開的。

有些問題不是 usability 問題，而是 decision problem。 例如：

  • 他不是不懂，而是不急
  • 他不是不喜歡，而是覺得轉換成本太高
  • 他不是不相信功能，而是不相信你這家公司
  • 他不是沒有痛點，而是痛得還不夠深

這種時候，單靠 funnel 常常只會讓你知道「人沒走完」，但不會知道他其實拿什麼標準在決定要不要繼續走。

所以，用戶研究到底在補什麼？

不是補熱鬧，也不是補故事感。

真正有價值的研究，通常在補下面四種東西：

1. 使用者怎麼理解這個問題

也就是他的 mental model。

他覺得自己是在「找房」，還是在「比較風險」？ 他覺得這個產品是在幫他「快速成交」，還是在幫他「安心做決定」？

這個差異會直接影響你怎麼定 activation、怎麼寫 value prop、怎麼設計第一個價值時刻。

2. 使用者真正卡住的是哪一段

很多時候，數據會把問題看成一個漏斗節點，但使用者感受到的其實是一串連動摩擦。

例如 onboarding 轉換差，不一定是第一屏太亂，也可能是：

  • 他不知道你要他先做這件事有什麼好處
  • 他缺少開始用的素材
  • 他害怕做錯不可逆的設定
  • 他不知道填完後下一步會發生什麼

如果不去聽、不去看，PM 很容易把問題修成畫面上的小摩擦，卻漏掉真正讓人不想繼續的那個理由。

3. 使用者用什麼 workaround 在完成工作

這一點特別重要，因為 workaround 往往比抱怨更有資訊量。

有人說「這功能不太方便」，其實很抽象。 但如果你看到他：

  • 先在 Slack 問同事
  • 再去 Excel 整理
  • 最後把結果貼回你的產品

那你就會知道，他真正要完成的工作並不是你目前想像的那一步，而是一整段橫跨多工具的流程。

4. 使用者怎麼排序風險與價值

這是很多成長實驗踩空的原因。

你以為只要把 onboarding 縮短、CTA 寫清楚、paywall 往後放，轉換就會起來。 但有些產品裡，使用者更在意的根本不是便利，而是：

  • 資料安全
  • 決策可回頭
  • 會不會被坑
  • 和既有工作方式的相容性

這些東西不容易直接長在 event schema 裡，但會直接決定轉換和留存。

什麼時候該先做研究，不是先加事件？

我自己會用一個很土但很好用的判斷：

當你們已經可以很清楚描述「發生了什麼」，卻開始對「為什麼會這樣」出現三種以上合理猜測時，就該考慮補研究。

例如：

  • retention 掉了，但你不確定是價值弱、流量品質差，還是提醒時機不對
  • activation 上不去，但你不確定是 TTFV 太長、承諾講不清楚，還是新手根本不知道下一步
  • 某個 segment 特別差，但你不確定是使用情境不同、需求不同，還是流程不相容

這時候再加更多事件，不一定能救你。 因為你缺的可能不是解析度，而是理解框架。

但也不是每件事都要先訪談

這一點很重要，因為很多團隊一聽到 user research，就像看到萬用瑞士刀，什麼都想拿去切。

有幾種情況，我不會先叫 PM 做研究。

1. 你連資料品質都還沒站穩

如果 tracking 壞掉、分母不清、事件延遲、identity 錯亂，那你現在先去訪談，很容易只是拿訪談替代資料治理。

研究不能幫你補 instrumentation bug。

2. 問題其實已經明顯是流程或技術故障

像是某個版本更新後支付錯誤暴增、某張表單欄位 validation 壞掉、特定裝置 crash rate 飆高。 這種問題先 debug，再談研究。

3. 你真正缺的是決策，不是資訊

有些團隊其實不是不知道問題，而是不想做艱難取捨。 例如大家都知道免費版限制太寬、空狀態太空、trial 結束沒有承接，只是沒有人想負責收斂方向。

這時候再去做訪談，常常只是把決策往後拖。

把研究放回 PM 的工作流裡

我會比較推薦把用戶研究放在這樣的位置：

數據先幫你找異常、找模式、找 segment。研究再幫你補上語義、脈絡和決策邏輯。

順序通常會像這樣：

  1. 先用 analytics 看出哪裡掉、誰在掉、什麼時候掉
  2. 寫出幾個目前最合理的 competing hypotheses
  3. 判斷哪些假設需要直接聽使用者、看現場，才能分得開
  4. 補 interviews、field study、diary study 或 usability test
  5. 再把研究回寫成更精準的 tracking、funnel 定義、訊息策略、實驗假設

這樣研究就不會變成和數據平行的一條支線，而會真的變成產品決策系統的一部分。

給 PM 的一個更實際的提醒

很多 PM 其實不是排斥研究，而是怕研究太慢、太軟、太難跟 roadmap 接上。

這個擔心不是沒有道理。 因為如果研究做成下面這個樣子，真的很容易被嫌：

  • 研究問題太大
  • 訪綱太散
  • 找的人不對
  • 結果只剩幾句金句
  • 最後沒有導回決策

但反過來說，如果研究做得對，它補上的往往正是 dashboard 補不起來的那一小段：

  • 使用者以為你在做什麼
  • 他怎麼描述他的工作
  • 他在什麼情境下會拖延
  • 他拿什麼替代方案勉強完成任務
  • 哪個摩擦是真痛，哪個只是嘴上嫌

而這一小段，常常就決定你的 activation、value prop、paywall、lifecycle，到底會不會打到點上。

這個系列接下來會怎麼走

這篇先把一件事講清楚：

用戶研究不是數據的替代品，而是數據盲點的補丁。

下一篇我會接著把 qualitative、quantitative、mixed methods 的邊界切開。 因為很多 PM 以為自己在做「定性研究 vs 定量研究」的選擇，實際上真正要回答的是：

  • 我現在到底在問什麼問題？
  • 我缺的是 pattern，還是 context？
  • 我需要 scale，還是需要把原因拆開？

如果這一關沒切清楚，後面的訪談、fieldwork、recruiting、analysis 都很容易從第一步就歪掉。