Storyboards and How They Help in Product Definition

by Nov 23, 2020#UIUXDesign

Printer Icon

Table of Content

  1. Introduction to storyboards
  2. What is a storyboard?
  3. Who can use a storyboard?
  4. Where can we use a storyboard?
  5. When can we use a storyboard?
  6. How do we create a storyboard?

Introduction to storyboards

During the UI/UX design process, it is essential to develop and represent the product’s experience through the user’s eyes in order to define the project’s objectives and requirements as well as to identify challenges.

There are many ways to convey what the product’s experience may be. Two of those are detailed (long) user stories and short user stories.

Detailed User Stories: Detailed user stories consist of lengthy descriptions of a use case, with plenty of specifics and distinguishing information. These long user stories help design teams understand the environment and inputs that the user is subjected to while using the product. There are many questions that must be answered to develop a detailed user story. Following are just a few:

  • Who is the user?
  • What does the user need to do and why?
  • What is the user seeing?
  • What is the environment?
  • How does the user feel?
  • What is the journey through the product?

Short User Stories: Short user stories help determine what actions a user needs to perform. These stories consist of short sentences that answer three simple questions:

  • Who is performing the task?
  • What does the user need to do?
  • Why does the user need to accomplish this task?


(For more information and analysis of short user stories, read our blog post entitled “Understanding Use Cases, Use Case Scenarios, User Stories, and Flow Charts in UX Design.”)

User Stories are not a bad tool, but for a more graphic way to map a product, we recommend using storyboards and navigation flows.

Let’s start with some basic definitions.


What is a storyboard? 

Storyboards are drawings, images, or diagrams that tell a story in chronological order. We are used to seeing these types of pictures from behind-the-scenes features about movies or TV shows. Writers and directors try to see how a story will develop visually before filming it; that way, they can make any necessary changes in a quick and straightforward manner rather than re-shooting.

Something similar happens with storyboards in the UI/UX process. Storyboards are a set of images that display the story of the usage of a product. This story could focus on a specific feature or action that the user needs to perform. We could say that storyboards are a graphical representation of detailed user stories. With storyboards, the idea and details of what’s happening with the user while performing a task is conveyed through graphics and captions. In essence, storyboards must answer the same three questions used for a short user story, but in a graphical way.

As in the film and TV show example, storyboards allow us to see how a product will be experienced before we get to the actual design and development. Iterations at this stage are much less expensive than if we had the whole product implemented and then realized the flow and the experience were not what was envisioned.


Who can use a storyboard?

As designers, our brains already work in a storyboards kind of way when we’re designing a mobile or web app. We envision what the user will see and where we want to guide the user. We can picture graphics, buttons, texts, and other components that the product may need, and we also understand how they work.

In addition, however, it is essential to look at the design process from the perspective of documentation, requirements, and feedback. Designers often need to share these flows with other team members, such as product managers, technical leads, testers, marketing managers, and others. Putting scenarios in a graphical form helps those other team members visualize the use case and provide meaningful feedback.

Prioritize aspects of your product and determine which topics need a more detailed or graphic exemplification. Also, be aware of how storyboards may benefit other team members:

For product managers, storyboards are beneficial for:

  • Defining a product
  • Visualizing different approaches to solving a specific problem
  • Identifying missing features or requirements

For marketing managers, storyboards are beneficial for:

  • Comparing experiences between competitors
  • Understanding the context and environment of a sale
  • Providing feedback about user research, user profiles, and personas

For technical leads and developers, storyboards can help identify aspects such as:

  • Response time a user is expecting for a specific process or input
  • Development constraints
  • Platform limitations
  • Technical needs

For UI/UX designers, storyboards are helpful for evaluating:

  • The overall experience of the case, time consumption, number of steps, etc.
  • The environment or context of the product’s usage
  • Platform and device standards
  • Possible side scenarios
  • Error prevention


Where can we use a storyboard?

Storyboards can be used to graphically exemplify any case. Sometimes, however, the flow of a mobile or web app could extend significantly in content and depth. In that case, developing a storyboard of every possible scenario or feature might not be the best choice. Depending on the situation, storyboards can become impractical and time-consuming.

Try to use storyboards primarily to exemplify the following use cases:

  • Scenarios where the user’s full attention is required for the process
  • New processes
    (It is essential that team members understand the implications of new approaches.)
  • Main features
  • Purchase processes
  • Troubleshooting


When can we use a storyboard?

Storyboards can be used any time we want to use them or any time a product or project would benefit from them. Consider the benefits of using storyboards at different phases of product development:

In the beginning: If we develop storyboards in the product definition phase, it is less likely that we’ll see requirement changes in the later stages of the project.

In the middle: All projects are unique, and there are times that changes occur within the course of a project. Even when designs enter a testing stage, we may encounter information or data we had not previously considered that would change the product’s experience. For these occasions, it is essential to stop, gather more details, and rethink the experience. Storyboards are particularly useful for that revisualization. We can compare the original experience with the new approach, analyzing the impact of the changes before taking the product fully to design and implementation.

In the end: Product evolution never ends; feedback and iterations are vital. Markets and users develop and change with culture and technology. For an established product, storyboards can help us modify the product’s current experience, as well as compare, test, and receive feedback on modifications that are being considered. It is important that consideration of any change always be driven by user research and feedback.


How do we create a storyboard?

The first step in creating a storyboard is to define the scenario or feature that you wish to develop graphically. To keep the flow clean, simple, and easy to understand, make sure the scenario is not too complicated in length or number steps.

If a crucial step or feature you wish to develop as a storyboard is too involved or lengthy, try breaking it into short steps by content so you can better visualize individual parts of the storyboard. For example, a smart device setup can sometimes involve multiple steps to achieve a complete device setup. We can break those steps into the following sections: discovering the device, setting up Wi-Fi, personalizing the hardware, and finishing the setup. Each of these sections would probably have its own set of steps to be represented in a storyboard.

After identifying the scenario you would like to develop, you’ll need to answer the same questions asked for short user stories: Who? What? and Why? You get answers to those questions from user and marketing research data and product management definitions.

When you have all the information you need about the user, the process, and the environment, then you can choose how you want to create your storyboard.

Storyboards are often developed with photographs and drawings. These drawings can illustrate a situation or the screens the user is seeing. If you happen to have real images of a user engaging with the product or service, use them. Remember to place the pictures or drawings in chronological order.

Then, you must plan your content correctly before placing it into the graphics.

One activity we recommend is to play with sticky notes as if they were the storyboard’s actual frames. Instead of drawings, the sticky notes will show the names or descriptions of specific steps. Playing with these notes can help you visualize the process and change the order of frames as necessary. You can also categorize the notes by colors and sections if the number of steps is too great.

When you’re sure of the content and the order of your storyboard, it’s time to replace each frame with images or drawings. In each frame, you can leave wording for actions, impressions, or thoughts that you believe the user is experiencing. You may also have notes about the environment; for example: Is it raining? Is it dark? Is it evening? All of these notes are very important in conveying context that can influence design decisions.

Finally, do not forget to iterate. Based on accurate feedback and user research data, design evolution is essential. Test your storyboards with team members, designers, and users.

About Us: Krasamo is a mobile-first UI/UX Design and consulting company focused on the Internet-of-Things and Digital Transformation.

Click here to learn more about our UI/UX Design services.


Using High-Fidelity Wireframes to Document UX Cases

Using High-Fidelity Wireframes to Document UX Cases

A wireframe is a tool within the discipline of UI/UX design that consists of a graphically simple 2D representation of a product, screen, concept, UX case, etc. for a user interface, without setting colors, specific shapes, final icons, etc.