Introduction

Learn how to use storyboards to help develop efficient and user friendly pathways through your systems user interface. A lot of the charts and diagrams you will use during Software Design and Development will focus on managing and manipulating data. This makes sense as data is typically the primary focus of the reason for the existence of the software. An effective user interface (or user experience) is invaluable in terms of the users perception of your product. There's no point in having solid processing if the users give up in frustration at a lacking UI.

Storyboards are one of the first steps in developing an effective user experience. They will help you work out which screens your product will have and the paths users will take between them.

Storyboards are useful for software development and are also useful for website development.

What does a storyboard look like?

A storyboard is a diagram showing the screens that make up the user interface of a system and how you navigate between them. The system may functionaly do exactly what the user desires but if the path the user takes through the screens doesn't match up with the way they want to work then it can be a rather frustrating experience for the user. Storyboards help us as software developers visualise and optimise this aspect of our system before we dive in and start building.

Here is an example of a simple storyboard for a kiosk in a shopping centre:

As you can see there is a rectangle representing each screen which has a title and minimal detail. Just enough detail to show the intent of the screen. Any buttons or elements which lead to another screen are also shown. These navigation elements are joined to the screen they link to by an arrow.

The amount of detail you inlude on each screen can be as little or as much as you like. There are no specific rules regarding this. Generally it is best to keep it low detail and rough like in the example above however. The intent of storyboards is to represent the paths through the system and these may change as you learn more about the system. You don't want to spend a lot of time on details that aren't adding value in terms of the objective of the diagram (and which very well may be thrown away as screens are redesigned).

Types of page layout structure

There are four types of page layout structure.

• Linear
• Hierarchical
• Non linear
• Composite

Normally these describe the main links between pages and there will be links in other ways between pages as well. These are also just descriptions of general patterns. You don't have to adhere to one of these.

Linear

In this pattern there is a single main path between the screens in an orderly fashion. This is useful when the task is linear and fairly fixed in terms of how you will go about doing it.

Heirarchical

In this pattern there is a main page. Beneath that are sub pages and beneath them are futher sub pages and so on. This is useful when there are decisions that need to be made and the user will go to different screens based upon those decisions. It is also useful when you have a lot of informatin to present which is organised categorically.

Non linear

In this pattern there are links between pages in a non structured way. This if often the case when the task is non linear and the user can make decisions leading to different screens. Wikipedia is a good example of this type of layout.

Composite

It is often the case that a combination of these layouts will be the best approach. Different sections of your software or website will utilise different patterns. For example this website is organised in a heirarchical manner at the top level but then each tutorial is organised in a linear layout. (Similar to the example below)

Experimenting with layout

For storyboards to work effectively with software design and development you need to be able to easily play about with them. It needs to be quick and effortless to move screens around, redo/ add/ remove paths between screens, change the rough layout on pages etc. If you've put too much time and effort into your storyboards and they are difficult to change you will tend to put your first impression down and leave it at that apart from maybe minor tweaks. Instead you want to be able to easily look at it, discuss it, radically change it etc.

Here are a few ideas for things you can do to this effect:

• Draw very rough and very quickly on paper.
• Use a whiteboard
• Take sheets of paper and fold into four squares, then cut out. These become your screens. Draw the screens on them then use blu-tac or magnetic buttons to attach them to the whiteboard. Use whiteboard markers to draw the connections between the pages.
• There is software available specifically for storyboarding.
• You can also use a vector based drawing package such as Inkscape.
• Using the drawing tools within a word processor is also doable.

Evaluating

Once you have your storyboard put together you need to evaluate it. For a simple piece of software you are developing there may only be a few screens, which are obvious, and the links between the screens may also be obvious. You should still evaluate your storyboard however as there are often opportunities for improvement. Things to consider are:

• Are there missing links between screens which would make life easier for the user?
• Are there links which aren't really needed and can be removed?
• Are some paths needlessly complex and can be simplified?
• Could a screen be added, creating new paths which might help simplify things?
• Is a particular screen redundant and could be removed?

When evaluating your storyboard, you should also consider:

• Are you targetting novice users with your software and want navigationg between the screens to be intuitive?
• Are you targetting expert users with your software which demand efficient and quick operation?
• Do you want a mixture of both with the expectation that novice users will grow into expert users who want more power?

The nature of the screens and links between screens in your storyboard may differ depending on which of these you choose.

Testing with scenarios

When first looking at a storyboard, it can be difficult to tell if the layout contains all the necessary screens and if they are effectively laid out or not. A good way to find out is to create a series of scenarios and work through the storyboard following the scenario.

A scenario is a story describing how a user would go about doing a task. It can be as paragraphs of text, or as bullet points. It is important that we write the story from the point of view of what the user is doing and achieving as opposed to how the user is interacting with the software. Doing the former will lead to software designed around the user. Doing the latter will result in software that dictates how the user works with it.

Here is an example of what a scenario might look like for a user who has forgotten their password:

• The user wants to use the portal to check progress on a task. They need to log in so the system knows who they are and that they have permission to do this operation. When they first open up the system it asks them for a username and password. The user has recently changed their password and has forgotten what they changed it to.
• The user tries a few attempts at what they think it might be. None of these are correct.
• The user now wants to reset their password. To do this they are asked for their date of birth. They are then sent a code by sms and an email is sent to them with a link to reset their password.
• The user clicks the link in the email and enters the code they were sent. If this is correct then they are provided a form to reset their password.
• The user is now offered the opportunity to log in again.

There were some references to screens or particular software actions in the scenario above. This was inevitable. You'll notice however that as much as possible I have discussed what the user is doing without specifically mentioning how they will interact with the software to achieve it. This allows us to easily try several different screen layouts against the scenario and see which works best.

Next is to test our storyboard agains the scenario. Print a copy of your storyboard and (in a different colour) draw a line running through (or just to the side) of screens to indicate the path the user takes in fulfilling the scenario. If it is a particulary complex scenario you can also put numbers next to events in the scenario and label those on the path on the storyboard also.

The big picture

A good storyboard will take the processing that has been explored and outlined in the previous charts and diagrams and help to organise it into effective paths for the user. It is also an important diagram in terms of developing the software from the users perspective.

Summary