Storyboarding in the Software Design Process

Storyboarding in the Software Design Process

Using storyboards in software design can be difficult because of some common challenges and drawbacks to the tools we have. The good news is that there’s a new, free tool that tries to address many of these issues. But before I get into that, let’s revisit the value of using storyboards (and stories in general) in software design.

Using stories in some form or another is a well-established practice in software design, so much so that there are many meanings of the term "stories." For instance, in agile processes, there is a concept of “user stories,” which are very basic units of expressing functional requirements: “As a user, I want to receive notifications when new applications are submitted.”

In user experience design, these stories take on more life through the incorporation of richer user and usage contexts and personas: real people in real places doing real things, not just some abstract, feature-oriented description of functionality that clothes itself in a generic “user.”

They can spark new design concepts and encourage collaboration and innovation.

They are a way to share ideas and create a sense of shared history and purpose.

They help us understand the world by giving us insight into people who are not just like us.

They can even persuade others of the value of our contribution.

Whatever they’re called, stories are an effective and inexpensive way to capture, relate, and explore experiences in the design process.

What Storyboards Add to the Picture

Storyboards have long been used as a tool in the visual storytelling media—films and television especially, though graphic novels and comics are perhaps an even closer analog (there are even presentations and articles I’ve seen on how comics can inform interaction design).

Although their uses and needs are somewhat different in these contexts, given that they are literally telling stories as the end product and not a means to an end, we can still leverage storyboarding to enhance the stories that we are telling by incorporating visual illustration. There are three primary benefits of doing this.

First, using storyboards allows the designer to quickly and easily add real-world contexts that involve place, people, and other potentially informative ambient artifacts. You can often learn unexpected things from storyboards, and embedding that context into your design efforts helps keep them grounded in the reality of the users’ lives.

Second, since software almost inevitably involves a user interface (and because we already know that drawing pictures of the UI is far more effective than verbally describing it) storyboards allow us to situate these UIs in the real-world contexts in which they’ll be encountered (or at least some of them).

Third, storyboarding helps enforce a discipline of thinking in terms of experiential flow. I recommend Mihaly Csikszentmihalyi’s Flow: The Psychology of Optimal Experience for a good primer on why this is important. It's all too easy when designing a UI to lose sight of the context and flow in which it will be used in, much to the detriment of the end experience. Using storyboards is one way to help keep your mind on the flow and not get lost thinking of the UI you’re designing as an isolated artifact.

Some Examples of Software-Oriented Storyboarding

If you search the Internet for “storyboarding software,” you’ll be confronted with a nice batch of software designed for storytelling in the media formats previously mentioned. There is precious little out there in the way of software that helps you leverage storyboards in software design.

Of course, you don’t have to use software to leverage storyboards in your design process. One of my favorite incarnations of physical storyboarding is in Adaptive Path’s “sketchboarding” approach. Another nifty set of tools is the specialized sketchpads and templates that give you boxes with space for narration underneath. While you’re in the early ideation phases, these can be great tools for keeping your designs on track and anchored in reality.

In addition to those physical/analog approaches to storyboarding, one can utilize presentation tools like Keynote and PowerPoint to at least situate screen designs in some kind of flow that tells a story.

Common Drawbacks in Existing Tools & Techniques

Tools like those outlined above have a number of drawbacks, or at least caveats to keep in mind.

Caveats for Physical/Analog Tools

These are good for quick, early, high level idea generation, but can become cumbersome for illustrating small changes to UIs or repeated contexts—you either have to redraw, copy with a machine, or simply leave out repeated elements and rely on imagination.

They do not port well into the digital world; there are techniques (like camera snapshots) that can help, but eventually they do require updating to higher fidelity, more pixel-perfect UIs.

If you do decide to bring your designs into a digital form (e.g., early sketch to hi-fi wireframe or prototype), the human context and story are left behind or must be recreated somehow. Unless you have relatively hi-fidelity sketches and have done evaluations of them with users through something like paper prototyping, you risk losing sight of the story context when you go digital.

Caveats for Software Tools

Software that focuses on UI design rarely lets us natively integrate human-centered stories, so it becomes easy for the designer to forget or leave behind that context and get caught up in technical concerns.

As noted above, even tools that talk about “storyboarding” often offer little more a display of UIs linked together, leaving out other contextual information.

Tools that capture stories and context are not integrated with the UI designs that go with them and have to be manually updated when UIs evolve.

Tools that have the story context have minimal interactive capabilities (usually just wireframes on static screens), or they are app development tools that don’t really incorporate human-centric storytelling.

