What Are Storyboards Good For?
Designing with Storyboards
Overview
Storyboards have certainly stood the test of time. They were early on developed in the film industry as a way to plan out and test the experience of a film before investing in shooting, and everything else that goes into shooting scenes. The storyboarding concept is also present in comic books that use, more or less, a pictorial approach, adding text to the images to tell the story in a finished form (film storyboards of course rely more on the scripts to tell the story, with the storyboard focusing on the visuals). In these two examples, you see the primary purpose of this tool: to explore, try, and plan out human-centric experiences before investing in the expensive process of creating them, and to effectively communicate such experiences to others.
Why Use Storyboards In Software Development?
In software, storyboarding is useful to understand the human contexts in which software will be used and to explore potential experiences before investing in developing software—before even investing in a prototype. It is axiomatic in the software industry that the earlier on in the process you can discover the best design, the cheaper and more efficiently you can make that software.
Storyboards help do this much better than, say, business requirements documents, functional requirements documents, or even use case scenarios and user stories. If you've been frustrated by having to create these kinds of documents, overwhelmed by having to use them to make software, and generally dissatisfied with the software that is made using such documents, storyboards are a good alternative, or at least a good complement to use up front in the discovery process.
The reason stories and storytelling are so effective in software is simply because stories reflect the way we live our lives. Stories are a millennia-old way of relating human experience, and even before there were words, people were using pictures to communicate their experiences. So it is only natural and makes sense to use them to relate human experiences that involve software. More than that, they help keep what is a very technologically-heavy endeavor focused on the human experiences that it is meant to support.
Whether you draw storyboards on a wall, sketch them in a book, or use some other tool to help in making them, they will only help you to better understand the software that you need to build—and sometimes to understand that you don't need to build it (or at least not the way you thought you needed to). You can quickly bang out a story, share it with stakeholders and users; they can immediately relate to it and sense if it resonates for them and more easily suggest areas where changes could make experiences flow better. Storyboards are cheap to change—much cheaper than changing code, especially for big/chunky issues that are easy to miss with functional-oriented or business-oriented textual descriptions.
You can use storyboards to tell high-level stories, and you can use them to show step-by-step interactions with an imagined piece of software. They're super versatile.
To support storyboarding activities, Indigo comes with many different scenes that help you to situate the software you are making into realistic contexts—people and places with devices. It helps remind you and others involved in software creation that the software does not exist in a vacuum. It helps the team and clients see the software from the outside in rather than the inside out, which is an essential perspective to maintain if the goal is to create software that is useful, usable, and desirable.
It supports telling high level contextual stories with mostly scenes, but it also supports telling more detailed, step-by-step interaction stories, and everything in between. You can use it to show just one flow, or you can use it to show decision branches and parallel/alternate flows—your choice. And with integrated screen design, you can easily step right into designing the UI for particular steps in your flows.