lean-ux-canvas

lean-ux-canvas 技能概覽

lean-ux-canvas 的用途

lean-ux-canvas 技能能幫團隊把模糊的產品想法，整理成 Lean UX Canvas v2：一頁式框架，用來定義商業問題、預期成果、使用者、假設、風險，以及最小可行且最有價值的實驗。它特別適合產品經理、引導者、設計師，以及需要把「我們該做什麼？」先轉成「我們先要學什麼？」的 AI 輔助工作流程。

誰適合安裝

當你需要先做結構化探索，再決定方案時，就適合使用 lean-ux-canvas 技能。它很適合工作坊準備、利害關係人對齊，以及產品早期的問題定義。若你已經有驗證過的待辦清單，只需要落實開發任務，它就沒那麼有用。

它有什麼不同

這個技能的立場很明確：先學習，再開發。這個 repository 把 Lean UX Canvas 當成決策工具，而不是腦力激盪海報；它會推著使用者先定義商業問題、找出最有風險的假設，再選出能用最少工作驗證的實驗。當你不想讓一個「功能需求」裡面默默藏滿假設時，lean-ux-canvas 就特別有價值。

如何使用 lean-ux-canvas 技能

安裝並檢查正確的檔案

先依你的環境執行 lean-ux-canvas 的安裝指令，接著優先閱讀 skills/lean-ux-canvas/SKILL.md。在下 prompt 之前，也要查看 template.md 和 examples/sample.md，因為這些檔案會直接展示 canvas 的實際版型，以及這個技能期待的細節程度。這個 repo 沒有 helper scripts 或 reference folders，所以核心 skill 檔就是主要的權威來源。

用真實情境來提示

lean-ux-canvas 的使用方式最有效的前提，是你提供具體的問題描述，而不是空泛的專案方向。好的輸入會寫明產品範圍、發生了什麼變化、影響到誰，以及哪個指標或行為最重要。例如：「我們在調整 onboarding 後，試用轉付費從 18% 掉到 11%；請幫我為一直無法完成設定的 enterprise admins 建立一份 Lean UX Canvas。」這會比「幫我做一份 onboarding 的 canvas」強得多。

採用務實的工作流程

一個好的 lean-ux-canvas 指引順序是：先描述商業問題，再界定預期成果，接著定義主要使用者族群、列出目前的假設，最後請技能產出假說與最有風險的假設。然後再根據輸出挑選一個小實驗。如果你跳過問題框定，直接要解法，canvas 會變得比較不實用，因為假說區塊本來就依賴清楚的成果與使用者價值。

第一次執行時該要求什麼

當你用 lean-ux-canvas 支援 Skill Authoring 或工作坊時，先要求一份填好的 canvas，再要一段簡短的引導摘要，以及一個優先排序過的實驗。也要把會影響可行性的限制一起交代：時程、可接觸的使用者、可用的測試管道，以及團隊是否能做原型、還是只能做訪談。這些資訊會實際改變「最少工作量」那一段，並讓結果更具可執行性。

lean-ux-canvas 技能常見問題

lean-ux-canvas 只適合工作坊嗎？

不是。lean-ux-canvas 技能也很適合個人產品思考、利害關係人準備，以及 AI 輔助規劃。不過，當你需要一個多人都能回應、挑戰、再一起修正的共同框架時，它最能發揮效果。

它和一般 prompt 有什麼不同？

一般 prompt 可能只會給你想法；lean-ux-canvas 則是刻意把問題、使用者、成果、假說和實驗結構化。當你真正的風險不是想不出點子，而是假設不清楚時，這就很有幫助。如果你其實已經知道解法路徑，那更簡單的 prompt 可能就夠了。

初學者可以用嗎？

可以，只要他們能清楚描述情境。初學者通常需要的是更精準的描述，不是 canvas 格式本身的學習成本。這個技能在輸入包含真實產品脈絡時表現最好，因為抽象 prompt 只會產生抽象假說。

什麼時候不該用？

當你需要的是交付計畫、規格，或 roadmap 時，不要用 lean-ux-canvas。它也不適合用來產出精緻的行銷文案或最終 UI 內容。當你的目標是先判斷一個問題值不值得解、以及先測什麼時，才適合用它。

如何改進 lean-ux-canvas 技能

提供更有力的問題證據

要最快改善 lean-ux-canvas 的輸出，方法就是提供可量化的證據：轉換率下滑、客服量增加、流失訊號、使用落差，或顧客原話。把「使用者很困惑」改成「42% 的試用使用者第一次都無法連接行事曆」。更好的證據，會帶來更好的問題框定與更好的假說。

讓使用者與成果更具體

當使用者族群夠窄、成果敘述可觀察時，這個技能最強。「SMB 帳戶中的管理者需要在 5 分鐘內完成設定」就比「使用者想要更簡單的 onboarding」好。具體化有助於 lean-ux-canvas 技能把使用者收益和商業成果分開，而不是混成籠統說法。

先聚焦最有風險的假設

如果你想讓 lean-ux-canvas 的使用品質更高，可以要求模型指出：如果哪個假設是錯的，整個想法就會失敗。這通常能看出團隊是在賭信任、理解程度、價值感知，還是技術可行性。一旦這點清楚，最少工作量的實驗就更容易挑選。

從 canvas 迭代到測試

第一次輸出之後，只修改會影響下一個決策的區塊：問題、成果、使用者，以及最有風險的假設。接著再要求一個實驗和一個成功訊號。這樣可以讓 lean-ux-canvas 工作流程保持精簡，而不是變成一份冗長的推測文件。