用戶回饋循環：聽懂用戶在說什麼
本篇是「一個人做產品」系列的第 9 / 18 篇。你可以從系列總覽開始閱讀，也可以直接接著看本文。
你不是你的用戶——用戶回饋為什麼重要
讓我告訴你一個我親身經歷的故事。
cloud-on-academy 上線初期，我花了一整個週末重新設計課程頁面的側邊導覽。我把章節樹狀結構做得很漂亮，可以展開、收合、顯示進度百分比、標記已完成的章節。身為工程師，我對這個 UI 非常滿意。
然後我看了 analytics。
用戶根本不用側邊導覽。他們的行為模式是：看完一章，直接點文章底部的「下一章」連結。側邊欄？大部分人從頭到尾沒點過。
我花了一個週末在打磨一個沒人用的功能。
這就是 Solo Builder 最危險的陷阱：因為你自己就是用戶，所以你以為你知道用戶要什麼。
你確實是用戶之一。但你是一個非常特殊的用戶。你知道產品的每一個角落、每一行程式碼、每一個設計決策的背景。你對產品的理解深度和一般用戶完全不同。
一般用戶不會打開 DevTools 看你的 CSS 寫得多漂亮。一般用戶不在乎你用了 Cloudflare Workers 還是 Vercel。一般用戶只在乎一件事：這個東西能不能幫我解決問題。
你需要一套系統，讓用戶告訴你他們真正在乎什麼。而不是你自己猜。
想看 cloud-on-academy 和其他產品的完整實戰經驗？👉 第 13 章：實戰案例——我的四個產品
回饋管道的四個層級
收集用戶回饋不是放一個「聯絡我們」的 email 就好。你需要多個管道，每個管道捕捉不同類型的訊號。
層級 1：行為數據（用戶做了什麼）
這是最客觀的回饋。用戶不需要開口，他們的行為就在告訴你答案。
| 數據 | 告訴你什麼 | 工具 |
|---|---|---|
| 頁面瀏覽量 | 哪些內容最受歡迎 | Google Analytics 4 |
| 跳出率 | 哪些頁面讓人立刻離開 | Google Analytics 4 |
| 功能使用率 | 哪些功能沒人用 | 自建事件追蹤 / Mixpanel 免費版 |
| 用戶路徑 | 用戶怎麼在產品裡移動 | GA4 User Flow / Hotjar |
| 搜尋紀錄 | 用戶在找什麼（但找不到） | 站內搜尋 log |
| 錯誤紀錄 | 用戶遇到什麼問題 | Sentry |
行為數據的好處是不需要用戶配合，你設定好追蹤，數據就自動進來。壞處是它告訴你「發生了什麼」，但不告訴你「為什麼」。
層級 2：被動回饋（用戶主動來找你）
用戶遇到問題或有想法時，主動聯繫你。
管道包括：
- 產品內回饋按鈕：頁面角落放一個「回報問題」或「建議功能」的小按鈕
- Email：最基本的管道，永遠不要關掉
- 社群留言：GitHub Issues、Discord、Telegram
- App Store / Chrome Web Store 評論：如果你有上架的話
被動回饋的特色是：會主動留回饋的人，通常感受很強烈。不是非常滿意，就是非常不滿。中間的大多數人什麼都不會說。
這代表被動回饋有偏差。但它的價值在於深度，用戶會用自己的話告訴你問題的脈絡，這是行為數據做不到的。
層級 3：主動收集（你去問用戶）
不等用戶來找你，而是主動出擊。
| 方式 | 適合時機 | 工具 |
|---|---|---|
| 產品內問卷 | 用戶完成某個動作後 | Google Forms 嵌入 / Tally |
| Email 問卷 | 定期（每季一次） | Google Forms |
| NPS 評分 | 衡量整體滿意度 | 簡單的 1-10 分嵌入 |
| 用戶訪談 | 深入理解特定議題 | Google Meet / Zoom |
主動收集的回覆率通常不高（5-15%），但你拿到的是你想問的問題的答案，而不是用戶自己想說的話。兩者互補。
層級 4：間接訊號（你沒問但能觀察到的）
- 社群媒體提及：有人在 X（前 Twitter）/ Threads 上提到你的產品（社群平台的貼文 Google Alerts 抓不到，要用 Mention、Brand24、Talkwalker Alerts 這類社群監聽工具；Google Alerts 只適合追蹤部落格、新聞網頁類的提及）
- 競品論壇的討論：用戶在競品社群抱怨什麼
- 搜尋趨勢：相關關鍵字的搜尋量變化
- 退訂 / 流失數據：用戶什麼時候離開、離開前做了什麼
這些訊號比較微弱，但有時候最有價值的洞察就藏在這裡。
Solo Builder 的最小回饋系統
四個層級聽起來很多。但你是一個人，你不可能全做。
以下是我建議的最小配置——設定一次，花不到 2 小時：
| 管道 | 工具 | 設定時間 | 維護時間 |
|---|---|---|---|
| 行為追蹤 | Google Analytics 4 | 30 分鐘 | 每週看 10 分鐘 |
| 錯誤追蹤 | Sentry 免費版 | 15 分鐘 | 被動（有告警才看） |
| 產品內回饋 | Google Forms 嵌入 | 15 分鐘 | 被動（有回覆才看） |
| 你的信箱 | 0 分鐘 | 被動 | |
| 社群 | GitHub Discussions 或 Discord | 30 分鐘 | 每天 5 分鐘掃一眼 |
五個管道，設定 1.5 小時，每週維護不到 1 小時。
不要一開始就上 Hotjar、Mixpanel、Canny、Intercom 全家桶。 那些是你有 1000+ 用戶之後才需要考慮的。前期最重要的是：有管道能讓用戶找到你、有數據能讓你看到基本行為。
同樣的「先做最小可行版本」思維，也適用在產品功能開發上，參考 👉 第 4 章：MVP 設計——砍到不能再砍
AI 驅動的回饋分析
回饋收集到了。然後呢？
如果你有 10 個用戶，你可以一條一條看完。但當你有 50、100、500 條回饋時，手動分析就不現實了。
這是 AI 最擅長的場景：從大量非結構化文字中提取結構化的洞察。
傳統做法
- 打開 Google Sheet
- 一條一條讀回饋
- 手動標記分類（bug / feature request / 抱怨 / 讚美）
- 嘗試找出模式
- 花了三小時，結論是「好像很多人想要 X 功能」
→ 主觀、耗時、容易遺漏
AI 加持做法
把所有回饋丟給 AI，讓它幫你做結構化分析：
以下是我的產品在過去一個月收到的用戶回饋（共 47 條）：
[貼上所有回饋內容]
請幫我做以下分析：
1. 分類統計
- 把每條回饋歸類為：Bug、Feature Request、UX 問題、
正面回饋、疑問/求助、其他
- 統計每個分類的數量和百分比
2. 情感分析
- 正面 / 中性 / 負面的比例
- 哪些主題引發最強烈的負面情緒
3. 主題提取
- 歸納出前 5 個最常被提到的主題
- 每個主題有多少條回饋提到
- 附上代表性的原文引用
4. 優先排序建議
- 基於「影響用戶數 × 情緒強度 × 實作難度」，
建議我優先處理的前 3 件事
- 每個建議附上理由
5. 我可能忽略的訊號
- 有沒有只出現 1-2 次但值得注意的回饋？
- 有沒有用戶用不同的方式在說同一件事？AI 在 2 分鐘內就能給你一份結構化的分析報告。
更重要的是，AI 不會有你的偏見。你可能下意識地更注意那些支持你既有想法的回饋（確認偏差）。AI 會一視同仁地處理每一條。
進階：趨勢追蹤
每個月做一次分析不夠。你應該追蹤回饋的趨勢變化：
以下是過去三個月的回饋分析摘要：
一月：[上個月的 AI 分析結果]
二月：[上上個月的 AI 分析結果]
三月：[這個月的 AI 分析結果]
請比較三個月的變化：
1. 哪些問題在好轉？（之前常被提到，現在變少了）
2. 哪些問題在惡化？（之前沒人提，現在越來越多人提）
3. 有沒有新出現的主題？
4. 整體情感趨勢是上升還是下降？這種趨勢分析靠人工幾乎不可能做，因為你不會記得三個月前的回饋細節。但 AI 可以輕鬆比較。
從回饋到功能：轉化管線
分析完回饋，接下來是最關鍵的一步：把回饋轉成你實際要做的事。
很多 Solo Builder 的問題不是「不知道用戶要什麼」，而是「知道了但不知道怎麼排優先順序」。用戶 A 想要功能 X，用戶 B 想要功能 Y，用戶 C 說你的 UI 很醜。你一個人一週只有幾小時，該先做什麼？
回饋分類矩陣
我用一個簡單的 2x2 矩陣來決定：
| 影響用戶多 | 影響用戶少 | |
|---|---|---|
| 實作成本低 | 立刻做 | 有空做 |
| 實作成本高 | 排入 roadmap | 不做 |
「影響用戶多」的判斷依據是：回饋中有多少人提到了類似的需求。 「實作成本」用小時來估：1-2 小時算低、一個週末算中、超過兩個週末算高。
AI 輔助的需求拆解
回饋往往是模糊的。「希望有更好的搜尋功能」——什麼叫「更好」？
用 AI 幫你把模糊的回饋拆解成可執行的項目：
用戶回饋：「搜尋功能不好用，常常找不到想要的文章」
這個回饋被 5 個不同用戶以不同方式提到。
我的產品是一個技術部落格，目前用 Pagefind 做靜態搜尋。
請幫我：
1. 分析「搜尋不好用」可能的具體原因（列出 5 個可能）
2. 每個原因的驗證方式（怎麼確認是不是這個問題）
3. 每個原因的修復方案和預估工時
4. 建議的處理順序（先解決最可能的原因）AI 把一條模糊的回饋變成了五條可驗證、可執行的任務。你不用自己想破頭，丟給 AI，它會列出一堆你沒想到的可能性。
量化 vs. 質性：你兩個都需要
很多工程師天然傾向量化數據，開口就是「給我看數字！」但數字只能告訴你「發生了什麼」，不能告訴你「為什麼」。
| 量化（數字） | 質性（文字） | |
|---|---|---|
| 回答 | 什麼、多少、多常 | 為什麼、怎麼想 |
| 來源 | Analytics、NPS 分數、轉換率 | 訪談、開放式問卷、客服信件 |
| 優點 | 客觀、可追蹤趨勢 | 深入、有脈絡 |
| 缺點 | 沒有脈絡、不知道原因 | 主觀、樣本小 |
| 適合 | 發現問題 | 理解問題 |
正確的流程是：量化發現問題 → 質性理解問題 → 量化驗證修復。
例如：
- 量化：GA4 顯示 checkout 頁面的跳出率是 60%
- 質性：訪談 3 個用戶，發現他們不確定付費後能得到什麼
- 行動：在 checkout 頁面加上「付費後包含」的清單
- 量化：跳出率降到 35%
如何優化 Landing Page 的轉換率，可以參考 👉 第 7 章：Landing Page 與 SEO 入門
AI 輔助用戶訪談分析
如果你做了用戶訪談（即使只是跟朋友聊了 20 分鐘），讓 AI 幫你從對話中提取洞察：
以下是我跟一個用戶的訪談逐字稿（約 20 分鐘的對話）：
[貼上逐字稿或筆記]
請幫我分析這次訪談：
1. 關鍵發現
- 用戶遇到的主要痛點（用他們自己的話）
- 用戶目前的替代方案（他們怎麼解決這個問題）
- 用戶對我們產品的期待 vs. 實際體驗的落差
2. 隱含需求
- 用戶沒有直接說出來，但從對話中可以推斷的需求
- 用戶以為自己要什麼 vs. 實際上需要什麼
3. 可行動的建議
- 基於這次訪談，最值得做的一件事是什麼？
4. 可引用的原話
- 列出 3-5 句最有洞察力的原話（未來可用在 Landing Page）最後一點很實用。用戶自己的話，就是最好的行銷文案。
說「不」的藝術
收集回饋最難的部分不是收集，而是決定不做什麼。
每一條用戶回饋背後都是一個真實的人、真實的需求。說「不」會讓你覺得虧欠。但 Solo Builder 的時間是有限的，你不可能做所有人要求的所有功能。
什麼時候該聽
- 多人獨立提到同一件事：如果五個不相關的用戶都抱怨同一個問題，那大概率是真的問題
- 符合你的產品定位：這個功能讓你的核心價值主張更強嗎？
- 低成本高影響：花 2 小時就能讓很多人受益
- 用戶在流失：如果流失用戶反覆提到同一個原因，那是緊急信號
什麼時候該忽略
- 只有一個人要求：除非那個人代表了你的核心用戶群
- 跟產品定位衝突：「你的部落格平台能不能加購物車功能？」不能，這不是購物車
- 高成本低影響：花三個週末做一個只有 5% 用戶會用的功能？不值得
- 用戶在描述解法而不是問題：「你應該加一個 X 按鈕」，先問他為什麼需要那個按鈕。也許有更簡單的方式解決他的根本需求
- 付費前的功能要求：「如果你加了 X 功能我就付費」。大部分時候，他們不會
回覆模板：優雅地說不
你不需要每次都寫一封長信解釋為什麼不做。準備一個模板：
感謝你的建議！
我有記錄下來，也理解這個功能對你的價值。
目前我在 [當前的優先項目] 上，
短期內可能無法加入這個功能。
如果之後有了更新，我會通知你。
再次感謝你的回饋，這對產品的改進很有幫助！真誠、簡短、不承諾時間。這比沒有回覆好，也比虛假承諾好。
回饋收集的常見陷阱
陷阱 1：只聽最大聲的用戶
最常留回饋的用戶不一定代表大多數用戶。他們可能是 power user（需求跟一般用戶不同）、或者是特別不滿的人。
對策：搭配行為數據。如果最大聲的用戶要求功能 A，但 analytics 顯示 80% 的用戶連功能 B 都沒用過，也許功能 B 的改進比功能 A 更重要。
陷阱 2：把「沒有抱怨」當成「沒有問題」
大部分遇到問題的用戶不會告訴你，他們會默默離開。
對策：看流失數據。用戶在什麼時間點離開？離開前最後做了什麼？哪個頁面的跳出率異常高？沉默的行為比大聲的抱怨更能反映真實問題。
陷阱 3：太快回應回饋
收到回饋後立刻開始做。三天後又收到另一個回饋，又轉方向。反覆改來改去，什麼都沒做好。
對策：設定一個「回饋冷卻期」。收到回饋後不要立刻行動。每月做一次統整分析（用前面的 AI prompt），根據分析結果決定下一步，而不是根據最新一條回饋。
陷阱 4：問用戶「你想要什麼功能」
這是最常見但最沒用的問法。用戶不是產品設計師，他們擅長描述問題，不擅長設計解法。
對策：問「你最近一次 [使用場景] 遇到什麼困難？」而不是「你希望我們加什麼功能？」。The Mom Test 這本書的核心觀點就是這個：問他們的行為，不要問他們的意見。
時間預算：每週 1 小時
最後，把回饋分析納入你的固定時間預算。
| 任務 | 頻率 | 時間 |
|---|---|---|
| 掃一眼 GA4 關鍵指標 | 每週 | 10 分鐘 |
| 讀新的用戶回饋 | 每週 | 15 分鐘 |
| AI 月度回饋分析 | 每月 | 20 分鐘 |
| 更新產品 roadmap | 每月 | 15 分鐘 |
| 每週平均 | 約 35 分鐘 |
不到一小時。
關鍵是固定時間做，而不是隨時被回饋打斷。當你收到一封用戶來信，不要立刻停下手上的開發工作去處理。標記為「待讀」，等到你的回饋時段再統一處理。
批次處理永遠比即時反應有效率。這是上班族 Solo Builder 最需要的紀律。
本章重點回顧
- ⚠️ 你不是你的用戶，不要用自己的直覺替代用戶回饋
- 📊 四層回饋管道：行為數據 → 被動回饋 → 主動收集 → 間接訊號，先建最小系統
- 🤖 AI 回饋分析：2 分鐘完成分類、情感分析、主題提取、優先排序，每月做一次
- 🔄 量化發現問題、質性理解問題、量化驗證修復，三步循環
- ❌ 學會說不：多人獨立提到的才優先做，只有一個人要求的先觀察
- ⏱️ 每週不到 1 小時，固定時間批次處理，不要被回饋隨時打斷
下一步
你現在有了一套回饋收集和分析的系統。你知道用戶在想什麼、要什麼、抱怨什麼。
但用戶的問題不只是「我想要 X 功能」。他們也會在凌晨三點問你：「為什麼我的帳號登不進去？」
下一章，我們來建立一個人的客服與社群系統——用 AI 和自動化把客服時間壓到最低，同時不犧牲用戶體驗。
