discovery-process

discovery-process 技能總覽

discovery-process 技能是一套結構化工作流程，專門把模糊的產品問題，透過問題框架化、訪談、綜整與實驗，轉化成經過驗證的方向。它特別適合產品經理、UX 研究人員，以及需要的不只是一般腦力激盪提示，而是可重複執行的 discovery-process 來支援 UX Research 與產品決策的跨職能團隊。

這個 discovery-process 技能是做什麼的

當你需要先確認問題是否真實存在、理解它為什麼會出現，並在開發前決定下一步時，就用 discovery-process。它能幫你從「我們覺得使用者在 X 這件事上有困難」往前推進到有證據支撐的後續行動。

哪些人最能受益

這個 discovery-process skill 特別適合在處理留存、流失、啟用、導入流程，或客戶痛點不明確的團隊。當利害關係人需要信心，但團隊手上的證據還不足以支持開發時，它尤其有用。

它的不同之處

它的核心價值在於流程順序：這個技能把問題框架化、訪談規劃、綜整，以及解決方案測試串成一條線，而不是把它們拆成彼此獨立的一次性提示。這讓它比單獨向 LLM 詢問「研究點子」或「使用者訪談問題」更有力。

如何使用 discovery-process 技能

先安裝並閱讀正確的檔案

先透過儲存庫的 skill loader 執行 discovery-process install 步驟，接著先開啟 skills/discovery-process/SKILL.md。然後再查看 template.md 和 examples/sample.md，了解預期的輸出格式，以及完整流程是如何被記錄下來的。

先給它一份真正的 discovery brief

當你的輸入包含問題範圍、目標受眾、商業背景，以及結果會影響哪個決策時，這個技能效果最好。弱的提示會說「幫我們處理 onboarding」；更強的提示會說「self-serve SMB 使用者的 activation 下降了 15%，我們需要知道主因是理解障礙、設定摩擦，還是價值感不足」。

一個實用的提示模式

可以用這種 discovery-process usage 模式：

Run discovery-process for UX Research on our onboarding drop-off problem. Audience: first-time SMB admins. Goal: identify the biggest friction point, draft interview questions, propose a synthesis structure, and suggest one testable solution hypothesis.

如果你已經有證據，就一起提供；如果沒有，也要明講。這個技能知道自己是要從假設、既有資料，還是利害關係人的問題出發時，會更有用。

先讀什麼、再重用什麼

先從 examples 資料夾看一個完整流程的參考，再依照 template 做你自己的筆記。當你把 discovery-process guide 的各個階段當成工作中的產出物來重用時，效果最好：問題框架化、研究計畫、訪談、綜整、機會點、實驗，以及決策。

discovery-process 技能 FAQ

discovery-process 比一般提示更好嗎？

如果你需要的是可重複執行的流程，而不是單一答案，那答案是肯定的。一般提示可以產生訪談問題或摘要，但 discovery-process 能協調整個順序，並讓輸出始終對應到某個決策。

什麼情況下不適合用？

如果問題已經被驗證，你只需要實作細節，就不該用它。對於純內部、非面向使用者的問題，它也不是好選擇，因為 discovery 訪談與綜整未必能帶來多少額外價值。

這對初學者有幫助嗎？

有，只要你能把問題描述清楚。初學者最能受益的方式，是照著 template 填入具體情境，而不是讓技能替你憑空發明研究問題。

它適合 UX Research 工作流程嗎？

適合。discovery-process for UX Research 這個角度是它最強的用途之一，特別是在訪談規劃、綜整結構，以及把發現轉成實驗或決策備忘錄時。

如何改進 discovery-process 技能

先把問題陳述寫得更精準

最好的結果來自能區分症狀、推測原因與商業影響的輸入。例如：「使用者在連結銀行帳戶後就放棄設定；我們懷疑是他們不理解下一步，這可能正在造成 activation 流失。」這比「使用者很困惑」更好。

補上會改變研究計畫的限制

如果你有時程壓力、可接觸的使用者很少，或只聚焦某個狹窄族群，請一開始就說明。這些限制會影響技能應不應該建議 switch interviews、support-ticket review、較輕量的綜整，或更快速的概念測試。

要求可以直接執行的輸出

想讓 discovery-process usage 的結果更好，就請它交付具體產物：訪談指南、綜整框架、機會陳述，以及可驗證的假設。如果你只要求「insights」，輸出通常會太抽象，難以推進成真正的決策。

第一次輸出後再迭代

先用第一版輸出來收斂下一輪。如果問題框架太大，就縮小受眾；如果訪談計畫太制式，就補上行為證據或特定漏斗階段；如果提議的解法太早出現，就要求在構想前先更強調問題驗證。