How Storyboarding for Software Can Be Better

Allow me to introduce you to a software tool that my team at Infragistics designed specifically to address the common drawbacks and challenges we’ve discussed: Indigo Studio, a new interaction design tool that provides integrated storyboards with extensive rapid, code-free prototyping capabilities.

Smoothing the Transition from Analog/Physical to Digital

One of the things I don’t want to do is to assume that you will start designing your UIs with software. In fact, I’m a firm believer that you should start with a pen or whiteboard marker. At the same time, I want to help transition these static drawings to higher fidelity designs, without losing the real-world contexts that storyboards provide. To do this with Indigo Studio, you simply snap a photo of your sketches, and once your cloud-based photo stream synchronizes, you drag-n-drop the photos into Indigo storyboards.

That sketch of the hand holding the phone is built into Indigo, it’s called a scene. Indigo has 100+ of them (and more on the way), showing common contexts with people and devices. Further, when there is a device in a scene that shows its screen (as in the scene above), you can drop in your sketches or prototype screens, and Indigo automatically scales and skews them to make it look like what you dropped is being displayed on the device in the scene.

Facilitating Increasing Design Fidelity (Sketch to Prototype)

At some point, you may want to take it to the next level. You can do this in a few ways.

One way is to make your sketch interactive. To do that, you double-click the sketch in the storyboard box. This creates a new prototype screen from the sketch, on which you can then draw hotspots and begin to make an interactive prototype.

There are entire products that only let you create clickable mockups, but this is just scratching the surface of what you can do with IndigoStudio.

The other way to move to the next level is by going ahead and drawing your UI in Indigo. As you see in the screenshot above, the toolbox contains many different built-in controls. You can leverage these to trace on top of your sketch, creating a “real” prototype UI with Indigo’s interactive controls and shapes.

You can also move your sketch to the side (it’s just an image after all) and use it as reference, both to draw your new screen and to keep it around for later reference.

Note: You don’t have to start from hand-drawn sketches; you can use Indigo screens to quickly “sketch” out your UIs first, if you prefer.

Integration Between Wireframes/Prototype Screens and Storyboards

When you swap back to your storyboard after making your new screen, Indigo has automatically associated the new screen with the step in the storyboard. In the following screenshot, you see a higher fidelity “real” UI based on the same story: this is a later alternative of the lo-fi sketch from above.

What this integration means is:

Whenever you update the associated screen, the storyboard is automatically up to date in your storyboard—you don’t have to manually export an image and replace it.

You can open and edit your screen to work on it right from your storyboard.

You can even start running your prototype directly from the storyboard block, which is great for presenting a story to clients or team members.

Keeping the Focus on Real Humans in Real Contexts

Ultimately, the goal of Indigo Studio storyboards is to help you not lose sight of the stories that you are designing for once you get into designing your UIs. Because the stories are literally integrated with the UIs that you are designing, you can more easily keep the people, places, actions, and other artifacts as part of their experiential flow, front and center in your software design efforts.

Conclusion

Stories are crucial tools UX experts can use to capture and share user-related information and to help keep software design and development focused on the user. While there are tools that help with this to some extent, most have considerable pain points that make it harder for people to incorporate storyboards as a best practice into their software design process.

Indigo Studio has begun to address many of these pain points and will continue to optimize to help make it as painless as possible for designers to leverage storyboarding in their design process, and offer seamless rapid wireframing and prototyping at the same time.

ABOUT THE AUTHOR(S)

Ambrose Little has been designing and developing software since the late '90s at companies as small as one and as large as Verizon, contributing to internal systems, Web sites, and commercial software products. He is currently Principal Design Technologist at Infragistics, creators of Indigo Studio, Quince, and many other software design, development, and business tools. In this role, Ambrose manages Infragistics' UX/Design products and researches trends in Design practice and emerging technologies. In addition to making software, Ambrose has co-authored four books, many articles, blog posts, and is a regular speaker on technology and design topics.

Add new comment

Login via:

Your name *

E-mail *

The content of this field is kept private and will not be shown publicly.

Comment *

Because of problems with spam comments, HTML in comments is not permitted. URLs are allowed, but they will not be rendered as click-able links.

Hi Ambrose, I really apreciate your article..I just want to ask some questions.
I am a graphic designer but I want to expand the horizon of my career..I am working as a graphic designer in a software company right now but I am limited on programming side. My coleagues are using c# and visual studio.

1. Do I really have to learn c#? if yes until what level?
2. I am good in html and css but is it necessary to learn javascript to become a UI designer?
Please I need your advise.thank you so much I really appreciate it.

