Best Practices for Prototyping in Software Development - 4

Posted by Ravindra under Software Development Practices, Software Development Prototyping

This article is the fourth in series of articles on Prototyping in Software Development.

Who should be involved, how far you should go and when do you have to do Prototyping in a Software Development Project?

Often Prototyping in Software Development Projects will be done without planning and without involving the relevant stakeholders. This will lead to wrong expectations, initial budget overruns and customer satisfaction issues.

1. Who is Involved?
Prototyping can be done informally by anyone, regardless of their background or role in the project. It’s easy to make a simple but effective prototype by taking a bitmap from Adobe Photoshop, putting it into the Microsoft FrontPage Web site creation and management tool, and adding active buttons or links. These lightweight prototypes only go so far, and can become unwieldy for complex interactions.

For more formal prototypes by larger teams, a developer or project manager will often collaborate with a designer and a usability engineer. Together they’ll generate ideas, build a prototype that represents the best ideas, and then go into the lab to see how effective it is in solving user problems. Developers might get involved if they can spare the time, or if their technical expertise is needed. Often the designer or project manager will do most of the scripting or coding to build the prototype.

Treat this phase with importance, just like any other phase in SDLC and try identifying and involving the relevant stakeholders at all stages in the prototyping stage.

2. When Do You Build a Prototype?
Depending on the scope of the prototype and the level of detail required, prototypes can be built at any time during the project. Most often they are created early in the project, during the planning and specification phase, before developers write any production code. That’s when the need for exploration is greatest, and when the time investment needed is most viable. If developers instead of program managers or designers are prototyping, scheduling time becomes even more important because you need to make sure the work invested in the prototype is accounted for in the development schedule. Planning for any UI release should include some level of prototyping.

Late in a project, smaller prototypes can help resolve tough design and technical issues. A quick HTML mock-up of how a dialog box or Web page should behave can help answer a developer’s question or give other teammates a feel for what the desired experience should be. In some cases, a strong program manager or designer can implement the behavior in Microsoft JScript development software and approximate much of the programming logic that developers will need to think through.

The time it takes to create a prototype can vary tremendously, depending on the scope and precision of what the end result needs to look like. An informal prototype could mean a few hours of work by one person; a more organized effort can involve weeks of effort by an entire team.

3. How Far Should You Go?
In your prototype, build only as much of the design as you need. It’s okay to have buttons that don’t work, or text that never updates. As long as you can experience the interactions you want to explore, it’s fine to use smoke and mirrors for the rest.

Here are a few reasons why you should focus your efforts carefully:

3.1 Cost of building the prototype.
You want to minimize the cost involved in building the prototype. The challenge with prototyping is recognizing the minimal investment needed to effectively answer your questions about the design. This is where usability studies are critical, because they clearly identify the parts of your UI that need the most work. Even without usability studies, you should clearly define what user problems you’re trying to solve, or what tasks you’re trying to improve, with the design in your prototype.

3.2 Limited lifetime.
Prototypes should have clearly defined lifetimes. Is the end goal a presentation at a team meeting? An executive review meeting? A spec review? A usability study? Convincing yourself, with your devil’s advocate hat on, that the design solves a user problem? Once the needs for these specific objectives are met, the prototype should be set aside. The basic mindset is that the code or bitmaps generated in a prototype will be left behind in most of the cases. There might be exceptions where code or visuals live on in the product, but the expectation should be that this won’t be the case.

3.3 Risk of overwhelming the team and setting wrong expectations.
Showing prototypes to developers and teammates can be tricky. An overly complex or elaborate prototype, with amazing visuals and animation, can overwhelm people. You should always have a sense for how far to go and how much of what you’re creating in the prototype you want to be taken seriously.  This is important because to build this amazing visuals with full functionality will be a challenge and will take more effort.

So the general practice that is preferable to follow is to involve people who can later be part of the design and development team, try writing code and scripts during prototype phase in a language that can be easily merged and scaled to the actual language and projects that you use as part of the subsequent phases in your projects.