# Storyboard
# Phase: 🎨 Problem shaping
Focus: Converge
IN BRIEF
Time commitment: 2-4 hours
Difficulty: Easy
Materials needed: Meeting space (physical or virtual), whiteboard and stickies (physical or virtual), participants from a variety of technical and cultural perspectives (the more of these, the more useful)
Who should participate: User experience designers, visual designers, product/project owners, community specialists, developers
Best for: Creating a sequential narrative of how your user interacts with your product
# About this tool
A storyboard is a simple, effective way to consolidate divergent problem shaping into a narrative that can help inform next-step decisions; in this way, it's almost a proto-prototype. Storyboards work well among team members who already have a good working knowledge of the problem space, but they're also a good fit for co-creation sessions with your users, too. Storyboarding can be useful anywhere in the process of creating or refining a product; in early stages, it can help you articulate features without a lot of effort, and later down the line, it can act as a "reality check" that helps you align against personas, definitions of success, and other foundational artifacts.
One note: It's OK if you can't draw! The purpose of a storyboard is to get ideas down on paper quickly in a sequential fashion, and remembering that while you do so, you'll probably reveal other insights along the way, including details on "who, where and how" that you may not have been ready to incorporate when developing personas or other foundational documents.
- Split your participants into partners and level-set with the entire group about the task or interaction that you want to storyboard. Keep in mind that it may be more effective to storyboard just one part of a larger task at a time, and later combine the results of your efforts into a larger task/interaction.
- Give partners a storyboard template (opens new window) and ask them to spend 30 minutes or so sketching out the task/interaction. Emphasize that stick figures are just fine — and that they're drawing out the activity that the user is engaging in, not the interface that the user is using to do it. Ask as well that they label each frame in the storyboard with the actions that are taking place in the drawing; here's an example (opens new window).
- Post each team's storyboard in a central location and ask teams to explain (or even act out!) what happens in each frame and why.
- When all storyboards have been shared, ask each individual to indicate (via dot-voting or a similar method) which frames feel the most effective to them.
- As a group, examine the frames that gathered the most votes and work together to assemble them into a meta-storyboard that captures a synthesis of the best of all options. This can be done by cut-and-paste method or by drawing an entirely new storyboard.
Additionally, this "final" storyboard can be exceptionally useful when it's overlaid against another type of process diagram, such as a journey map. Here's a great example (opens new window) from the Nielsen Norman Group (opens new window).
# Links and resources
- Mozilla step-by-step guide to storyboarding (opens new window)
- IDEO references on storyboarding, including video example of recap (opens new window)
- Extensive guide to storyboarding and how it fits into the overall design process (opens new window)
- Nielsen Norman Group on why storyboards are helpful (opens new window)
- Example image of storyboard overlaid on another axis, in this case user satisfaction (opens new window)