Providing proof through prototyping

Prototyping is a term that is often used but can mean many different things to different people and within the context of product development there are many roles that a prototype can play. The value of any prototype is linked to the expectations placed upon it, and much of the success of any prototyping activity comes down to being clear about what it is expected to achieve. Modern day prototyping techniques are so powerful that one of the key challenges can often be in understanding how much development has gone into the device or product sat in front of you. This has enabled people to blur the boundaries of what a prototype is intended for, which can be both powerful and at the same time misleading.

This article will explore some of the functions that a prototype may be intended for throughout the product development process and identify where there may be differences that are not apparent at first sight. It also proposes a nomenclature intended to highlight these differences and provoke thought into why you are building a prototype.

Types of prototype

Let’s start by breaking down three broad areas for use which we will term Demonstrators, Proof of Principle & Prototypes:

Integrated prototypes

These are the assembled builds that get produced towards the second half of your product development cycle. They will often be prefaced by terms such as ‘looks like’, ‘looks like / works like’ or ‘looks like / works like / made like’ to indicate the state of development.

The development process:

Project inception

The early days of product development are all about the art of what might be possible. As product developers we want to present our ideas on how we can break new ground, whether that is through advances in technology, new ways of interacting with users or taking advantage of new information that is available. The challenge here is getting buy in or investment into a project rather than making concrete design decisions, however it is worth considering the expectations that are set when demonstrators are produced at this stage.

Risk based approach to product development

Once a product development is underway it is important to tackle the most difficult problems early on. These challenges could be technical or possibly user related, but at this point prototypes are being used to demonstrate the feasibility of an approach and design decisions are being made off the back of these, whether based on engineering tests or user-based studies and so the prototypes need to be representative of final product in the function of interest.

This stage of a development can be challenging to manage as it is the area where challenges arise and things are most likely to require iteration. Expectations of project sponsors needs to be managed through an understanding of what they might expect from prototypes.

System integration

As more complex systems are integrated, it is important to consider the dependencies of different subsystems on one another. A mechanical system may require some electronics

and software in order to test functionality, a diagnostic instrument may require a cartridge to run and so forth. These specific dependencies will dictate the ideal path to take, and in some cases there is inherently some iteration where there are interrelated dependencies.

Ultimately, as your product comes together, the assembly of subsystems enables the formal verification and integration in to full product prototypes provides the validation of the subsystems. This can often follow a path where initially the look and feel of the integrated prototypes may be defined up front (looks like prototype), and then evolve, adding in the functionality (looks like / works like prototype), and in the final iteration, a product is transferred to manufacture (looks like/ works like /made like prototype).

In conclusion

Prototypes have many different uses throughout the development process, and there is a natural tension between product demonstrators and the more functional proof of principle prototypes, particularly in the early days of a project. The right balance depends on the degree of technical challenge in your project, the funding environment, and the involvement and attitude of project sponsors. However, while striking this balance can be something of an art, the key is to be clear and about what your prototype is trying to achieve and when there are design decisions being made.