Prototyping

Prototype is an early sample or model built to test a concept or process or to act as a thing to be replicated or learned from. In many fields, there is great uncertainty as to whether a new design will actually do what is desired. New designs often have unexpected problems. A prototype is often used as part of the product design process to allow engineers and designers the ability to explore design alternatives, test theories and confirm performance prior to starting production of a new product. Engineers use their experience to tailor the prototype according to the specific unknowns still present in the intended design. For example, some prototypes are used to confirm and verify consumer interest in a proposed design whereas other prototypes will attempt to verify the performance or suitability of a specific design approach. In many product development organizations, prototyping specialists are employed - individuals with specialized skills and training in general fabrication techniques that can help bridge between theoretical designs and the fabrication of prototypes.

Basic prototype categories There is no general agreement on what constitutes a "prototype" and the word is often used interchangeably with the word "model" which can cause confusion. In general, "prototypes" fall into five basic categories: Proof-of-Principle Prototype (Model) (in electronics sometimes built on a breadboard). A Proof of concept prototype is used to test some aspect of the intended design without attempting to exactly simulate the visual appearance, choice of materials or intended manufacturing process. Such prototypes can be used to "prove" out a potential design approach such as range of motion, mechanics, sensors, architecture, etc. These types of models are often used to identify which design options will not work, or where further development and testing is necessary. Form Study Prototype (Model). This type of prototype will allow designers to explore the basic size, look and feel of a product without simulating the actual function or exact visual appearance of the product. They can help assess ergonomic factors and provide insight into visual aspects of the product's final form. Form Study Prototypes are often hand-carved or machined models from easily sculpted,

inexpensive materials (e.g., urethane foam), without representing the intended color, finish, or texture. Due to the materials used, these models are intended for internal decision making and are generally not durable enough or suitable for use by representative users or consumers. User Experience Prototype (Model). A User Experience Model invites active human interaction and is primarily used to support user focused research. While intentionally not addressing possible aesthetic treatments, this type of model does more accurately represent the overall size, proportions, interfaces, and articulation of a promising concept. This type of model allows early assessment of how a potential user interacts with various elements, motions, and actions of a concept which define the initial use scenario and overall user experience. As these models are fully intended to be used and handled, more robust construction is key. Materials typically include plywood, REN shape, RP processes and CNC machined components. Construction of user experience models is typically driven by preliminary CAID/CAD which may be contructed from scratch or with methods such as industrial CT scanning. Visual Prototype (Model) will capture the intended design aesthetic and simulate the appearance, color and surface textures of the intended product but will not actually embody the function(s) of the final product. These models will be suitable for use in market research, executive reviews and approval, packaging mock-ups, and photo shoots for sales literature. Functional Prototype (Model) (also called a working prototype) will, to the greatest extent practical, attempt to simulate the final design, aesthetics, materials and functionality of the intended design. The functional prototype may be reduced in size (scaled down) in order to reduce costs. The construction of a fully working full-scale prototype and the ultimate test of concept, is the engineers' final check for design flaws and allows last-minute improvements to be made before larger production runs are ordered.

Characteristics and limitations of prototypes Engineers and prototyping specialists seek to understand the limitations of prototypes to exactly simulate the characteristics of their intended design. A degree of skill and experience is necessary to effectively use prototyping as a design verification tool. It is important to realize that by their very definition, prototypes will represent some compromise from the final production design. Due to differences in materials, processes and design fidelity, it is possible that a prototype may fail to perform acceptably whereas the production design may have been sound. A counter-intuitive idea is that prototypes may actually perform acceptably whereas the production design may be flawed since prototyping materials and processes may occasionally outperform their production counterparts. In general, it can be expected that individual prototype costs will be substantially greater than the final production costs due to inefficiencies in materials and processes. Prototypes are also used to revise the design for the purposes of reducing costs through optimization and refinement. It is possible to use prototype testing to reduce the risk that a design may not perform acceptably, however prototypes generally cannot eliminate all risk. There are pragmatic and practical limitations to the ability of a prototype to match the intended final performance of the product and some allowances and engineering judgment are often required before moving forward with a production design. Building the full design is often expensive and can be time-consuming, especially when repeated several timesbuilding the full design, figuring out what the problems are and how to solve them, then building another full design. As an alternative, "rapid-prototyping" or "rapid application development" techniques are used for the initial prototypes, which implement part, but not all, of the complete design. This allows designers and manufacturers to rapidly and inexpensively test the parts of the design that are most likely to have problems, solve those problems, and then build the full design.

Outline of the prototyping process

The process of prototyping involves the following steps 1. Identify basic requirements Determine basic requirements including the input and output information desired. Details, such as security, can typically be ignored. 2. Develop Initial Prototype The initial prototype is developed that includes only user interfaces. (See Horizontal Prototype, below) 3. Review The customers, including end-users, examine the prototype and provide feedback on additions or changes. 4. Revise and Enhance the Prototype Using the feedback both the specifications and the prototype can be improved. Negotiation about what is within the scope of the contract/product may be necessary. If changes are introduced then a repeat of steps #3 and #4 may be needed. Advantages of prototyping There are many advantages to using prototyping in software development some tangible, some abstract. Reduced time and costs: Prototyping can improve the quality of requirements and specifications provided to developers. Because changes cost exponentially more to implement as they are detected later in development, the early determination of what the user really wants can result in faster and less expensive software. Improved and increased user involvement: Prototyping requires user involvement and allows them to see and interact with a prototype allowing them to provide better and more complete feedback and specifications. The presence of the prototype being examined by the user prevents many misunderstandings and miscommunications that occur when each side believe the other understands what they said. Since users know the problem domain better than anyone on the development team does, increased interaction can result in final product that has greater tangible and intangible quality. The final product is more likely to satisfy the users desire for look, feel and performance

Disadvantages of prototyping Using, or perhaps misusing, prototyping can also have disadvantages. 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. Further, 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. 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. (They are, for example, often unaware of the effort needed to add error-checking and security features which a prototype may not have.) 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 are able to require all proposed features be included in the final system this can lead to conflict. Developer misunderstanding of user objectives: Developers may assume that users share their objectives (e.g. to deliver core functionality on time and within budget), without understanding wider commercial issues. For example, user representatives attending Enterprise software (e.g. PeopleSoft) events may have seen demonstrations of "transaction auditing" (where changes are logged and displayed in a difference grid view) without being told that this feature demands additional coding and often requires more hardware to handle extra database accesses. Users might believe they can demand auditing on every field, whereas developers might think this is feature creep because they have made assumptions about the extent of user requirements. If the developer has committed delivery before the user requirements were reviewed, developers are between a rock and a hard place, particularly if user management derives some advantage from their failure to implement requirements. 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. (This may suggest that throwaway prototyping, rather than evolutionary prototyping, should be used.)

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. When the prototype is thrown away the precisely developed requirements that it provides may not yield a sufficient increase in productivity to make up for the time spent developing the prototype. 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. A common problem with adopting prototyping technology is high expectations for productivity with insufficient effort behind the learning curve. In addition to training for the use of a prototyping technique, there is an often overlooked need for developing corporate and project specific underlying structure to support the technology. When this underlying structure is omitted, lower productivity can often result.