很多人看到使用者說「請加一個新手教學」，就立刻請工程師照著做一個導覽影片。這就像看到朋友咳嗽說想吃冰淇淋，你就真的買冰淇淋給他吃。使用者回饋是使用者遇到困難時，把感受與自己猜想的解法混在一起的一段話。
如果把使用者的解法直接當成功能去做，團隊往往做出了導覽，使用者卻依然卡在同樣的關卡上。
整理回饋時，請把一段話拆成四個清晰的積木：
把這四個積木分開，團隊就能準確找出最適合的解決方案。
拆解回饋時，請確實執行以下動作：
① 情境標出操作時機：寫出使用者在什麼畫面、想做什麼任務。
② 症狀保留原汁原味：完整保留原話中的情緒詞與形容詞，忠實記錄痛點。
③ 需求提煉核心目標：用一句話說明使用者想要達成的實質進展。
④ 解法存入建議欄位：將使用者提出的做法獨立存放，保留後續探索替代方案的空間。
每拆解一條，都要標記事實或推論。這能確保團隊的理解與事實完全吻合。
以下為教學專用範例資料，編號將持續沿用：
F01｜我接受邀請後看到很多專案，不知道自己要看哪一個。
F02｜能不能一登入就跳出新手教學？
F03｜同事說有派任務給我，但我找不到。
F04｜首頁都是空的，我以為邀請失敗了。
F05｜我只想知道今天要做什麼，不想先設定一堆東西。
F06｜左邊選單項目太多，第一次使用看不懂。
F07｜希望有人告訴我這個工作區是做什麼的。
F08｜進來沒有任務，也不知道要等主管還是自己建立。
F09｜個人資料沒填完一直被提醒，但那不是我現在要做的事。
F10｜可不可以寄一封信告訴我第一步？
這十則資料專門用來練習客觀拆解語意，訓練精確提煉問題的能力。
以三則典型回饋進行結構化拆解：
① 回饋 F02 拆解：
② 回饋 F03 拆解：
③ 回饋 F08 拆解：
在 F02 中標記「推論」，後續訪談就能直接向使用者求證，讓事實完整浮現。
背景：
FlowBoard 是教學用虛構專案協作 SaaS。我們研究新成員首次加入工作區的體驗。
任務：
逐則標註回饋中的情境、可觀察症狀、需求訊號、建議解法與待追問問題。
輸入：
【貼上保留編號的回饋原文】
執行規則：
① 保持單則獨立處理，精準對應每一筆回饋。
② 完整保留原始用字，精確記錄使用者字句。
③ 針對推測內容明確標示「推論」。
④ 資訊缺乏時明確標示「待確認」。
⑤ 專注於可觀察之操作事實與具體陳述。
輸出格式：
依序輸出各項欄位：編號、原話摘要、情境、症狀陳述、需求訊號、建議解法、事實與推論標示、待追問項目。
F10
原話摘要：希望用 Email 得知第一步。
情境：加入後（確切時間待確認）
症狀：原文省略具體描述
需求訊號：取得第一步指引（推論）
建議解法：寄送 Email
待追問：使用者當時是否已登入？產品中哪項資訊需要進一步指引？
這比直接記錄「使用者需要歡迎信」更精確，因為它指出方案可能成立的前提，並保留探索更多解法的空間。
執行人工檢視時，請確認以下問題：
最後請一位研究夥伴閱讀拆解結果，遮住建議解法欄，只看情境與症狀，確認能否看出真正的需求訊號。如果能看出，代表問題層提煉得非常乾淨。
建立專屬工具，讓 Claude Code 自動執行清洗：
① 在專案中建立 .claude/skills/feedback-cleaning/SKILL.md 檔案。
② 寫入以下配置內容：
---
name: feedback-cleaning
description: 將使用者回饋拆成情境、症狀、需求訊號與建議解法。當使用者貼上客服、訪談或問卷文字時使用。
---
保持每筆回饋的原始 ID 與原話完整。
明確區分情境、症狀、需求訊號與建議解法。
將使用者的提議保留於建議解法欄位，維持問題與解法的獨立性。
資訊不足時明確列出待驗證問題。
③ 在終端機執行調用指令：
/feedback-cleaning 請整理 feedback/day-07.md，保留每筆 ID，輸出四類欄位。
輸入回饋編號，輸出是一份結構化拆解紀錄，每一列都掛著來源編號與待追問項目：
這就是 Skill 的價值：把團隊的專業工作流程沉澱為穩定的自動化工具。
今天完成的是結構化回饋分類清單。
清楚的問題定義，永遠比急著做出解法更能幫團隊打造出成功的產品。明天將利用這份清單，把 50 則回饋做進一步分群。
iThome鐵人賽
看影片追技術