Storyboarding

Show a concept in context and decide what to prototype next.

Prototyping

Design

Prototype · Run a workshop

Individual · Collaborative · Workshop

Illustrative parcel collection storyboard

AT A GLANCE

USE IT WHEN

You need to explain how a concept fits into a real situation.

YOU’LL NEED

One scenario, a concept, evidence notes and six simple frames.

YOU’LL GET

A visible scenario, explicit assumptions and a clear next investigation. Keep the unresolved transition attached to the prototype brief so it is not lost when the story becomes a design.

01 / UNDERSTAND

What is storyboarding in UX?

Storyboarding represents an experience through a sequence of illustrated moments. It shows a person acting in a particular context, encountering a product or service and reaching an outcome. In UX and service design, it helps a team examine a concept before deciding what to build.

A storyboard can describe an existing situation or propose a future one. Label which kind you are making. A proposed story is a hypothesis about how an experience could unfold, not evidence that people will behave that way.

Why use Storyboarding?

A feature description can hide the work surrounding an interaction. A storyboard makes that work visible: noticing a message, understanding its meaning, finding help and continuing after an interruption. It gives a team concrete moments to question.

Use Customer Journey Map when you need to organise research across an experience. Use a storyboard when you need to examine one particular sequence in context.

When to use it

USE IT WHEN

  • You need to explain how a concept fits into a real situation.

  • A proposal crosses screens, physical places or human handoffs.

  • The team agrees on a feature but imagines different ways people will use it.

When to choose another method

  • Use User Interviews first if the situation and underlying need are mostly guesses.

  • Use Paper Prototyping to examine interface choices and task execution.

  • Use Service Blueprint when the unresolved issue concerns operational responsibilities behind the experience.

What you’ll need

Start with a person, a specific goal and a bounded situation. Bring relevant research notes, known service constraints and the decision the storyboard should support. Paper and a pen are enough. Drawing skill matters less than making actions and context understandable.

Mark invented details as assumptions. When using research, record source references without exposing personal information.

What a storyboard needs

Keep the elements that help answer your question and support a decision.

Person and goal

Person and goal

Who is trying to achieve what? Include only context relevant to the situation.

Trigger

Trigger

What starts the experience, and why does the person act now?

Visible action

Visible action

Show what the person does, rather than naming a feature.

Service response

Service response

Show what changes or what another person does in response.

Transition

Transition

Make time, place and channel changes understandable.

Outcome and uncertainty

Outcome and uncertainty

Show the resulting situation and identify what still needs checking.

02 / PUT IT INTO PRACTICE

How to create a UX storyboard

Keep evidence and assumptions distinct. Revisit your work when new information changes your understanding.

01

Choose the decision

Write the question the sequence must help answer. Keep the boundary narrow enough to examine.

For a parcel collection concept: can someone recover when their collection code is unavailable?

02

Set the scene

Specify the person, location, goal and relevant constraints. Separate research from invented context.

Mina reaches a collection counter after work. Her phone has no battery. This scenario is illustrative.

03

Write the key moments

List the trigger, obstacle, response and outcome before drawing. Remove scenes that add no useful information.

Arrival, request for a code, explanation, alternative check, staff response and collection.

04

Draw actions in context

Use simple figures, objects and short captions. Include what the person can actually see or know.

Show the counter notice offering help. Do not assume Mina knows an unpublished recovery process.

05

Challenge the transitions

Ask a colleague to explain the sequence without narration. Identify jumps that require invisible knowledge or effort.

Can staff perform the alternative check, and what prevents someone collecting another person's parcel?

06

Choose the next investigation

Record the most consequential uncertainty and select a method that can examine it.

Review the proposed identity check with operations before prototyping the counter interaction.

Example: collecting a parcel without a working phone

This is a fictional design scenario, not a report of user research. Mina arrives at a collection counter with a phone that has run out of battery. A six frame storyboard explores a proposed recovery route.

She reaches the counter; staff request a collection code; she explains the problem; a visible help notice prompts an alternative check; staff examine the required evidence; she collects the parcel if the check succeeds. The alternative check is a design assumption, not a recommended security policy.

The storyboard reveals a dependency hidden by the phrase ‘offer another way’: the service must define acceptable evidence and staff authority. The team decides to investigate that dependency before polishing the interface. A second version should show what happens when the check fails, including a safe next step.

Fictional six frame storyboard of parcel collection with a phone that has no battery.

03 / BELOW THE SURFACE

Below the surface: a coherent story can hide a weak concept

A smooth sequence can make a proposal feel inevitable. The author controls the person, the circumstances and the outcome, so the story may quietly remove the conditions that would make the concept fail.

KNOWLEDGE

What makes the next action possible?

Name the cue, previous experience or assistance required.

AUTHORITY

Who is allowed to make the decision?

Make permissions and service constraints visible.

COUNTEREXAMPLE

What if this transition fails?

Draw a plausible alternative and identify the next investigation.

Review the gaps between frames as carefully as the frames themselves. For each transition, ask what new knowledge, permission or effort makes the next action possible. If none is shown, the story may be relying on an invisible helper.

In the parcel example, moving from ‘phone unavailable’ to ‘identity confirmed’ conceals the most important design question. Draw a second version in which the proposed check fails. Compare the support, privacy and operational consequences rather than choosing the more reassuring ending.

An understandable story is not a validated solution. Feedback on a storyboard can reveal interpretation and concerns; it does not establish whether someone can complete the real task. This review approach is editorial guidance for this article, not a validated assessment framework.

Storyboarding working canvas

Use the first page to draw or describe six moments in reading order. Add the scenario and question at the top. Use the second page to examine evidence, transitions and an alternative ending. The PDF supports typed notes; print it or use a PDF annotation tool for sketches.

Storyboarding canvas with scenario field and six sequential frames.
Storyboard review canvas for evidence, assumptions, transitions and alternative endings.

Practical tips

  • Keep captions short enough to leave the action visible.

  • Show help, waiting and interruptions when they matter to the decision.

  • Ask reviewers what they infer before explaining the intended story.

Common mistakes

  • Drawing only screens and leaving out the surrounding situation.

  • Presenting imagined emotions as research findings.

  • Polishing the artwork before challenging the concept.

  • Treating a positive reaction as evidence of successful use.

What you’ll get

A visible scenario, explicit assumptions and a clear next investigation. Keep the unresolved transition attached to the prototype brief so it is not lost when the story becomes a design.

Sources and references

Behind every outcome, a deeper body of knowledge.

DESIGN ICEBERG

© 2026 Design Iceberg

Independent by design. Connected by knowledge.

Back to the surface ↑

Behind every outcome, a deeper body of knowledge.

DESIGN ICEBERG

© 2026 Design Iceberg

Independent by design. Connected by knowledge.

Back to the surface ↑

Behind every outcome, a deeper body of knowledge.

LIBRARY

+

EXPLORE

+

DESIGN ICEBERG

+

© 2026 Design Iceberg

Independent by design. Connected by knowledge.

Back to the surface ↑