The Usability Architect

The forceful employment of prototypes would lead to situations, in which the development team could continuously present their interpretation of stakeholder needs and the corresponding design solutions to the client. People can much more easily articulate what they need by playing with prototypes. Prototypes can turn stakeholders into partners in a collaborative software-development process. Prototypes externalize conflicts and require stakeholders to handle trade-offs. The sooner individuals can access simulations of their requirements, the earlier they can recognize the need for modification and decision-making. This, in turn, decreases the risk of costly late-cycle changes.

The medium of prototyping is a means of communication that has been recognized by stakeholders of various disciplines related to the design of modern software systems. In software engineering, prototypes are used to verify functional specifications and models, as well as for understanding problems by carrying out user inspections and testing. In usability engineering, prototypes are recognized as an artefact for iterative UI design. They are employed for requirements analysis, producing alternative designs and for gathering user feedback. Here, the role of prototypes is therefore a particularly deep-seated method for propelling user-friendly development and is primarily related to the UI of a software product (Preece et al. 2002). In today's software market, usable products are desirable products. Providing task-adequate functionalities is mandatory, but there is great competition to deliver them with a high grade of usability. Ease of use therefore differentiates software products in a highly competitive market place. Ease of use brings an added value that culminates in a higher degree of customer satisfaction, continuing business and higher revenues. In addition, customer satisfaction provides market differentiation (Jones & Sasser 1995).

Literature:

• Preece, J., Rogers, Y. and Sharp, H. (2002), Interaction Design: Beyond Human-Computer Interaction, John Wiley & Sons.
• Jones, T. O. and Sasser, W. E. (1995), 'Why satisfied customers defect', Harvard Business Review, vol. 6, no. 1, pp. 88-99.
• Memmel, Thomas (2009): User Interface Specification for Interactive Software Systems. Schriften zur Informationswissenschaft, Bd. 54, ISBN 978-3-940317-53-7, VWH Verlag

In order to better incorporate prototyping efforts into software-development practice, several fundamental issues have to be addressed in order to identify the right prototypology, for example:

• Appropriate fidelity. Discuss different fidelities of prototyping and their con-tribution to the software-development process with regards to the externaliza-tion of functional and non-functional requirements.
• Pressure of time and budget. Determine prototypes that can be developed within time and budget constraints in order to overcome objections to early-stage prototyping.
• UI development fragmentation. Identify the kind of prototypology (Schrage 1999) that can take client and supplier relationships into account and become part of contract-forming.
• UI specification support. Consider forms of prototyping that can become rec-ognized as well-engineered models that evolve into specifications and final products.
• Adequate traceability. Externalize the interdependency of models and design, turning the UI development into a transparent engineering process.

Although prototyping is useful in any situation where a requirement is not clear, there are several reasons why prototypes are often disregarded as a valuable methodology in many software-development projects, for example:

• Cost-saving measures. Requirements prototypes are usually throw-away products and are not expected to evolve into the finished product (Robertson & Robertson 1999). It is therefore likely that project managers save on their development, especially when the role of look and feel and usability is underestimated or misunderstood, and stakeholders are used to textual descriptions of requirements.
• Form of contract. If an external IT supplier is assigned to design and code the software system, the production of prototypes is usually deferred until the specification sheet has been produced (Schrage 1999). The consolidated specification is usually necessary for forming a contract between client and supplier. It is unlikely that the supplier will start working before the specification is finalized.
• Delaying influence. Even if prototypes are created during early stages, the chance of them having significant impact on the consolidation of written requirements is very low. Depending on the complexity of the software that has to be built and factors such as time and budget, building a first prototype can take (the IT supplier) several weeks, or even up to a month (Schrage 1999). This is mainly due to poor responsibility assignment and excessive up-front processes. Results are not likely to be received until there is no longer any opportunity for extensive changes.

Consequently, software developers tend to produce first prototypes very late in the overall process, if at all, although well-established lifecycle models do recommend it for the earlier stages.