How to Get Better Product Ideas from User Interviews: Design Thinking and AI-Powered Research Insights

設計思考如何從訪談找到真正需求，再用 AI 整理洞察

做產品時，最常出現的問題不是沒有想法，而是太快進入解法。

使用者說功能不好用，團隊立刻想改功能。
客戶說報表不夠，團隊立刻開始設計新報表。
使用者抱怨流程很麻煩，團隊馬上討論要刪掉哪一個步驟。

但使用者說出口的，通常只是他當下認為的解法，不一定是問題本身。

他說想要更多篩選條件，真正的困擾可能是資料分類混亂。
他說想要自動提醒，真正的困擾可能是不知道事情的優先順序。
他說系統很難用，真正的問題可能不是介面，而是流程本身不合理。

這也是為什麼設計思考、產品開發與服務創新，都離不開使用者訪談。

訪談不是照著問卷把問題問完，也不是找幾個人來稱讚產品。它的目的，是走進使用者真實的工作、生活與決策情境，理解他做了什麼、卡在哪裡、為什麼這樣做，以及他其實在意的是什麼。

AI 出現後，訪談工作確實可以更有效率。

逐字稿可以快速整理。
大量回饋可以初步分類。
不同受訪者的共同痛點可以被比對。
研究者也能更快找到值得回頭確認的矛盾與模式。

但 AI 不能取代跟使用者聊天。

因為真正的洞察，不只在一句回答裡，也在使用者停頓的地方、前後矛盾的地方、描述細節的方式，以及他做的事和他說的事之間的差異。

AI 可以幫團隊整理聲音。
真正理解使用者，仍然需要人。

為什麼使用者訪談比「直接問需求」更重要？

很多人會問：

「你希望產品新增什麼功能？」
「你喜歡這個設計嗎？」
「這個服務好不好用？」

這些問題並非完全不能問，但通常只會得到表面答案或客氣話…

使用者可能說「還不錯」。
可能說「希望更快」。
可能說「功能再多一點」。
也可能因為不想尷尬，而給出禮貌性的正面回覆。

比起問他想要什麼，如果能深入請他描述真實經驗……

上一次遇到這個問題是什麼時候？
當時你原本想完成什麼事？
你是怎麼處理的？
哪一個步驟最花時間？
你後來有沒有放棄？為什麼？
如果沒有這個工具，你會怎麼做？
你曾經用過最順利的一次經驗是什麼？
最讓你挫折的一次是什麼情況？

問題能把對話從「意見」帶回「行為」得到回饋。

而產品、服務與設計真正需要理解的，往往不是使用者的抽象意見，而是他在特定情境下實際採取的行動。

使用者可能說自己重視效率，但實際上花很多時間手動確認資料，因為他更害怕出錯。
使用者可能說不需要教學，但第一次使用時卻反覆詢問客服。
企業客戶可能說價格太高，但真正不願意採購的原因是導入成本、資安疑慮，或內部沒有負責人。

這些資訊，通常不會在第一個問題就出現，需要透過追問、傾聽與觀察慢慢挖出來。

訪談前確認你想得到與理解什麼

使用者訪談不是聊天越久越好。

如果研究目標不清楚，訪談很容易變成收集大量故事，最後卻不知道該怎麼使用。

開始前，用一句話寫下本次訪談想理解的問題。…..

新使用者為什麼註冊後沒有完成第一次核心操作？
中小企業客戶為什麼試用後沒有轉成付費？
使用者在建立報表時，最常卡在哪一個步驟？
現場人員遇到設備問題時，現在如何查找資訊？
消費者購買產品前，最在意哪些不確定性？
使用者為什麼開始改用競爭對手的服務？

這句話不是要限制對話，而是避免訪談過程被太多旁枝問題帶走，接著，把研究問題拆成幾個需要理解的面向…..

面向	想了解的內容
使用情境	問題通常在什麼時間、地點、任務中出現？
行為流程	使用者目前怎麼做？先做什麼、後做什麼？
痛點與阻力	哪裡最花時間、最容易出錯、最令人挫折？
替代方案	沒有產品時，使用者怎麼解決？
決策因素	使用者如何選擇工具、服務或產品？
成功標準	使用者認為什麼情況算真正解決問題？

有清楚的研究目標，才知道要找誰訪談、該問什麼，以及哪些回答需要追問。

跟用戶聊出好點子的四個訪談技巧

1.少問「你想要什麼」，多問「你上次怎麼做」

訪談最容易踩到的陷阱，是直接請使用者設計產品…..

「如果我們新增 AI 自動整理功能，你會想用嗎？」
「你會不會想要一個新的儀表板？」
「如果有這個按鈕，是不是會比較方便？」

這些問題很容易變成引導式問題。

使用者可能因為禮貌、想像困難，或不想否定你，而回答「會啊，感覺不錯」。但這不代表他真的會用，也不代表它能解決問題。

比起問未來假設，更應該問過去發生的真實事件…..

最近一次遇到這個問題，是什麼時候？
你當時要完成什麼事情？
你第一步做了什麼？
中間發生了什麼？
你花了多久？
你找過誰幫忙？
最後怎麼解決？
哪個地方讓你覺得最麻煩？

