Prototyping

By | June 25, 2009

In this post I will try to post pro”s and con”s of user interface prototyping in software development projects.

First, let me explain you what I call UI propotype.

UI Prototype for us is user interface draft for all screens of system with maximum behavior (JavaScript where possible, popups, etc) and completed design. Usually design is something that can be changed very easy so often prototypes has several design versions for review and selection. Prototype doesn”t contain business logics inside or connnection to database, it is just list of interconnected screens. I can show you examples:

Here you can see two prototypes of one not big software project, Inventory system. One and two.

Another prototype of small/average project – project manipulates with business data according different sets of rules. You can see it here.

We often propose to implement such prototypes when we need to develop medium/large complexity business project because:

  • It helps us to show customer what we can do, how it will look, what will be the logic of application, looking and clicking through prototype customer can already feel what his application will look like, select the design he would like. so in the end it won”t be black box where you don”t know – have this service provider understood me correctly and will deliver what is expected? Prototype answers 70% of this question as you can judge about understanding of project by looking at prototype.
  • Customer can make changes in requirements (and it happens very often I must say) before actual implementation is started. And making changes in requirements is cheapest on this stage.
  • Developers can use the prototype then to understand application instantly and develop the screens like it is in prototype. Technically prototype is part of specifications, just instead of UI screens in word document we have UI screns which are connected and already shown as application.
  • This design and html coding that is done for prototype, it is then reused by developers in templates (when it”s web). So this work is not buried in specifications.
  • Prototype can be used as part of specification to set a goal/task to even another provider (not the one who developed proto). Or to sub-contractors, it will be easier to explain them what you want.

I think there are other advatages of prototyping, just can”t remember now 🙂

As for disadvantages – I know following:

  • It takes some additional time – usually prototypes are done in 1 week (from small/mid level project) to 4 weeks (for big projects ) together with specification document. (Overall we often do prototype even for small function/pages if there is any chance of misunderstanding/unclear requirements. better to spend 4 hours on prototyping, then later remake the page 3 times until it looks what customer wants.)
  • But prototype still doesn”t garantee full understanding of project and business logic behind it – as it is only User Interface, not full application.
  • One more thing – if your application is constantly changing – supporting prototype will be also rather complex. So in this case it can be partial prototyping or no prototyping as well.

But in any case, according our experience – UI prototype greatly decreases the risk of misunderstanding between provider and customer in software development, and this is very important for our work. So when we see it will help us in communication with customer, help customer to better understand his goals and check his expectations, help in communication between developers in team –  we always propose to develop prototype.

I wrote this article to give it sometimes to new customers and explain why we propose to make prototypes 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *