There is one topic that presents a matter of confusion in virtually every new client project. It is the subject related to the following question:
What is a…
The answer? It depends and there are no two companies (or sometimes individuals in one company) who will give you the same answer to these questions. While I don’t claim to be the only person whose opinion matters, perceptions of the meaningful functions related to each physical and digital entity here can be used to set reasonable expectations. Both product developers and businesspeople can use these perceptions to create mutual understanding at each juncture of the development effort. Because this is a subject that is so individual and non-standard, the following info is intended to help; it spells out how to avoid difficulties that arise when discrepancies in what a prototype should be or do exist between clients and their development practitioners.
In engaging with a service provider like IPS (or IPS engaging with a client), a common language for such things must be arrived at to avoid under-investing in these deliverables or “over engineering” them. Here are some definitions around these items. You’ll note that there are some overlaps between them.
Description:
In the case of hardware, a mockup could be as simple as a foam core physical representation or as much as a fully machined representation with a high level of fit and finish. A mockup could be a crude representation of the product using off the shelf parts to demonstrate feasibility or a functionality without any regard for the appearance or ergonomics. For software, a mockup could be simply a matter of static, graphic screenshot representations. It could be a very limited functionality representation of the product.
Purpose:
These are often used in very early stages of product development to get a feel for a hardware product’s aesthetics and ergonomics. While everything we do as engineers and designers can have digital representations, aesthetics, and ergonomics are still best tested using a physical representation. In the case of risky new products or technologies, a physical mockup created by “cobbling together” a bunch of off the shelf materials to show a function or test a feasibility can be extremely useful. Similarly, when it comes to software, evaluating user interfaces and user experience, it is often quite helpful early on to get a sense of user feel for the appearance and intended flow of an application. Since mockups are very early in the product development process, mockup assessments can allow for evaluation of key product criteria before significant effort is devoted to productization.
Limitations/caveats:
The limitations here are obvious. A mockup is in no way, shape or form a fully developed representation of the product. They are purpose-driven representations. Mockups must be very clearly explained when a client and a consulting firm like IPS are included in a proposal or statement of work.
Description:
A model is a very broad description for something that represents a product. Typically, they can be either non-functional (sometimes referred to as a “looks like” prototype or model), partly functional or functional (sometimes referred to as a “works like” prototype or model. In early stages of product development, models are commonly not functional or only partially functional. In later stages, models often have limited or fully product functionality. When custom parts are being developed for the product, models rarely are produced using production processes.
Purpose:
Models are used for a variety of purposes. These can be to evaluate aesthetics and ergonomics. They can also be used with early user testing to evaluate various features, functions and user experience. They are often used at trade shows to launch new product introductions in advance of having finished product available. From a mechanical perspective, models can be used to assess assembly fits or to perform limited testing.
Limitations/caveats:
Since models are not fully released products, they are often created using rapid prototyping methods such as 3D printing and additive manufacturing. Even when functionality is embedded, they rarely have gone through rigorous testing as found in production level embodiments. It is not unexpected that models, particularly in early stages of development, may have flaws and significant limitations. If you are buying services from a product development team and evaluating their proposals, a client would be wise to spend a good amount of time defining what is and what it is not to be included in “models” since there are no fixed definitions. The cost of creating models can vary wildly so it is important to be clear in the purpose and capabilities of models and in defining how many “models” are needed and at what time during the process. Lastly, models are rarely very durable so handling physical models should be done with care and consideration for this fact. Because of these limitations, be very careful with how models are used and realize that, whether they are for software or hardware products, models can be quite fragile.
[LATEST] Product Development Process Series:
Description:
Prototypes are typically later stage representations of the product or purpose-driven for testing of final product systems or subsystems. While certain features, functions, or physical parts may not have been made with production-level manufacturing processes, they often will look, feel, and work similar to the final product. For subsystem or system-level testing, prototypes may be designed for specific purposes.
Purpose:
For example, a prototype PCB may be created to test the circuitry and embedded software ultimately to be rolled into a product. A mechanical prototype could be created to test not only part fits but also to perform certain early-stage testing to ensure the lower elements of a design are likely to satisfy ultimate product requirements. In some cases, prototypes, like mockups, may be suitable for tradeshow or product launch events. They have the benefit of higher level authenticity when compared to models or certainly mockups.
Limitations/caveats:
As with mockups and models, prototypes are not a finished product. They share some of the same limitations. That is, they are rarely fully tested or debugged. Because the processes to create prototypes are not necessarily those of a finished product, quality may not be up to finished product standards. For subsystem or system testing, prototypes are built specifically for evaluation and debugging purposes. In fact, one might say the purpose of such prototypes is to uncover bugs and flaws for corrective action prior to engaging in late-stage productization processes.
[CASE STUDY] Aero Pure – From Concept to Production
From concept development to proof of concept we developed a working prototype suitable for pathogen kill testing. We supplied the expertise required to move concepts from inception to manufacturing. Read the full case study →
Description:
Engineering Validation Test (EVT) units are used by engineers to ensure the final hardware satisfies all functional requirements found in the product specification or Product Requirements Document (PRD). In order to ensure that the design is as close to final as possible, it may take one more iterations to verify that all functional requirements are being satisfied by the design. EVT models are typically created from hardware using processes that are very close to those of ultimate manufacture or that generate embodiments with characteristics that closely simulate those of production processes.
Purpose:
EVT devices are created as part of the late-stage product development process. They are purposely constructed to fully represent the final product with all subsystems and functions fully integrated. This is a design quality insurance step to confirm, the ultimate product will satisfy the requirements of the PRD.
Limitations/caveats:
Because EVT models (there is that word “model” again…) are not necessarily constructed using full production line processes, there may be some limitations. Commonly, the fit and finish may not be up to final product quality standards. Since EVT models are constructed to test function, final appearance is not a critical characteristic in this stage. However, the form should represent the final product.
Description:
Design Validation Testing (DVT) units are one of the last stages before the product is fully transferred into manufacturing. In this case, it will be necessary to have the models built to be suitable for all forms of testing. They are often constructed with manufacturing processes however such model runs are typically very short run – much shorter than even a first level production run.
Purpose:
DVT models are used for full environmental testing. This is testing for conformance to requirements for temperature, humidity, water resistance, impact resistance, etc. They are also used for regulatory pre-certification tests and even submission for regulatory approval. Any failures in this stage will require rapid corrective action to remediate failures.
Limitations/caveats:
There should be no limitations in the use of such models as they are intended to fully represent the final product in every way.
Description:
Production Validation Testing models are used to evaluate mass production. Because there can be unit-to-unit variability as a manufacturing process ramps up, it is not a given that the first unit off a manufacturing process will look and perform identical to the 1000th unit off the same production line. Obviously, PVT is always performed on full production quality manufacturing lines.
Purpose:
This is used to evaluate the manufacturing process more so than the quality of the product design. While design flaws can show up during PVT builds, if the proper processes have been followed, design flaws should be very rare. However, there could be issues with things like tooling, fixturing, staging, etc. that need to be optimized to have a product that can be manufactured with high yields (i.e. extremely few products failing final acceptance testing) and with consistent quality.
Limitations/caveats:
There are no limitations on such units. Typically, these are units that are deemed ready for sale and shipment to customers. While the manufacturing process may need to be fine tuned during this stage, the end products coming off the line should be of the quality expected for the finished product.
CONCLUSION
The preceding descriptions do not represent all of the terminology used in product development processes. People may refer to things like samples that are even more vaguely defined. Even with these descriptions, do not accept them as common knowledge. Do you have your own personal or corporate definitions of such things? Great. Just make sure when engaging with a product development partner, or even discussing such things internally within your company, make sure there is clarity across the board as to what is meant by these terms for the purposes of your collaboration and development effort. Especially when working with an outside partner, it is advisable to have such descriptions clearly articulated – preferably in writing – so as to avoid confusion, disappointment, increased costs, and delivery delays. At a minimum, whether you’ve engaged a product development partner like IPS or are designing in-house, be sure to have specific discussions regarding working definitions of models and prototypes to ensure that everyone is on the same page.
[LATEST] Product Development Process Series: