In part 2 of this series, I discussed the fact that a business user of software spends 100% of their time interacting with the user interface, yet we as software developers, spend only 10% to 25% of our time developing user interfaces and spend most of our time under the covers, buried in the technical details.  As mentioned in the previous post, the business user could care less about whats under the covers in any given software application.

 

I suggested one way to increase our software development productivity and reduce product delivery risk is to spend more time on user interface development and the interactions with the business user.  I suggested that we borrow a tried and trued technique from another industry, the film industry, and develop inexpensive storyboards, that represent the user interface screens that the business user actually interacts with.

 

While we do use some storyboarding techniques in our software development process, we dont take it far enough.  I would suggest that no code is written until all of the storyboards for a business application have been developed and approved by the business user(s).  Much in the same way all of the storyboards for a film have been developed and approved before a single frame of film has been shot.

 

I think that following this storyboarding approach (without writing any code) would dramatically increase the success rate of designing and constructing business software applications. This would remove the trial and error approach (read: major source of risk) to software development that we currently have today or at least for business software, where the business user spends 100% of their time interacting with the software.  Some might say that prototyping (in iterations) is the same approach.  I would disagree, because prototyping involves writing code and soon we are lost in the details and mechanics of writing code, (under the covers again) and increasing the gap between what the business user wants in a software application and what we think the business user wants.  Remember the business user interacts with the just the user interface 100% of the time.

 

Others would say that users dont know what they want so how can we develop the storyboards?  I would suggest that if the business users dont know what they want, then we have no need to write a software application.  While I am being a bit facetious, I also believe this to be true.  If the user requirements are so ambiguous that storyboards, even using pen and paper, cant be developed, then whats the business need for software?  It has been my experience that someone or persons in an organization knows exactly what is required, you just need to find those people.

 

So how do we storyboard what a business user wants?  First we need a storyboarding tool to do this.  In the film industry, it is still done mostly the old fashioned way pen and paper.  However, since we have a computer and the business user is the target user of the storyboards and the storyboards themselves are the representations of user interfaces and provides the interaction between the business users, it makes sense to develop the storyboards as complete (representations of) user interface screens.

 

At one point in my career, I remember working on a project where we took this storyboarding approach and developed all of the user interface screens and the order that they were used for business users, using Windows Forms in Visual Basic 6.  In fact, a few of our programmers at the time, could literally whip the forms up on the spot as they were very adept with VB6 and with absolutely minimal coding could storyboard the order of the screens while clicking on OK or next buttons.

 

The business users were ecstatic with this approach cause within a few weeks we had developed over 50 screens that represented the entire business application.  Not only did this give the business users exactly what they wanted, it also provided us with a complete blueprint of what was to be constructed.  This dramatically reduced the risk of the project failing and reduced the cost of the project because we had our complete specification.  This is one approach to industrializing the software development process.

 

Next we will explore a specific storyboarding approach that separates user interface definition from implementation.