storyboard

storyboard 技能概覽

storyboard 技能能幫你把產品想法轉成一個六格敘事，呈現使用者如何從問題走向解法。它特別適合需要快速、以人為中心方式判斷概念的利害關係人，尤其是 demo、提案對齊，以及 Prototypes 的 storyboard。和一般通用 prompt 不同，storyboard 技能提供可重複使用的結構，讓使用者痛點、急迫性、解法與最終收益一目了然。

storyboard 是用來做什麼的

當你需要在做 UI 之前先說明行為、動機或價值時，就適合用 storyboard。它的輸出是一種敘事型素材，不是畫面設計系統。這個差異很重要：當你問的是「這個想法對使用者來說是否合理？」而不是「每個像素該長什麼樣？」時，這個技能最有發揮空間。

這個 storyboard 技能的突出之處

這個技能採用經典的六格敘事弧：角色、問題、升級、解法、突破，以及解法之後的生活。這種結構能減少空泛的產品話術，逼出清楚的前後對照故事。當你的輸入還很粗略、需要 storyboard 把缺漏的假設挖出來時，尤其有用。

最適合的使用情境

這個 storyboard 技能很適合概念評審、產品願景會議、利害關係人 demo，以及早期原型驗證。當你想傳達的是同理心與成果，而不只是功能時，這會是一個不錯的選擇。如果你已經有非常完整的視覺規格，這大概就不是最適合的工具。

如何使用 storyboard 技能

安裝並找到原始檔案

使用以下指令安裝 storyboard 技能：

npx skills add deanpeters/Product-Manager-Skills --skill storyboard

安裝完成後，先讀 SKILL.md，再讀 template.md，最後讀 examples/sample.md。這些檔案會告訴你預期的輸入格式、六格輸出形式，以及什麼才算「做得好」。因為這個 repo 沒有額外的 rules/、resources/ 或 scripts，所以大部分實用指引都集中在這三個檔案裡。

提供給技能正確的輸入

要把 storyboard 用得好，請提供一個明確的使用者、一個具體問題、一個惡化或升級點，以及預期的解法。好的輸入像這樣：「一位自由接案設計師常常漏掉發票，需要一個自動提醒流程。」不好的輸入像這樣：「幫我做一個關於付款的 storyboard。」第二種寫法會留下太多空白，讓模型去猜 persona、風險與結果。

把粗略想法轉成更好的 prompt

呼叫 storyboard 技能時，建議用這個結構：

• 主角是誰？
• 他們想完成什麼？
• 哪裡出問題，或情況怎麼變糟？
• 解法或產品是什麼？
• 使用解法之後改變了什麼？
• 哪種視覺風格應該引導這些畫格？

這能幫模型產出更連貫、也更能支援決策的 storyboard。若是要做 storyboard for Prototypes，請加入使用者情境與原型承諾的價值，不要只寫功能名稱。

產出更好結果的工作流程

先從 persona 和痛點開始，不要先講解法。接著要求六格內容時，要強調情緒轉折，而不只是事件本身。如果第一次輸出看起來很普通，就把輸入收得更緊一點，加上數字、期限，或真實世界的限制，例如浪費掉的時間、可能損失的營收、或令人煩躁的人工步驟。這些細節會讓 storyboard 更可信，也更容易拿去簡報。

storyboard 技能常見問答

storyboard 是 UI 設計技能嗎？

不是。storyboard 技能是用來做敘事溝通，不是做像素層級的介面設計。它幫你說明使用者旅程與產品價值，因此很適合在 prototype 工作之前，或與 prototype 工作並行時使用。

什麼時候該用 storyboard，而不是一般 prompt？

當你想要固定的六格結構、也希望減少 prompt 漂移時，就該用 storyboard。一般 prompt 可以拿來做一次性的概念草案，但如果你需要在多個想法或團隊之間維持相同的敘事格式，storyboard 技能會更合適。

storyboard 指南適合新手嗎？

可以，只要你能描述使用者、問題與期望結果，就很適合。你不需要設計背景，但你需要足夠的產品脈絡，避免畫格內容過於空泛。

storyboard 不太適合處理什麼？

它不能取代 journey mapping、UX 規格，或視覺互動設計。如果你需要很細的流程、邊界情境或元件狀態，應該用其他素材，並把 storyboard 當成框架工具來看。

如何強化 storyboard 技能

在產生前先把使用者故事補強

品質提升最大的一步，就是把 persona 寫得更具體。請加入角色、環境與壓力點。「下班後要對帳發票的中小企業主」會比「有問題的使用者」產出好得多的 storyboard。

加上一個可衡量的後果

當問題帶有明顯代價時，storyboard 技能會更好用：例如時間流失、營收損失、焦慮，或延誤。這會讓第 2 格和第 3 格更真實，也能讓解法看起來是「應得的」，而不是硬塞進去的。

把解法帶來的改變寫得更具體

最好的 storyboard 會呈現明確的前後差異。不要只寫功能名稱；要描述使用者現在能更快做什麼、少掉哪些阻力，或更有把握完成什麼。若是 storyboard for Prototypes，就要描述原型如何改變行為，而不只是畫面長什麼樣。

針對薄弱的畫格反覆修正

如果某一格看起來很薄弱，通常是因為輸入寫得不夠清楚。請修訂 brief 後重新執行 storyboard 技能，並把焦點放在失敗的那一格上：如果問題太模糊，第 2 格就需要更多情境；如果收尾效果不夠強，第 5 格和第 6 格就需要更清楚的結果。