Create UX storyboards from scratch, from user research, or from existing journey maps. Use this skill whenever a user wants to create a storyboard, visualize a user scenario, illustrate how a user interacts with a product, or communicate a UX story to a team or stakeholders. Also trigger when the user asks to "sketch a user flow", "show how a user would use X", "create a scenario illustration", "map out a use case visually", or wants to present research findings in a visual, narrative format. Even if the user doesn't say "storyboard" explicitly ā if they want to show a sequence of steps a user takes, trigger this skill.
A skill for creating structured, effective UX storyboards that communicate user stories through visual sequences ā for teams, stakeholders, or ideation sessions.
A storyboard communicates a story through images displayed in a sequence of panels that chronologically maps the story's main events. In UX, storyboards provide context about how a user experiences a product or flow ā making it quick to understand and easy to remember.
Every storyboard must have these three elements:
Scenario ā A persona + short description of the situation. Clear enough to understand before looking at the visuals. E.g. "Corporate buyer James needs to replenish office supplies."
Visuals ā A sequence of panels (sketches, illustrations, photos, or screen mockups). Each step represented once. Images show: environment, device, facial expressions/body language, speech bubbles, UI screens as relevant.
Captions ā One or two bullet points per panel max. Describe: user action, emotional state, environment, device. Concise ā the image is primary.
Ask the user for (or extract from context):
If no data is available yet, storyboards can still be used as ideation artifacts ā just flag that they should be treated as conversation starters, not lasting prioritization tools.
| Audience | Fidelity | Format | |---|---|---| | Internal team brainstorm | Low ā sticky notes, stick figures | Text outline or simple SVG | | Usability test debrief | Medium ā photos/stills + captions | Structured panels with quotes | | Stakeholder presentation | High ā detailed illustrations | Polished visual artifact |
Ask the user who the audience is if unclear.
Before drawing or writing panels:
This surfaces which moments matter most emotionally before committing to layout.
For each step produce:
Default output is a structured storyboard written out as:
STORYBOARD: [Title]
Persona: [Name + role]
Scenario: [One sentence description]
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
Panel 1: [Step name]
[Visual description]
⢠[Caption bullet 1]
⢠[Caption bullet 2 if needed]
Emotion: š / š / š
Panel 2: ...
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
If the user wants a rendered visual, use the show_widget visualizer tool to create an
SVG storyboard layout with panels, icons, and captions.
| Use Case | Notes | |---|---| | Usability test debrief | Include direct user quotes; use photos/stills where possible | | Augmenting a journey map | Add storyboard panels for key stages to show physical/device context | | Feature prioritization | Use emotional state per step to identify which pain points to tackle first | | Ideation | Sketch hypothetical flows; label clearly as speculative, iterate fast |
| Storyboard | Journey Map | |---|---| | Imagery first, minimal text | Text-rich, extensive annotations | | Covers a fragment of the journey | Big-picture, end-to-end overview | | Narrow use ā specific team or problem | Broad use ā cross-department alignment | | Informal, fast to create | Often a formal organizational artifact |
Use storyboards within or alongside journey maps ā not instead of them.
Before delivering a storyboard, verify:
Apply the Governors framework to design or audit human-in-the-loop features that keep users informed, in control, and safe as AI acts autonomously. Use this skill whenever someone is designing or reviewing AI product features involving oversight, trust, transparency, or control ā including "how do I keep users in the loop", "how should I handle risky AI actions", "users don't trust the AI", "how do I prevent costly AI mistakes", "should I ask for confirmation before this action", "how do I show AI reasoning", "users are scared the AI will overwrite their data", "how do I handle AI memory and privacy", or any request about making an AI feature feel safe and controllable. Trigger even when the user doesn't say "governor" or "human-in-the-loop" ā if they're designing any AI feature and the question touches on control, trust, transparency, cost, risk, or oversight, use this skill.
Apply the AI Identifiers framework to design or audit the distinct, brand-level qualities that define how an AI presents itself across a product. Use this skill whenever someone is designing or reviewing the visual, verbal, or behavioral identity of an AI ā including questions like "what should we call our AI", "how should our AI look", "what color should we use for AI features", "how do we make our AI feel distinct", "what icons should represent AI actions", "how do we give our AI a personality", "should our AI have an avatar", or any request about making an AI feel coherent, recognizable, and on-brand. Also trigger when the user is building a new AI feature and hasn't yet thought about how it should present itself ā proactively raising identifiers as a design consideration is part of this skill's job.
Design and implement AI input patterns for products. Use this skill whenever the user wants to add an AI-powered input mechanism to their product, improve how users interact with AI features, decide which input pattern fits a use case, or audit existing AI input UX. Trigger on phrases like "how should users prompt this", "add AI input to", "let users control the AI with", "what input pattern should I use", "design an AI prompt experience", "how do I let users fill fields with AI", "add a regenerate button", "inline AI actions", or any request about how users should interact with or direct AI in the product. Always use this skill before designing or recommending any AI interaction surface.
My name is Tommy. Im a Product designer and developer from Copenhagen, Denmark.
Connected with me on LinkedIn āļø