Storyboarding
A storyboard is an ordered sequence of panels, and it is read. Each panel carries a sketch and a sentence, and the panels advance through time: the reader follows one scenario from its trigger to its outcome, across the actors, the channels and the waits that make it up. BABOK files it among the prototyping methods and writes that it details, visually and textually, the sequence of activities, summarising the user's interactions with the solution or with the enterprise. The Agile Extension gives it its full treatment and its economic reason: you storyboard when a formal prototype would be unnecessary or too expensive. What the technique puts on the table is an entire journey made inspectable before anything is built and an artefact stakeholders can argue with.
Goal
The storyboard puts a whole scenario in front of the room, panel by panel, and anyone can point at the one that does not hold. A journey that crosses several steps, several actors, several channels and often several days has, until somebody draws it, no support anyone can put on a table. The use case states it in prose, and the business reacts poorly to prose it cannot see. The mock-up of a screen shows one instant of the journey and leaves the intervals in the dark. The process model describes the organisation's activities, and what the customer lives through between them stays outside the frame.
What it makes inspectable is precisely the material the other techniques leave implicit: what happens between the steps. Who acts, on which channel, how long the silence lasts, what the customer is holding while waiting, what state each step leaves them in. The decisions that reading it enables are of that order: which scenarios the solution must serve, in which order the steps follow one another, who owns each hand-off and where the journey breaks. The Agile Extension adds two uses BABOK does not mention and that weigh heavily in practice: showing several variations of the proposed solution, by drawing the same scenario twice in order to choose between them, and aligning stakeholders on a vision before the first screen exists.
The deliverable is made of three objects, and the third is the one teams forget. A set of storyboards, one per selected scenario, each a short ordered sequence of panels that stands on its own. A selection record, which says which scenarios were drawn, which were not and why. And the list of rules, open questions and breaks that the reading surfaced: the requirements come out of that list.
Downstream, the storyboard feeds three pieces of work. The elicitation of the requirements the journey implies. The design of the interfaces the panels contain. And, the most neglected of the six uses the Agile Extension lists, acceptance testing: a scenario validated panel by panel is already a test scenario, written in the words of the business and accepted by it.
Usage
When to use it
- The journey crosses steps, channels and days: no single interface carries it, and the sequence is the subject.
- Use cases and user stories stay too abstract: the business does not react to what it cannot see.
- A formal prototype would be unnecessary or too expensive: the technique's economic trigger, frequent in practice.
- Two solution variants to compare: draw the same scenario twice, side by side, then choose.
- A room to align on a vision: a sketch gets commented on, a vision document gets signed without being read.
- An existing process to understand before proposing to change it: reading it brings the breaks out.
- Acceptance-test scenarios to establish: a journey validated panel by panel is one.
When not to use it
- The question is the usability of a screen: take paper prototyping, where a user performs the task.
- The decision turns on a quantity: delay, throughput, queue length. Take simulation, which measures.
- The journey is settled and the rules remain to be established: take business rules analysis.
Description
One method on two axes
BABOK classifies prototypes on two distinct elements. The approach says what the prototype becomes: you throw it away, or you grow it into the delivered solution. The method says what it is made of and what somebody does with it. Storyboarding is a method, alongside paper prototyping and simulation, and the three are told apart by a single criterion. A storyboard is read: you follow a sequence of panels and you move forward in time. A paper prototype is operated by a user, who performs a task while a colleague plays the computer. A simulation is executed by a machine, which returns measurements.
Every prototype carries an answer on each of the two axes, and the two answers are free of each other. A storyboard is a throw-away prototype, always, because paper does not go into production: the method closes the evolutionary prototyping cell by itself. The converse is free: a throw-away prototype also takes the form of a piece of code, a screen mock-up or a drawing on a whiteboard, and the storyboard is one of those forms among others. It is prototyping taken as a whole that governs the routing between the two axes.
The technique travels under four other names, and they are worth knowing because the reader will meet them: dialogue map, dialogue hierarchy, customer journey, navigation flow. The Agile Extension records them, and it sets the boundary with story mapping, which organises the user's activities into a structure, where the storyboard presents the detail of one scenario in a visual flow. The two artefacts look alike on a wall and answer two different questions: one says what the user does in general, the other says what happens this time, in this order, with these delays.
What a panel carries
The Agile Extension names three elements. The scenario, which is the unit: one scenario, one storyboard. The illustration, a series of boxes or segments, one per step of the scenario. And the textual explanation, which accompanies each box and which must be enough for the storyboard to be read without its author.
In practice a useful panel carries five pieces of information and no more: the step, the actor who performs it, the channel it happens on, the state it leaves the customer in and the time elapsed until the next one when that time matters. The panel number makes the sequence, and a one-line caption does the rest. What is not on that list is decoration, and decoration costs twice: it has to be drawn, and then it pulls the eye away.
The journey as it is actually lived
Both guides describe the storyboard on the side of the proposed solution, and a reader comes away with the idea that the technique belongs to the future. It works just as well on the present. The panels carry the same five pieces of information, the three-to-five discipline still holds and what they record is the journey as it runs today: you reconstruct it with the people who live it, you draw it, you read it back to them out loud. The deliverable then changes in nature. It is the list of breaks that the reading surfaces: the waits nobody had put a number on, the states the customer is left stranded in, the hand-offs whose owner is named nowhere, the rules the back office applies from memory. Set beside the real journey, the storyboard becomes an audit instrument, and it is out of that reading that the decision to change something most often comes.
Running a storyboard
- Identify the scenarios in play
They come from the use cases and scenarios already written, from user stories, from an interview with a business expert, from a visit to the customer, from a workshop. Personas do direct service here: a scenario belongs to somebody, and the journey of a new arrival is not the journey of a customer of thirty years' standing. At this stage you enumerate broadly, without sorting. - Choose the ones you draw
Not every scenario calls for a storyboard: you draw the most frequent and the most complex. The two criteria are the likelihood of the scenario and the complexity it holds, and the Agile Extension states them in those terms. The rest is not drawn, and that choice is recorded. This is also where the unit of work is fixed, once and for all: one storyboard is worth one scenario, and inside a scenario the panels form a sequence. The six-cell grid the Agile Extension publishes as its illustration shows the set of storyboards, one cell per scenario. Once the unit is fixed, the two guides say the same thing. - Draw
A series of boxes, one per step. This is where the empirical evidence takes over from the guides. Three to five panels. Truong, Hayes and Abowd varied the panel count from one to seven: below three, comprehension collapses; above five, comprehension, perceived quality and reader engagement all three fall. The storyboards practitioners actually produce run from one to more than twenty panels, but the experts' ones cluster between two and six, and the rule those experts state themselves is that a feature needing more than five panels must be cut into several storyboards. The test for the cut is simple: one short sentence must be enough to describe each panel. If it is not enough, the panel contains two steps. - Draw little
The level of detail is minimal, and that is decided. Experts remove detail deliberately, they prefer the stick figure to the drawing and the filter to the photograph, because removing detail is how you direct the eye. Superfluous detail costs the drawer time and pulls the reader away from the points that matter. Two decisions are taken explicitly at this moment. People: putting them in focuses the reader on the lived experience and generates empathy, leaving them out focuses the reader on screen layout and technical detail. You put them in when you want a reaction to the experience, you take them out when you want a view on usability or on aesthetics. Time: you draw it explicitly only when it is part of the story. A pointless clock distracts; a necessary clock decides, and Truong and his co-authors measure that 35.9% of readers change their interpretation of the scene depending on whether a delay is drawn or not. - Add the text
Each panel gets what it needs to be read without its author: the step's caption, the optional interactions, the unavailable ones, the stakeholder requests that fall outside the main scenario, the notes on a particular step. The difference the text makes is considerable: with text, 84.4% of readers correctly identify the story being told, against 65.7% without text, and adding text to a storyboard that had none improves 39.7% of the answers. Short forms beat long ones, a speech bubble or a line being worth more than a paragraph. The counterweight has to be known: text steers the reader, and when the object of the session is to get an unprimed reaction to the interface itself, the panels stay silent by decision. - Validate with the stakeholders
The storyboard is read out loud in front of people who resemble the intended audience, exactly like any prototype meant for evaluation, and then the author goes back to the group and starts again. Iteration is part of the process: ISO 9241-210 treats producing design solutions and evaluating them with users as a cycle, and that cycle is human-centred design. A single reading, politely applauded, is not validation. The technique survives a distributed team very well, better than most: a small set of ordered panels reproduces itself without loss on a shared canvas, and everyone can point at the same panel.
What makes a storyboard fail
The drift towards the "how"
Both guides flag it independently and at two heights: BABOK observes that prototyping bogs down in the "how" at the expense of the "what", the Agile Extension at the expense of the "why". The panels are a support for a discussion, and the discussion is about the journey.
The visual flow hides the rules
This is the technique's most expensive limitation, and the Agile Extension names it: attention concentrates on the sequence of images and significant rules and constraints go unnoticed. A storyboard can look complete while being empty of any rule. The counter is procedural: read the storyboard a second time, asking one question of each panel, which rule decides this step, and route what comes back to business rules analysis.
Too much detail
The beginner's reflex is that the finished drawing communicates better. The evidence says the opposite, and BABOK adds the consequence: an elaborate, detailed prototype generates unrealistic expectations about the final solution, and stakeholders fix on design specifications instead of requirements. A rough sketch gets criticised; a polished drawing gets signed.
Too many panels
Beyond five, comprehension and engagement fall together. A scenario that needs ten panels is two scenarios, and the remedy is to cut it.
Storyboarding every scenario
You produce a wall nobody reads and you burn the technique's one decisive advantage, its cost.
Text added at the last minute
A silent storyboard is understood by two readers in three, a captioned one by more than four in five. The text is part of the artefact, on the same footing as the line.
"Nobody here can draw."
This is the commonest refusal and it rests on a factual error: stick figures and rectangles are exactly what the evidence recommends. Graphic talent appears in none of the technique's conditions for success.
AI considerations
The expensive part of storyboarding is the cut: deciding where the scenario breaks, how many steps it has, what each panel must carry. Beginners and experts alike point at the story as the real difficulty. That is precisely where a model does its best service: you give it a use case, a set of user stories, an interview transcript or a process description, and you get a proposed cut into three to five steps, each with its sentence. It is a starting cut, one you can argue with.
Three other uses hold up. Producing variants: the same scenario drawn twice, once with the identity check at the counter and once by video call, costs little to have produced in parallel, and the choice between the two becomes a human decision taken in front of two artefacts. Tightening the captions: short forms win, and a model compresses a step into one line well, in the country's three languages if the journey has to be read in French, German and English. And the enumeration of scenarios, as a list to prune before the two or three that will be drawn are chosen.
Selecting the scenarios is a business decision: frequency and complexity are properties of this organisation and this customer base, a model has access to neither and told to choose it will choose the typical scenario, whereas the value of the technique lies in the awkward one. The finish is the danger. A generated image is polished by construction, and a polished artefact stops being criticised and becomes a specification: if you draw by machine, you push the fidelity back down deliberately, or you have manufactured the very trap the technique exists to avoid. Validation happens with people. A model's approval of a storyboard is worth nothing, because what is validated is the journey, and the journey belongs to those who live it. Finally, a model invents the plausible hand-off: it does not know that this bank sends the card by post and that the permit check costs it six calendar days. Every fact of the journey is checked with the organisation, failing which the storyboard confidently teaches a process that does not exist. Interview transcripts and customer journeys also carry personal data, and they do not go into a public model.
Examples
A retail bank wants to overhaul account opening, and it starts by drawing the journey as it runs today. Five scenarios are on the table, two are selected on the two criteria and it is the selection record that says so.
| Account-opening scenario | Frequency | Complexity | Storyboarded |
|---|---|---|---|
| Long-standing resident, neighbourhood branch | Very high | Low | Yes, the most frequent |
| New arrival in Switzerland, B permit | High | High | Yes, the most complex of the frequent ones |
| Cross-border commuter, salary paid in Switzerland | Medium | Medium | No |
| Youth account with a legal representative | Low | Medium | No |
| Politically exposed person | Very low | Very high | No, its difficulty is in the rules |
The B-permit scenario crosses four steps, three customer channels and eleven days, which is exactly the shape the technique exists to make visible. Four panels fit inside the three-to-five band, and the delay is drawn between each of them because here the time is part of the story: it is the six-day silence that triggered the discussion.
Reading it out loud produced what the technique really produces, which is a list. Between the third and the fourth panel, the customer waits six days with no news, without knowing that the account already exists and that it is blocked. His first salary, CHF 6'200 paid on day 8, falls inside that silence, before the permit check has come back, and the rule that decides the fate of that payment was written nowhere: the product manager believed it was known, the back office applied it from memory and the two versions differed. A second reading, run by asking each panel only for the rule that decides the step, surfaced eleven rules of which four were documented nowhere. They went to business rules analysis, and the questions that stayed open went to item tracking.
Visualisations
The technique produces two objects, and each takes the form that follows from its nature. The storyboard itself is a sequence of panels positioned in space and oriented by time: the delays between the panels carry part of the meaning, the space that separates them is proportioned to their duration and a bulleted list would destroy both. It is drawn. The selection record is made of rows and columns, with a frequency column and a complexity column that compare at a glance, and what is made of rows and columns is rendered in cells.
Cost
| Phase | Level | Justification |
|---|---|---|
| Preparation | Medium | The scenarios have to exist before one of them is drawn, and choosing the two or three that will be storyboarded is a real conversation with the business, about frequency and about complexity. That is where the technique's cost lives. Beyond that: paper and a wall. Nothing to install, no data to gather, no licence. |
| Execution | Low | A workshop of two to three hours produces the storyboards of the selected scenarios. That is the technique's principal strength, produced quickly and at very low cost compared with a prototype. It is also its trigger: you storyboard when a formal prototype would be unnecessary or too expensive. |
| Documentation | Low | The panels are the deliverable, and they are already legible. What remains to be written is short: the selection record and the list of rules and questions the reading surfaced. The cost only rises if the storyboards are maintained as living artefacts: they are throw-away by construction. |
Tooling
The minimum tooling is paper, with a pencil, cards and a wall. It is the tool the evidence recommends: cards reorder, and reordering the panels is the technique's central operation. The coarseness of the line is a sought-after property, because a rough sketch gets criticised without embarrassment. The whiteboard holds the same place in a co-located workshop where the story is still being argued over.
The presentation software deserves more consideration than it gets: one slide per panel, the notes underneath, the form is native, the slides reorder with a drag and the tool is installed on every machine in the company, which weighs more than any feature. The online collaborative canvas (Miro, Mural, FigJam and their like) is what makes the technique survive a distributed team: a small set of ordered panels reproduces itself there without loss, and everyone can point at the same panel at the same moment.
The design tools (Figma and its peers) come in once the storyboard is stable, when its screens feed interface design. The risk there is named once and for all: as soon as the tool makes the panels finished, the artefact stops being criticised. The image generators pose the same problem, faster.
No tool is required. A storyboard drawn on four A4 sheets and taped to a wall is a complete instance of the technique.
Sources
- IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.36 Prototyping: storyboarding as a prototyping method, the sequence of activities it details visually and textually and the limitations of bogging down in the "how", of unrealistic expectations and of fixing on design rather than on requirements.
- IIBA, Agile Extension to the BABOK Guide, §7.17 Storyboarding: the technique's full treatment, its aliases, its six uses, its economic trigger, its three elements, its five creation steps, the boundary with story mapping and the limitation of the rules the visual flow hides.
- Khai N. Truong, Gillian R. Hayes, Gregory D. Abowd, Storyboarding: An Empirical Determination of Best Practices and Effective Guidelines, Proceedings of DIS '06, ACM, pp. 12-21: the empirical study of what makes a storyboard legible, the number of panels, the level of detail, the effect of text, the presence or absence of people and the representation of time.
- ISO 9241-210:2019, Ergonomics of human-system interaction, Part 210: Human-centred design for interactive systems: producing design solutions and evaluating them with users as an iterative cycle, which makes validation a step of the process.

