Often, a project doesn’t feel real until a reasonable facsimile of the final product is produced. A prototype offers a decent approximation of the final product that can inform future iterations of research and development, design and development. Even well-reasoned design processes benefit from a tangible, if incomplete, prototype. Here’s a few ideas on how to approach and use information from prototypes.

As design nears a close, it’s often possible and advisable to create a mockup of the system being developed. Doing so is a great way of transitioning from design to creation and can help discover unforeseen obstacles and problems that are harder to discover in the abstract.

Examples of Prototypes as a Learning Technique

Electrical and computer software engineers are already well versed in the necessity of prototyping. Much hardware and software development happens through cycles of prototype development and redevelopment.

In abstract design, one can avoid and eliminate obvious errors that will ensure a prototype will fail, but in complex systems it’s usually a smaller detail that can compromise system integrity. These are often very difficult to discover looking at pages of code or a printed circuit board design specification. Simply put, it’s hard to visualize what a particular circuit or piece of code will do until it’s put into action. Once a prototype is created, problems are often much more obvious. Successive prototypes can solve these problems and are themselves tested for validity. This iterative cycle of development helps make the design and realization of a complex system that much easier to grasp.

Prototypes are not only valuable for logical systems, however. Physical systems can benefit greatly from simple mockups of design in progress. Both Formula SAE and Mini Baja create prototypes of the frame before manufacturing the car itself. These mockups are fabricated from wood, and known dimensions and locations of parts are mocked up using foam, spare parts, and other available placeholders.

The frame mockups accomplish four goals:

• Making systems conflicts tangible: It is often difficult to conceptualize system integration and interdependency issues in the abstract, especially with mechanical systems. A mockup makes potential integration issues obvious and spurs new designs to resolve those problems.
• Catching problems before it’s too late: Unlike software development, fixing problems after the fact in mechanical systems can be significantly more complex. Ripping out pieces of foam is much easier than ripping out pieces of steel or remanufacturing a part.
• Allowing for attention to qualitative details: The Formula SAE car is generally well regarded by design judges because all systems seem to be integrated neatly and efficiently. It is perhaps easy to ignore this as irrelevant, but there is a certain subtle effect functional aesthetics provides. In a quick evaluation of a team’s work—and most evaluations are quick—if it looks right, it probably is. Functional and aesthetic packaging is greatly improved through the use of mockups, where major and minor packaging conflicts can be resolved early. Competing cars that do not take advantage of mockups often have systems and parts that even lay observers will suggest just look wrong.
• Building morale and motivation: Often, by the end of the design phase, team members are frustrated with formal, abstract design and want to get into realizing the project. Prototypes are a great way to get people involved in this process and signify the eventual transition to manufacturing.

Traps in Prototyping

All this said, prototyping should be approached carefully and at the right time.

By making systems more tangible, prototyping also serves to lock down certain system parameters. It’s much harder to think outside of the box if you’ve just built a box. Prototyping should be avoided early in design and become increasingly necessary later in the process. If started too early, it is easy to become locked into the constraints of the prototype and not see other alternative solutions.

Care should also be taken with respect to the use of systems that are products of continuous iteration. At times, it is preferable to redesign completely based on lessons learned from successive prototypes rather than make another sketchy fix. Although it is possible to add a quick code fix, solder a jump over an incorrect circuit, or drill another hole next to an incorrectly drilled one, too many iterative fixes of the sort can make the final product look poorly designed. At times, it is necessary to compile all lessons learned from iterative design and create a new, well-integrated design.