03 Jan Why Prototype? 

Prototyping can be a divisive issue within an organization.  Critics cite additional cost and time to create a prototype when resources should be focused on the “real work” of getting the product designed and out the door.  Proponents point out the quicker turn on a prototype and the ability to reduce the risk of the overall project schedule. Where should you stand? This blog discusses prototypes in their varied forms and the pros and cons of each.

There are many different kinds of prototypes.  A piece of paper folded into the shape of a product enclosure is a prototype.  At the opposite end of the spectrum, a pre-release model of a production product is also a prototype.  There are prototypes that have the same shape as the product but only dummy electronics to display representative screens and prototypes that look nothing like the final product that are used to characterize circuitry and software.  Prototypes come in many different shapes, sizes, costs, and complexities, and each has its own specific goals. Therefore, when determining whether to prototype, the answer is, “it depends.”

This blog will focus on the following types of prototypes:

Mechanical Look-Alike / Show-and-Tell

These prototypes are “dummy” models used to show people roughly what the prototype will look like.  These could be as simple as a folded paper model for simple enclosure geometries to a rapid mechanical prototype using SLA or 3D-printing techniques.

Folded paper models quickly and very inexpensively put something into a prospective investor’s or user’s hand that lets him or her see how the device will look.  These are good for evaluating the industrial design elements of the product: is it the right color? Shape? Size? However, paper models are limited in the shapes they can create and do not give an accurate representation of weight or texture of the final product.  

Rapid mechanical prototypes such as SLA and 3D-printed models go beyond paper-folding and can handle more complex geometries and are still inexpensive.  They can be designed to allow weights to be added to give the exact weight of the production unit, which gives end-users a very life-like product to evaluate.  They may not be able to replicate the exact texture of the final product due to limitations in the printing or SLA process, but they can save a lot of time and money on tooling during the concept phase, especially if deciding among multiple designs.

Proof-of-Concept

Proof-of-Concept prototypes are early versions of a product that needn’t have the right form factor, are not designed to be as robust as the final product, and whose main purpose is to demonstrate that the core feature(s) of the device works as intended.  The effort on these prototypes will be focused on the technical parts of the design, especially where novel science is involved. Proof-of-concept prototypes therefore must have the interfaces to the real world that will be used to collect external data, the algorithms to process it, and the interfaces to return results or actuate controls; however, these components may not be representative of the final product.  For example, a proof-of-concept will frequently use off-the-shelf evaluation or development boards to save the time and money needed to develop a custom PCB from scratch. They may use parts scavenged from existing products (including competitors’ products) for their interfaces where the final product will have a dedicated vendor.

Proof-of-concepts are critical prototypes when developing something new.  When modifying an existing product, the existing product may act as the proof-of-concept.

UI Evaluation

UI Evaluation prototypes are used to let users interact with the UI, especially for formative usability evaluation.  The size, shape, location, and arrangement of controls and indicators can be prototyped to see how users interact with the device, to identify whether the controls contribute to use error, and to receive feedback from users on how to make the device easier to use.  UI evaluation prototypes are usually show-and-tell prototypes with circuitry and/or software put in place to step through a set of UI configurations (screens, LED patterns, sounds, etc.), without the underlying features developed to actually perform diagnostics or treatment. This significantly reduces the cost and timeline of the prototype, since the “main guts” of the device needn’t be implemented.  It also reduces the chance that a user will inadvertently damage the system or cause injury by moving a control beyond its intended limits because the UI is not connected to anything capable of causing damage or harm.

Sub-System

Sub-system prototypes are used to test a small piece of the device, usually from a technical standpoint, to establish how to correctly use an electronic component or piece of software.  The primary purpose of a sub-system prototype is to de-risk the project: establishing on a breadboard how to use a complicated integrated circuit is far less expensive than designing the final product only to realize that the IC has been hooked up wrong in the schematic, and prototyping a software module in isolation is far less complex than developing the entire software application just to test a small piece.

Test Platform

Test Platform prototypes are generally developed in parallel with the actual product and are used for characterization and/or unit testing.  They consist of entire electrical systems or sub-systems that have been instrumented to allow injection of stimuli and monitoring of outputs.  They generally are not intended to be form-compatible with the production unit. Rather, they are designed to allow ease of access, although some parts of the production design may be copied verbatim.  From a software standpoint, unit tests are a perfect example of a test platform. Production code is modified slightly to allow the injection of test vectors, and the outputs are compared with the expected results.  In short, a test platform is production hardware and/or software with slight tweaks to allow easier manipulation of the inputs and outputs to different sub-systems.

