Detalle del Skill
storyboard
Useful PM artifact for communicating product concepts.
Revisar antes de usar
La revisión automática comprueba relevancia, no seguridad ni respaldo. Lee las instrucciones de la fuente antes de usar este Skill.
SKILL.md
Este extracto es una copia guardada durante la revisión. La fuente externa contiene la versión completa y actual.
--- name: storyboard argument-hint: "[user and problem]" description: Create a six-frame storyboard that shows a user's journey from problem to solution. Use when you need a fast narrative for alignment, concept reviews, or demos. intent: >- Create a 6-frame visual narrative that tells the story of a user's journey from problem to solution, using the classic storytelling arc to build empathy, illustrate value, and make abstract product concepts concrete. Use this to align stakeholders, pitch features, communicate vision, or test if your solution resonates emotionally before building it. type: component theme: pm-artifacts best_for: - "Showing a user's journey from problem to solution in six frames" - "Getting fast alignment without building anything" - "Turning an abstract concept into something people can react to" scenarios: - "I need to pitch a concept next week and slides aren't landing" - "The team can't agree on the experience — show me the journey frame by frame" estimated_time: "20-30 min" --- ## Purpose Create a 6-frame visual narrative that tells the story of a user's journey from problem to solution, using the classic storytelling arc to build empathy, illustrate value, and make abstract product concepts concrete. Use this to align stakeholders, pitch features, communicate vision, or test if your solution resonates emotionally before building it. This is not a UI mockup—it's a storytelling tool that brings the human side of your product to life. ## Input **Works best with:** The user and the problem-to-solution story you want told. **Also useful:** The emotional arc, key moments you know must appear, and the audience for the storyboard (execs, design review, sales). Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended `ARGUMENTS:` line — counts as answers already given. Use it and skip whatever it covers; don't re-ask. **Arriving empty-handed? That works too.** The skill asks who the user is and what changes for them, then builds the six frames. **Example invocation:** `Storyboard: overwhelmed pharmacy tech discovers our auto-refill queue and ends the day on time — for next week's concept review.` ## Key Concepts ### The 6-Frame Storyboard Structure Based on classic narrative arcs, the 6-frame format follows this pattern: 1. **Frame 1: Main Character** — Introduce the persona and their context 2. **Frame 2: The Problem Emerges** — Show the challenge or obstacle they face 3. **Frame 3: The "Oh Crap" Moment** — Escalate the problem to create urgency 4. **Frame 4: The Solution Appears** — Introduce your product/feature 5. **Frame 5: The "Aha" Moment** — Show the user experiencing the breakthrough 6. **Frame 6: Life After the Solution** — Illustrate the improved state ### Why This Works - **Emotional engagement:** Stories create empathy in ways specs can't - **Concrete over abstract:** Visual narrative makes vague concepts tangible - **Memorable:** People remember stories better than feature lists - **Alignment tool:** Stakeholders can react to a story and give feedback - **Low-fidelity:** Doesn't require polished design—sketches work great ### Anti-Patterns (What This Is NOT) - **Not a user flow diagram:** This is emotional storytelling, not process documentation - **Not a feature demo:** Focus on user outcomes, not product capabilities - **Not marketing copy:** Authentic narrative, not hype ### When to Use This - Pitching a new product or feature to stakeholders - Aligning teams on user value (product, design, engineering, execs) - Testing if a product idea resonates emotionally - Communicating vision at all-hands or investor meetings - Validating problem/solution fit before building ### When NOT to Use This - For technical implementation details (use architecture diagrams instead) - When the user problem is trivial or well-understood - As a replacement for user research (storyboards illustrate insights, don't create them) --- ## ALeer la fuente completa en GitHub (abre una página externa)