這種問法能讓使用者講出具體流程，而不是抽象偏好，產品機會通常藏在流程斷點裡。

2.請使用者講「最順」和「最糟」的一次經驗

一般性的問題，容易得到一般性的回答。

但請使用者回想最順利、最挫折、最生氣、最浪費時間的一次經驗，通常更容易得到具體細節……

你用過最順的一次經驗是什麼？當時為什麼順？
最讓你受不了的一次是什麼？
有沒有哪一次你差點放棄？
你有沒有因為這件事出錯、延誤，或被客戶抱怨？
這個流程中，哪一段你最不想再做第二次？
如果今天要教新人處理，你覺得他最容易卡在哪裡？

極端經驗會帶出情緒，而情緒往往能幫助團隊判斷問題的重要性。但要注意，極端案例不等於所有人的共同需求。

一位使用者遇到非常嚴重的問題，可能代表重要風險，也可能只是少見例外。因此，訪談後還需要用更多受訪者、產品數據、客服紀錄或現場觀察來確認這個問題是否具有代表性。

3.保持好奇，不要急著證明自己的想法是對的

訪談最重要的能力不是問問題，而是聽得下去。

當使用者說出與團隊假設不同的答案時，很容易忍不住解釋：

「其實這個功能已經有了。」
「你可能是不知道怎麼操作。」
「如果我們改成這樣，你應該就會用了吧？」

這些話雖然自然，卻可能讓使用者不再說真話，訪談不是產品 Demo，也不是辯論比賽。研究者的工作，是理解使用者的世界，不是替產品辯護….

可以多說一點嗎？
為什麼你會這樣做？
當時你在擔心什麼？
你原本期待發生什麼？
你怎麼判斷這個方法不適合？
後來為什麼改成另一種做法？
這件事對你影響最大的是什麼？

有時候，最有價值的做法是在對方回答後停幾秒。不要急著接下一題，沉默會給使用者更多整理想法的空間，他往往會在停頓後補上一句更重要的內容。

4.訪談不是越長越好，但要留給意外發現一些空間

一般產品或服務訪談，可以先規劃 30 到 45 分鐘。

太短，很難進入真實情境。
太長，受訪者容易疲累，也會開始給出比較表面的回答。

訪談結構…..

時間	訪談內容
5 分鐘	破冰、說明訪談目的、取得錄音與資料使用同意
10 分鐘	了解背景、角色、工作或生活情境
15–20 分鐘	深入討論最近一次真實經驗、流程與痛點
5–10 分鐘	測試假設、確認重點、補充遺漏問題
最後 3 分鐘	詢問是否還有未提到但重要的事情

最後一題可以問…..

「如果今天只能改善一件事，你最希望先改善什麼？」
「有沒有什麼問題我沒問到，但你覺得很重要？」

這兩題常常能得到意外收穫。

訪談問題範例：把「意見」問成「行為」

以下是常見問題的比較。

容易得到表面答案的問法	更容易挖到洞察的問法
你喜歡這個產品嗎？	你上次使用它要完成什麼事？過程順不順？
你會想用 AI 功能嗎？	你目前怎麼處理這件重複工作？哪裡最花時間？
你覺得這個介面好用嗎？	你第一次使用時，在哪一個步驟不知道下一步怎麼做？
你想要哪些新功能？	有什麼事情你現在必須用 Excel、LINE、紙本或其他工具繞著做？
價格會不會太高？	上次你考慮購買但最後沒買，是因為什麼？
你會推薦給朋友嗎？	什麼情況下你願意推薦？什麼情況下你會提醒朋友不要買？
這個流程有問題嗎？	請你帶我走一次上次完成這項任務的流程。

訪談問題，通常有三個特徵…..

問過去，而不是問假設的未來。
問行為，而不是只問喜好。
問細節，而不是只問結論。

AI 可以怎麼加入訪談流程？

AI 最適合用在「加速整理與找線索」，而不是代替研究者解讀使用者，AI 協作方式。

訪談前：用 AI 協助建立研究假設與問題清單

請 AI 協助整理：

目前已知的產品數據與客服問題
可能的使用者分群
初步研究假設
訪談問題草稿
不同角色需要追問的情境題
容易出現引導性的問題

例如可以這樣問 AI：

以claude為範例AI…..

AI 可以提供一個不錯的起點，但訪談問題仍需要由團隊依照產品情境、受訪者角色與研究目的調整。

訪談中：AI 可以記錄，但不要讓它破壞對話

取得受訪者明確同意後，AI 逐字稿工具可以協助記錄對話，減少研究者一邊記筆記、一邊錯過重要表情與細節的問題。

但使用 AI 錄音、轉錄或摘要前，至少要做到幾件事：

明確告知是否錄音、使用什麼工具、資料保存多久
確認受訪者是否同意
不將機密、個資或客戶資料直接丟入未經核准的公開 AI 工具
避免把姓名、公司、帳號、聯絡資訊等敏感資料放進提示詞
對企業客戶、醫療、金融、教育或高敏感資料，先確認公司資安與法務規範

