Significance of Prototyping in Software Development Process

By Anoop Madhusudanan

Vote on HN

Any software or technology, in it's final form, is expected to solve a business problem for an end user. And hence, it makes perfect sense to enable the end user to validate the requirements visually, before the actual construction - to ensure that there are no surprises in the end.

 
Yes, this sounds so obvious, but it is often amazing to see how teams neglect such a powerful technique like prototyping

Prototyping the user interfaces and workflows early enough will ensure
  • There are no frequent change requests and release time hotch-potch
  • Requirements are captured properly
  • There is clarity in functional scope (in scope and out of scope)
  • Analysis is good enough to start the construction phase.
Why you need Prototyping?

In most scenarios, customers are not really aware about what they need. Capturing the requirements also means working with the customer to envision the final system, and at times, to suggest possible alternatives.

Let us take an example. Assume that you have a whole-sale carrot distributor as your customer, who is owning the company "Thick Red Carrots" and he is having a requirement.
"I need a simple program to manage the distribution of carrots I purchase from my suppliers. I also need to view and track the location of all my sales guys in the field; to know the number of shops they are covering a day, and to track the number of carrots they are selling in each shop. I also need the software to give my tax statement from my sales data"

When you dissect the requirements for this 'simple' software - obviously you can see the scope is increasing. And after several rounds of discussions with your carrot whole seller, you understood the actual requirements - still on a high level.

Briefly, the system should include
  • A user management and payroll module to enter and manage sales staff details.
  • An allocation module to allocate a geographical boundary for each of his sales guys on a daily or weekly basis.
  • A module for interfacing with sales guys - the sales guys will use their mobile device to enter the collection data back to the system, from the field.
  • A supplier management module
  • A stock management module to track the in house stock, allocated stock etc to foresee and report possible stock deficits
  • Admin module to enter master data - including employees, stocks, suppliers, shops (customers) etc
  • Reports for reporting all this
You also found that you need to address specific conditions, like overlapping of sales regions, back-collection of damaged carrots etc. Gasp. Gasp. Gulp, Gulp.

Prototyping To Help

You have several challenges. To mention a few, you need to
  • Make sure your carrot seller understands the features required for the final system, so that he won't cry about the scope creep.
  • Ensure your design and development teams are understanding the requirements, so that they won't miss out any functionality, and at the same time they won't over engineer.
  • Ensure all workflows and specific business cases are documented
  • Ensure all customer expectations are clearly identified and captured (remember, the tax calculation part)
You turn to a white board, and start visualizing the screens and user actions. (For an illustration, I'm using http://www.balsamiq.com/ for some quick drawings). You decided that the main screen should allow easy navigation to all modules, and hence should be having a tabbed interface. The entry screen will display a summary of statistics, and will may have few quick links as shown.

You go further, and sketch up few individual screens as well, based on each requirement. To enable the end user to define sales regions, you might create a user interface with a map - so that the end user may draw a sales region with in the map, to specify the allocated stock for the sales guy to sell in that region, and the date of allocation.

With these sketches, you might goto your end customer, and take him through these screens. You might get straight forward comments like "The dashboard screen looks awesome, but I need to view my current stock there in numbers". Few comments might definitely alter the scope, like "I need to import my employee contacts from outlook".

And once the end customer agrees on the screen protoypes and how he may switch back and forth between them, you are good to pass it to your design and dev guys, to take it to the next step.

Another key point to have in the back of your mind - When you present the prototypes, make it clear that it is just a wire frame to demonstrate the functionality. And if possible, present a real life snapshot of atleast one of your screens, to clarify your point.

Tools for doing prototyping

There are various online and offline tools for doing prototyping. You can google around to find a few. I use Balsamiq for quick and static UI prototyping, http://www.balsamiq.com/ - and Microsoft Expression Sketchflow for some serious prototyping.

The good thing about Sketchflow is that it supports workflow prototyping and behaviour prototyping to some extent. What's catchy about Expression Sketchflow is its ability to provide a dynamic, 'clickable' interface for the user - so that the user can get a some what realistic experience.
© 2012. All Rights Reserved. Amazedsaint.com