User interface prototyping: Risks / Problems / Disadvantages
Filed Under Problems, Pitfalls, User, Interface, Prototyping, Issues | Posted on February 16, 2008
User Interface Prototyping is seen as a great value adder to the entire project; it helps to get better user input, show the final functionality to some extent, and determine short-comings. However, like any other process, it has its weaknesses and pitfalls and one needs to be careful in the prototyping process, and never lose sight of the goal for which the prototype has been developed. Some of the potential problems are:
* Insufficient analysis: The focus on a limited prototype can distract developers from properly analyzing the complete project. This can lead to overlooking better solutions, preparation of incomplete specifications or the conversion of limited prototypes into poorly engineered final projects that are hard to maintain.
* Since a prototype is limited in functionality it may not scale well if the prototype is used as the basis of a final deliverable, which may not be noticed if developers are too focused on building a prototype as a model. By the time this is determined, it would be expensive to take corrective action.
* User confusion of prototype and finished system: Users can begin to think that a prototype, intended to be thrown away, is actually a final system that merely needs to be finished or polished. For example, they would be unaware of the effort needed to add error-checking and security features and the proper quality testing that the final product would need. This can lead them to expect the prototype to accurately model the performance of the final system when this is not the intent of the developers.
* Users can also become attached to features that were included in a prototype for consideration and then removed from the specification for a final system. If users find these prototype features to be interesting, they may require that many of these new features be included in the final system this can lead to feature creep.
* Developer attachment to prototype: Developers can also become attached to prototypes they have spent a great deal of effort producing; this can lead to problems like attempting to convert a limited prototype into a final system when it does not have an appropriate underlying architecture.
* Excessive development time of the prototype: A key property to prototyping is the fact that it is supposed to be done quickly. If the developers lose sight of this fact, they very well may try to develop a prototype that is too complex. Users can become stuck in debates over details of the prototype, holding up the development team and delaying the final product.
* Expense of implementing prototyping: The start up costs for building a development team focused on prototyping may be high. Many companies have development methodologies in place, and changing them can mean retraining, retooling, or both. Many companies tend to just jump into the prototyping without bothering to retrain their workers as much as they should. Many of them do not know about the level of effort needed.
* It is critical to understand that you don’t need to create a prototype for the entire system. It is very common to prototype a small portion of the user interface, perhaps a single screen or HTML page, before moving on to implementing it. This can be ignored by both developers and users.
* Not aligning the design with project constraints. In the urge to show off exceptional talents, developers might be tempted to invent ingenious solutions that exceed what is possible with the time and budget the project has at its disposal. If shown to clients directly, it can put the project in a precarious situation, where we either have to cover the extra cost ourselves, ask the client for more money, or explain to them that what they saw, is not what they are going to get.
* Interface designs have far-reaching consequences for the entire development project. Design by blinkered dictatorship is not a viable alternative to design by committee. Need to get inputs from colleagues and not decide on the entire interface design by just 1-2 people.
* Whatever poor coding practices you use to build your prototype will be replicated in the final production version.
Leave a Reply
