The old adage that 'a picture is worth a thousand words' is never truer in software development than in relation to the User Interface (UI) Storyboard. I am working on requirement modeling today and I am once again reminded of the value that simple storyboards can add to overall requirement modeling.
Even though I know how to build it "the right way", I tend to model some requirements and feel that I have enough information to start designing and/or coding. I was creating a design model this morning for a subsystem and had a lot of detail in it. I started working on the data model, however, and several questions popped into my head.
While trying to answer the question, I repeatedly went back and forth between the requirements artifacts and the design artifacts. It was like trying to get the bubbles out of a carpet. Every time I smoothed one bubble, another appeared in a remote location. Then I started thinking along the lines of "how will the user actual perform this task?" I quickly realized that the problem domain is not as well understood as I had thought initially and that more detail is needed in this iteration.
I spent about an hour creating a simple UI storyboard focused on the question that had arisen. Fortunately for me, it not only paid off to help answer that question, it also raised several other situations I had not considered but that could prove the initial design inadequate.
I was chatting with a friend about UI storyboards and we discussed different tools we use to create them. Here are my suggestions for successful UI storyboarding. By "successful" I mean that you get a big value from a relatively small effort.
In my vernacular, a UI storyboard is NOT a prototype and NOT a proof of concept. It is an organization tool that allows you to preview a sequence of events without expending a lot of effort.
I use Microsoft(R) PowerPoint(R) for most storyboarding.
- It offers a wide range of display & visualization tools, navigation options, and deployment formats.
- It is generally more available than other products such as Microsoft(R) Visio(R). Visio is GREAT for UI storyboarding. However, as a consultant, I run into a lot of situations where clients don't have Visio.
- It is relatively quick. I have a few UI storyboards from past projects on which I rely to provide a baseline. A few changes to the Master Slide and I am off and running.
I have also used other tools.
- Visio - As stated above, I like Visio for a UI storyboard tool but I find it is not as common as other tools.
- HTML - I have done a few storyboards in HTML. You might think that it seems a very logical choice, especially for Web apps. I find a few problems with it.
- Effort - It is relatively time consuming. Without writing code (such as a Master Page), you will have to redo a lot of work for each page. For example, if you remove a page or add a new page in a multi-page process, you might have to modify "main menu" links on every page.
- Expectations - Viewers have higher expectations. I find that people viewing a PowerPoint presentation tend to have less expectations and, therefore, more ability for abstraction than with HTML. I can only assume it is because they are viewing the storyboard in a browser and, as such, expect everything to "work".
- Tear-Off Sheets - I love this option as well. It is extremely fast and provides virtually immediate feedback. I actually start with these when in a group setting and then migrate to a digital format.
- Whiteboard - I love whiteboards too but they don't have the permanence that tearoff sheets have. This is why someone put a camera on your phone!
Don't skip storyboarding. In fact, if you don't feel like opening Word(R) and typing, create a storyboard. If you are new to storyboarding, you will be amazed at how many questions are answered with relatively little effort.