Storyboard
Describe a user’s actions, thoughts, and feedback across key moments to reveal gaps in a proposed experience.
Use a storyboard to make a product or service concept easier to discuss. Start with the user and goal, then describe the key moments in time order using text frames.
A user, a situation, a goal, and the important moments in the experience.
A sequence of text frames and questions for an experience test.
How to use it
- Identify the user, situation, and task.
- Choose the key moments in time order.
- For each frame, describe the scene, action, thought or dialogue, and feedback.
- Check transitions, errors, and confirmation states, then ask others to explain the sequence.
Keep its limits in mind
A coherent story does not establish usability or technical feasibility. Include failures and recovery where they matter; simple text or sketches are enough to explore the sequence.
Explaining a client review without registration
Fictional example: Yunqiao needs to explain a proposed mobile review experience to developers and clients in four frames. A registration step between viewing changes and leaving feedback would interrupt the flow.
On a small screen, scroll across the diagram to read it.
Proposed requirements: The four frames identify access without registration and feedback confirmation as requirements to assess. They are not claims that the feature has been built.
Two different checks: Three unfamiliar people would check whether the explanation is understandable; five trial users would check the experience. Neither test has a reported result.
Next step: Check the explanation and prototype separately, including error recovery and resubmission.
Three reasons a smooth story needs another pass
First, pause if the protagonist, goal, or starting situation changes between frames. A client reviewing a design and a project manager assigning work have different knowledge and authority. A story that silently swaps them can appear effortless because somebody else has solved the hard step. Keep one viewpoint, and show a handoff explicitly when it matters.
Second, stop when a frame jumps directly from intention to success. Clicking Submit, the system receiving a request, and a person seeing confirmation are different events. An error, expired link, wrong version, or interrupted connection may break the sequence. You do not need an exhaustive specification, but you should identify the failure that would invalidate the proposed experience.
Third, do not label imagined dialogue as a research quote. Thoughts in a proposed scene are writing devices until observed or reported by a real participant. Attractive illustrations also cannot establish comprehension, access control, or technical feasibility. This page’s tool produces editable text frames; drawing or acting out a scenario is a separate way to discuss the same sequence.
Choose a sequence, observation map, process, or concept
A storyboard makes an experience discussable at the level of key moments. It can expose missing transitions before implementation. Select a related method when you need a different kind of evidence or a different view of the work.
| Input and question | Method | Output and boundary |
|---|---|---|
| A concept needs a chronological user experience | Storyboard | Proposed moments, actions, and feedback; not an observed journey. |
| Customer observations need to be organized across touchpoints | Customer journey map | Evidence and gaps by stage; imagined behavior stays labeled. |
| Roles, conditions, and exception paths need specification | Business process flowchart | A process with branches; no proof the implementation works. |
| An idea lacks a clear audience, mechanism, or test | Idea concept sheet | A bounded concept; no validated demand. |
Read all four review frames as proposed requirements
The complete fictional Yunqiao packet is a client opening a design-review link on a phone. Four frames cover receiving the link, viewing changes, leaving feedback, and confirming completion. The concept proposes no registration and feedback tied to a version. Three people unfamiliar with the concept would retell the explanation; five trial users would examine the experience. Error and resubmission messages need checking. Neither group has reported results, and implementation is not established.
Begin with the first frame’s information: project, sender, and deadline. The next frame proposes a change summary. At the transition to image feedback, the team notices that requiring registration would interrupt the intended flow. That is a design conflict to resolve, not evidence that all real users abandon registration. The final frame needs a clear distinction between a local action and confirmed submission.
The table retains the four supplied moments and turns each into a check. The imagined questions are part of the fictional scenario, not customer quotations. Before adding more screens, ask whether the transition gives the protagonist enough information to act. A visible success message should correspond to the actual state it describes; the story cannot stand in for testing that correspondence.
| Moment | Proposed action and question | Expected feedback and check |
|---|---|---|
| Receive link | Open the message: when is feedback due? | Project, sender, deadline visible; confirm intended recipient and link state. |
| View changes | Read the summary: what changed? | Key changes identified; confirm the intended version and missing context. |
| Leave feedback | Annotate the image: adjust this area | Comment tied to a version; check phone targeting and preservation after an error. |
| Confirm completion | Submit: was it sent? | Confirmation and next step; distinguish pending, failed, and received states. |
Run two different checks and retain recovery problems
The conclusion is a clearer proposed experience with access and confirmation requirements still to assess. For the explanation check, ask the three unfamiliar people to retell the sequence without coaching. Note which actor, transition, or state they misunderstand. Agree what counts as an adequate explanation before interpreting responses. Being able to retell the story does not prove that someone can complete the task on a phone.
For the separate five-user trial, agree representative tasks, participation, device conditions, and prototype limitations. Observe entry, the feedback location, version understanding, submission status, and recovery after an error. Do not combine three explanation participants and five trial users into an eight-person usability success rate. The packet does not establish whether the groups overlap, and their questions differ.
Retain interrupted attempts, requests for help, and repeated submission. A person who cannot tell whether feedback was received may send it twice; the team needs a specified recovery behavior rather than a second success frame. Do not promise reliable resubmission or preserved annotations until the relevant behavior has been implemented and checked.
At review, distinguish a revised explanation from a changed requirement, a functioning prototype, and a completed technical test. Record which transitions improved, which remain unresolved, and whether another iteration is justified. A coherent four-frame story is a useful design output even when it reveals that the concept needs revision. No user comprehension, completion rate, or working access-control result is supplied in this case.
Check your work
- The sequence and the user’s goal are clear.
- Each frame describes one important moment.
- Transitions and feedback reveal possible obstacles.
- A planned test is separate from a completed validation.
Framework references
References explain the framework and its scope; they do not validate the fictional example's results.
Put the framework to work
Copy the outline and add your question, evidence, and open questions.