Storyboarding
An important part of my job is to analyze requirements and write specifications. I have found the technique of storyboarding to be extremely effective. A storyboard is a concrete rendition of a particular scenario - could be a use case or an XP story (see Martin Fowler on UseCasesAndStories for an explanation of the difference). Not only are storyboards great for sorting out requirements, they are also effective in communicating what needs to be built to developers, and as a starting point for the development of tests.
If what you are building is exposed to the user through UI, then the most likely form of your storyboard is a click-through of the UI. If what you are building is infrastructure, say an API, then your storyboard might be a click-through of the experience a developer goes through in authoring code that uses the API, or it might be a filmstrip - a series of object diagrams that illustrate what happens to the state of the system as methods are executed.
Tools that I have found to be particularly effective in developing storyboards, especially those that click-through a UI experience, are Powerpoint and Visio. You can really bring storyboards alive in Powerpoint using a combination of moving through slides, using its custom animation capabilities, and by mixing and matching graphics from multiple sources. And the Windows XP template in Visio is pretty useful too. I've put up an article with specific hints and tips on using Powerpoint and Visio for this purpose.
Interestingly, I soon move from sketching a storyboard on paper or the whiteboard to committing it to Powerpoint, as the latter imposes a discipline that forces you to make decisions and care about the detail. It's so easy to continue hand-waiving and putting off those hard decisions at the whiteboard. I don't spend a large amount of time getting the UI 'just so'. It just needs to be good enough to tease out those important decisions about what the requirements actually are.
If anyone has suggestions for alternative tools that could be used for this purpose, then please add them as comments to this post.
Comments
- Anonymous
July 01, 2004
Hi!
We are (also) dealing a lot with requirement analyzing and found storyboards quite helpful as well. Probably it depends on the type of projects, we are mostly doing large enterprise individual sw-developments with .NET.
However: before we create storyboards we are collecting and writing usecases. A very good book on describing this methodology is "Writing effective Usecases" from "Alistair Cockburn". How much you go into detail when writing usecases depends of course on the project. Sometimes you only write short user stories or actor-goal lists, sometimes you specify down to the usage level.
Only after writing the usecases we are moving to creating storyboards. The reason for this is, that creating story boards is already "design": design of user workflow and UI, which (a) needs someone with architectural skills and (b) needs some architectural decisions to be done before (e.g. like what kind of client the system is going to have).
Mixing up requirment analysis too much with design often yields in strange solutions. Therefore, when endeavoring the problem domain of the user, we found it most beneficient not to be distracted by design details. Only after having analyzed the requirements we are making architectural decisions and one of the first steps we take in design is writing storyboards.
Regarding tools for creating storyboards:
We found it very distracting to create storyboards in Visio, PPT or even ASP.NET. Instead we are using whiteboards where the creative process of design is not interrupted by technical usage details. Also we found it very distracting if you are getting lost in small details before you have completed the big picture consistently, especially in larger projects. A very good tool we found for working on the whiteboard is eBeam (e-beam.com) which is a cheap solution to electronically capture on almost any whiteboard.
Once the storyboard is completed we also think that PPT is a good tool to put the different UI forms together (which you copy/paste from the whiteboard protocol recorded with ebeam then) and for creating hyperlinks between them.
When the user, who ususally has no experience in formally specifying his requirements for a piece of software, has to review the usecase specification we found it a great help to walk through the usecases while presenting the already designed UI using the storyboard. - Anonymous
July 02, 2004
Christian, thanks for sharing your experiences. I think storyboards can still be used to tease out requirements, without slipping into design, provided you understand the UI used is indicative, and is there to make things concrete; it is not there to specify exactly how the UI should look or exactly what the user workflow should be (a storyboard will usually illustrate just one workflow out of many). However, I work in an area where much of the architecture is already established for you and there are significant constrains on the design of the UI. So it's probably less of an issue for me.
I agree that there is nothing to beat a whiteboard in brainstorming ideas with colleagues. However, I find the process of entering the sketches into Powerpoint and Visio helpful for reviewing and reflecting on the results of those brainstorming sessions, as well as being great for ironing out areas of ambiguity and raising further issues that need to be discussed. You can then go back and review with colleagues and use further brainstorming to iron out the issues raised.