Sorry for the delayed reply. Still not getting notifications on this article..

1 - No! :) See: http://www.infragistics.com/community/blogs/ambrose_little/archive/2012/06/26/to-code-or-not-to-code.aspx
2 - JavaScript is pretty ubiquitous, so there are times when you will find it useful to know. I recommend at least a passing familiarity so you can use it if you need to. But it shouldn't be required, especially not for UX design purposes.

Rob, I'm curious what kinds of "interactivity" you have in mind because Indigo was designed specifically with modern apps in mind, and I've seen and personally created pretty complex animations with it. We have limited the scope of animations to what makes sense more for business/productivity/informational apps, with particular emphasis on the kinds of animations that enhance usability.

For instance, I wouldn't recommend it as a game design tool nor a general-purpose motion design tool (e.g., bouncing spinning balls), but most apps, even modern apps (e.g., iOS, Windows 8, Web, etc.) don't need _that_ much animation capabilities. Certainly in an enterprise app context, Indigo should be able to prototype what you need. And if it can't, I'd like to know what specifically is missing, so we can work on adding it, assuming it makes sense for the broader target audience. Feel free to suggest at http://indigostudio.uservoice.com

I would agree that at some point fine tuning on the target platforms could be needed, but that is outside the scope of an interaction prototyping tool. Indigo should be able to get you 90% there, and is a lot faster than, e.g., mucking about with HTML with CSS animations and/or JavaScript. This means you can more cheaply and quickly try out more ideas, iterate, and then once you find a good one, implement and refine that on your target platform.

About ditching wireframing/prototyping tools for coding, I've also written on that, FWIW: http://ambroselittle.com/2013/01/10/yes-ditch-traditional-wireframes-but-not-for-code

About storyboards, I wouldn't dare generalize to say that _everyone_ needs to _always_ use storyboarding or even prototyping, but I'd say that it is more helpful than the alternative approaches to software app design in most cases. It doesn't seem like jumping right into code and focusing on fancy animations is a better thing to do.

Even in your hypothetical enterprise situation, it depends. Because if the designer is wrongly assuming that the user will always be sitting down in the office at 09:00, that could be a completely wrong assumption. Users might need or want to accomplish their tasks outside of that in-office-at-desk context, and if someone doesn't take the time to research, understand, communicate, and design for those other contexts, the users will be stuck with a suboptimal app that chains them to their work desk, based on the aforesaid wrong assumption.

BYOD makes this happening entirely likely in the enterprise today. What about starting a task on the phone, working on it some more at the desk, then finishing it up that night at the dinner table on the tablet? Enterprises have a lot to benefit from taking a more user-centered approach to get more productivity from their employees, and they'll never get that if they always just assume their workers can only work attached to their desks.

Storyboarding is not always applicable when creating enterprise level applications. I found that there is huge effort in keeping your contexts up to date during the requirements gathering process. Furthermore, the client doesn't need to see a picture of "09:00, user sits down at desk and logs in" because a sentence does the job perfectly.

Storyboarding for smaller, more contained, applications works OK but it still think there is a huge jump of interactivity design that is being missed here. Having a clickable interface is all very well if your app is that simple but Indigo (and the other competitors advertising here) are unable to represent the full level of interactivity you get on the modern web (rather than simple animations you get in Indigo).

The only success I've had is getting designers either to mock in HTML or produce sketch animation frames. For those things, you don't need a tool like this. If you do build something that looks finished and show it to the client (as you often need to) they think that's exactly what they're getting AND think most of the work is done already. When you get the design to the Devs, who often have to change it due to an unforeseen constraint, you then have to manage expectations with the client - something that would have been easier if you only ever show the client scratch wireframes until UAT.

For iPhone apps I also find POP to be a useful tool. It lets you design an iPhone app on paper and then animate it with your iPhone camera: http://www.fastcodesign.com/1671490/design-your-app-on-paper-animate-it-with-your-iphone-camera

You may also want to check out PowerStory at http://www.power-story.com. PowerStory is a PowerPoint plugin that adds a rich library of over 250 UI Controls to help you build UI Mockups / Wireframes. Our library is easy to extend with your own UI Controls as well share them with others.

However in addition to that we also provide the ability to create storyboards with "alternate flows" just like you would see in a use case. This reduces duplication of common steps across storyboards, saving you rework costs.

In addition we also provide the ability to generate test cases for each unique path through the main flow and alternate flow steps of your storyboard, and insert them including their UI Mockup directly into Team Foundation Server with full Traceability. You can also export the generated test cases to Excel or Word.