The path less taken.
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.
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).
There are four types of page layout structure.
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.
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.
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.
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.
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)
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:
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:
When evaluating your storyboard, you should also consider:
The nature of the screens and links between screens in your storyboard may differ depending on which of these you choose.
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:
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.
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.