AI 能提高效率，但不能跳過隱私與信任。

訪談後：用 AI 找模式，但回到原始逐字稿確認

訪談結束後，最花時間的通常不是聊天，而是整理。

傳統上，團隊會把訪談內容拆成一張張便條紙，依照相似主題做親和圖法（Affinity Mapping），逐步整理出重複出現的行為、痛點、動機與機會。

AI 可以加快這個過程。

例如，將完成匿名化處理的逐字稿交給 AI，請它協助：

摘要每位受訪者的主要情境與問題
標記重複出現的痛點
區分事實描述、情緒、需求與建議
找出不同角色之間的差異
整理可能的使用者旅程
列出值得回頭確認的矛盾資訊
擷取可代表問題的原話

可以使用這類提示詞：

以下是 8 位使用者訪談逐字稿，已完成匿名化處理。請不要直接下產品結論，先協助我完成研究整理：
1. 依受訪者整理其使用情境、任務、目前做法與主要阻力。
2. 找出重複出現的問題，並標示出現人數。
3. 區分「使用者實際行為」、「使用者主觀意見」與「研究者推論」。
4. 找出逐字稿中彼此矛盾或需要進一步驗證的地方。
5. 每個重要主題都附上 2 至 3 段原始引言。
6. 不要自行補充逐字稿中沒有提到的事實。

這裡有一個很重要的原則…..

AI 提出的主題不是洞察本身，而是待驗證的研究線索。

AI 可能把不同情境混在一起，也可能因為語句相似，就誤以為它們是同一種需求。團隊仍要回到原始內容確認：這個結論是否真的有證據？出現在哪些人身上？是否只是一兩個人的特殊案例？

從逐字稿到洞察
一個比較可靠的分析流程

訪談不是做完就有洞察。

「使用者覺得麻煩」、「大家希望更簡單」、「需要更多功能」這些都還太模糊，無法直接變成產品決策。

可以試著用以下五個步驟，把訪談內容慢慢整理成可行動的洞察…..

第一步：先分開事實、解讀與解法

以使用者說：「我每週都要把三個系統的資料複製到 Excel，整理完再寄給主管。」

事實／行為
使用者每週從三個系統複製資料到 Excel，再寄給主管。

可能問題
資料整理重複、耗時，而且可能出錯。

使用者提出的解法
希望系統能自動產出報表。

團隊洞察假設
使用者真正需要的，也許不是一份更漂亮的報表，而是降低跨系統整合與確認資料正確性的成本。

先把這幾層拆開，才能避免把使用者提出的解法，直接當成唯一答案。

第二步：找出重複的情境與行為模式

不要只看誰抱怨最大聲。

要看哪些問題反覆出現在不同使用者、不同角色或不同資料來源中。

例如，八位受訪者中有六位都提到「資料要跨系統整理」，但原因可能不同：

業務要向主管報告進度
營運人員要追蹤訂單
客服要查詢客戶紀錄
財務要核對資料一致性

這時候，共同問題可能不是「缺少報表」，而是系統之間沒有形成可用的工作流程。

同一個表面需求，可能對應不同情境。
同一個情境，也可能暴露不同產品機會。

第三步：把洞察寫成完整句子

好的洞察不是一句「使用者需要更方便」，在可以用這個結構……

某一類使用者，在某個情境下，為了完成某個任務，必須使用現有替代方法，因此產生明確成本、風險或情緒。

中小企業的營運主管在每週向管理層整理訂單進度時，必須從多個系統手動複製資料到 Excel，因為現有工具無法快速彙整一致資訊，因此不只花費大量時間，也擔心資料錯誤影響決策。

這樣的寫法，比「使用者想要自動報表」更能幫助團隊討論問題。

第四步：把洞察轉成可驗證的假設

有洞察後，不要立刻做完整功能，先寫出需要驗證的假設….

如果我們讓營運主管可以在同一個畫面檢視三個系統的關鍵資料，並清楚標示更新時間與異常項目，他們完成每週報告的時間可以明顯下降。

接著定義要怎麼測試….

用互動原型測試使用流程
先整合一個系統，而不是全部三個
找 5 位目標角色完成指定任務
比較使用舊流程與新流程的時間
觀察是否真的降低錯誤與人工確認
詢問是否願意持續使用或付費

這樣訪談才不只是「收集意見」，而會進入真正的產品探索。

第五步：讓 AI 協助反駁，而不是只幫你支持結論

AI 很容易順著提示詞給出看似完整的答案。除了請 AI 協助整理，也可以請它扮演反方角色……

以下是我們根據使用者訪談得出的洞察與產品假設。請扮演一位嚴格的產品研究主管，不要直接認同我們的結論，請找出....
1. 哪些結論其實只有少量受訪者支持？
2. 哪些地方把使用者意見誤當成真實行為？
3. 哪些問題可能是流程、教育、權限或價格問題，而非產品功能問題？
4. 還缺少哪些證據？5. 下一步最便宜、最快的驗證方法是什麼？

這種用法比請 AI「幫我想更多功能」更有價值，因為研究的目的不是證明原本想法正確，而是降低做錯產品的機率。