Storyboarding
In short A storyboard shows users a rough story of how the future system will behave, so they can react before anything is built. Leffingwell and Widrig present it as the main cure for the “yes, but…” reaction: it is cheap, friendly to users, and quick to create and change.
Based on: D. Leffingwell, D. Widrig, Managing Software Requirements: A Unified Approach, ch. 12.
On this page
What it is#
A storyboard is a sequence of sketches, screens or scenes that walks users through what the system will do in a typical situation. Leffingwell and Widrig describe three types, by how much the user takes part:
- Passive. You tell the user a story with sketches, pictures, screenshots, slides or sample outputs. The analyst plays the system: “when you do this, this happens”.
- Active. An automated presentation, such as an animation, a self-running slide show or a short video, that shows the system’s behavior in a typical scenario.
- Interactive. The user works with it directly: a simulation, a mock-up or throwaway code. The line between an interactive storyboard and an early prototype is blurry.
Choose the type by the complexity of the system and the risk that people misunderstand its purpose. For something genuinely new, you may move from passive to interactive as understanding grows.
Every storyboard covers the same three elements as a use case: who (actors: users, other systems, devices), what (the behavior in the interaction), and how (the details of moving from one state to the next).
When to use it#
- Early and often on any project with new or innovative content.
- When users struggle to describe what they want but can react to something concrete.
- When stakeholders argue over a design and need a shared object to point at.
When to use something else. If the screens are fixed by a packaged product, a configuration walkthrough of the real product is more useful. If you need to test real performance or technical feasibility, build a prototype. If the behavior is already well understood and agreed, a storyboard adds little.
How to do it#
- Pick one scenario that matters and where misunderstanding is likely.
- List the who, what and how: actors, the steps of the interaction, and the transitions between states.
- Choose the type: passive for a first conversation, interactive when you need users to try things.
- Make it rough. Paper, sticky notes, whiteboard sketches or a simple slide deck. Leffingwell and Widrig’s guidelines: - Do not invest much. If it looks finished, customers hesitate to ask for changes, and may even want to keep it as the product. - Make it easy to change, within hours. - Do not make it too good. Use materials or tools that cannot accidentally turn into production code. - Make it interactive where you can; more interaction brings more reactions and more requirements.
- Walk users through it and invite “yes, but…” comments on purpose.
- Change it on the spot where you can, and replay.
- Record reactions as requirements, questions and decisions.
Template#
Storyboard: <scenario name> Type: passive / active / interactive Version: <n>
| Frame | Who (actor) | What happens | How (transition to next frame) | Reactions / questions |
|-------|-------------|--------------|--------------------------------|-----------------------|
| 1 | | | | |
| 2 | | | | |
Example#
Leffingwell and Widrig tell of a project stalled over the front-panel design of a device. Five professionally drawn color designs only fed the argument. The next day a team member brought felt, scissors and markers, and invited the customer to cut out and rearrange the panel elements during the meeting. Within an hour the customer had settled on a design. The rough version worked where the polished ones failed for two reasons: it was interactive (what can a customer do with five pictures when none is quite right?) and it was easy to change. The customer was the domain expert; given a tool to edit with, they solved their own problem.
The same idea at The Workshop, a fictional bike-repair chain: the analyst draws six paper frames for “book a repair”: choose workshop, describe the problem, pick a slot, confirm, receive confirmation, receive the “ready” message. In a passive walkthrough with two customers and a front-desk lead, the first “yes, but…” comes at frame 2: customers do not know how to describe the problem, and the front-desk lead says the description decides the slot length. The analyst switches to an interactive version with sticky notes for problem categories (“puncture”, “brakes”, “gears”, “not sure”) that customers move around. “Not sure” becomes a requirement: book a short inspection slot instead.
Common mistakes#
- Polishing the storyboard → keep it rough so people feel free to change it.
- Building it in production tools → use materials that cannot become the product.
- Showing it once, late → show it early, change it, show it again.
- Only passive walkthroughs for a novel system → move to interactive as soon as you can.
- Not capturing reactions → note every “yes, but…” and turn it into a requirement or a question.
- Defending the storyboard → it exists to be criticized; thank people for each objection.
Checklist#
- One scenario chosen where misunderstanding is likely.
- Who, what and how listed for each frame.
- Type chosen on purpose (passive, active, interactive).
- Rough enough that changes take hours, not days.
- Users invited to object and, ideally, to rearrange.
- Reactions recorded and traced to requirements.
- Next session planned with the revised version.
Sources and further reading#
- D. Leffingwell, D. Widrig. Managing Software Requirements: A Unified Approach. Addison-Wesley, 2000, ch. 12.