Early Production Model

Early Production Model prototypes are in essence the stepping stones towards reaching the final production model.  It is usually to these particular prototypes that critics refer when they say, “just design it”.  Because early production models typically require the same amount of process rigor as the final production models, it is understandable that critics would want to limit the number of these built.

However, not all early production model prototypes are bad.  Very early production models might be developed on off-the-shelf evaluation boards to allow software development to occur while the production board is being designed, thus reducing the schedule with only incremental cost.  While the software intended for final production must be developed following the software lifecycle, the hardware needn’t be assembled to the same rigor. Unless the final product will use the same development boards, the prototype is clearly not representative of the final product and therefore doesn’t require full design controls, documentation, etc.  The drawback, however, is that because the prototype is not representative of the final product, it is difficult to justify using it for any kind of formal verification. Exceptions exist, but they are not the rule. 

Later early production models that are close enough in form, fit, and function to the final device may be used for formal V&V with proper justification.  These later early production models that are close to the final design will also be used by manufacturing personnel to establish the manufacturing processes and work instructions to build the product and perform risk management activities on the manufacturing processes.  

But the question remains:

why build a prototype when you can just develop the final product?

 

The most-cited reasons are usually cost and schedule. Designing an entire PCBA only to realize that it doesn’t fit the final desired form factor, connects a component incorrectly, or doesn’t allow a desired feature to be implemented is time-consuming to do.  It is extremely expensive to build hard tooling for an enclosure only to realize that the enclosure is too small, large, or the wrong shape to be usable by end-users and it is a major impact on schedule to wait to develop anything in software until production PCBAs are available.  Prototypes help mitigate all of these risks.

Another major function that prototypes serve is to answer questions.  Some of these questions have already been touched on:

As described in our blog Is Your Design on the Road to Success?, having the answers to all of these questions and more is critical before beginning formal development because not having the answers leads to hesitation or wasted effort, both of which affect schedule and may also affect cost.  Prototyping is one of the fundamental means to getting those answers.

Prototypes are also much less expensive in terms of process than formal development.  While all prototypes should be configuration-managed, formal documentation is not generally required for prototypes, formal design controls need not necessarily be followed, and changes may be made much more rapidly than the final product.  Note, though, that whether formal processes are required or not depends on the intent of the prototype.  If the prototype could be sold or used in formal V&V testing, then it is almost certain that formal processes are required.

Note that although usability engineering is a formal process, prototypes used during formative evaluation need not be formally developed.  Summative evaluation, however, does require products under formal design controls.

Note, too, that although prototypes need not follow formal design controls, the importance of maintaining the right documentation cannot be stressed enough.  Do maintain a revision history of your design documentation (schematics, software, 3D models, etc.) to allow referencing them later.  Even if the schematic or rough sketch is hand-drawn on a piece of paper, scan it and save it in a common location so that it can be easily found later.  Do keep track of what the intent of the prototype is and what was learned from it.  Write it down; having lessons learned as tribal knowledge subjects them to misremembering and loss of details.  This documentation does not need to be formal. It can even be written in a notebook or text editor so long as the information is captured in a way that can be found and referenced later, preferably by others besides just the person who wrote it.  Maintaining this kind of information is invaluable because it helps to establish requirements and—just as importantly—their rationale, and having the data available within the organization in a location where people know where to find it streamlines later discussions if the author isn’t available.  

Conclusion

Prototypes come in many different shapes, sizes, costs, and complexities, and they have different goals.  Some are geared towards lay audiences while others are used by technical personnel to hone and prove the design, but all can be used to answer questions.  While most do not require formal design controls, some do, and all prototypes should have sufficient documentation to make the exercise of creating the prototype worthwhile.  Yes, prototypes take additional time, but the benefits of risk reduction, ability to answer questions about the design more quickly, and ability for multiple teams to work in parallel to design, characterize, and verify the design are well worth the incremental time and cost.

The Realtime Group has years of experience in development from concept through prototyping to design transfer in many industries including medical, defense, aerospace, oil and gas, and consumer electronics.  Let our experts help with your design and prototyping needs. Give us a call at 972 985-9100 today!