A Better Prototyping Approach

I would like to share one experience I had changing the way of prototyping and making it more fun for myself and the user also saving time.

 

Prototyping is very important in a project , a finished prototype having  the user agreement may mean you have already developed 70-80 percent of your database and you have clear understanding of what you will be needing in terms of data , now you are in a better position to find out the availability of that data and less risk of finding surprises later on.

Traditional Way Of Prototyping

                The common practice is to gather the user requirements and use HTML , FLEX,MS WORD or any other technology to build screenshots and show it to user get his feedback change the screens again and repeat the same process few number of times until you have an agreement with the user. This process takes time to finalize the prototype. Sometime we also go ahead and introduce some functionality into the system where a prototype is actually saving and getting the data from database , and this adds some more time to the whole effort.

Remember the goal of this effort is to get user’s agreement on what he needs in the application.

Prototyping approach recommended by David A.Patterson

I took a course at Coursera instructed by David A.Patterson where he shared his experience with the traditional prototyping and the approach he came up with (in fact he said the approach is widely being used these days ).

 Basically he recommended to forget about all the prototyping tools at this stage of your project and take a paper a pencil and sit with user let him draw whatever he has in his mind for what he really wants in the application , of course it will span on multiple screens and discuss all one by one repeat the process until you both agree on a single screen and then do it for other screens. He said this is the fastest and fun way of working on a prototype. Once you agree on a screen think about it in different prospective , like who should be able to see this screen , what should he see and what should be hidden based on role , here you are preparing your test/acceptance cases.

I tried this approach in one recent system I developed for my company and it really helped and saved some time and involve the user at very early stage of the project. Since he drew his requirements for me he had the right expectations from the first iteration of the project J.