A great product idea means nothing without proper execution. Although very powerful, our imagination can stand in the way of a successful execution because it never depicts things exactly how they are going to be in reality. Rapid prototyping can help bridge that gap between imagination and reality.
When the Google Glass team came up with the idea to add a laser keyboard to the glasses that enables the user to type on any surface, they needed to decide on the color of the laser for projection. Tom Chi, the Experience Lead for Special Projects at Google and a rapid prototyping evangelist, later said that it wasn’t an easy process. The team sat together to discuss the laser color but the counsel got protracted, and, instead of deciding, participants started leaning toward whichever side had the better speaker.
Tentatively, the red color won. Then Chi quickly made a simple prototype to test different colors of lasers, and red turned out to be the worst option according to the whole team. Even those who had defended it by a wide margin didn’t like it. But, more importantly, the team discovered that the laser keyboard would flash the user’s friends, family, or colleagues in the eyes if they distracted him or her from work. No one had predicted that outcome; the feature was abandoned. Could they have arrived at this outcome during the discussions? Hardly. Bottom line, the time the top managers and engineers spent discussing this problem was many times more expensive than the prototypes, and, more importantly, it did not bring any results.
Indeed, speculative discussions lead to nowhere. This is true even for low-tech products. Take lamps. If your team is working on a desk lamp and trying to decide on the shade of light, everyone will find rational arguments to adopt a warmer or a cooler shade, and there will be no way to make a specific choice other than a vote. But voting won’t give you any real experience with the product, you won’t be able to put yourself in the customer’s shoes, and some team members will become frustrated that their opinions have been discarded.
Another frequent problem with team discussions is the inability to make a decision. For instance, once at Woodenshark, we were launching production for devices in two colors, white and black. The marketing team decided to add a third one, gray, but wasn’t ready to give an exact shade yet. They kept discussing what shade of gray to use for the next one and a half months until it was time to cast the plastic parts, which is impossible to do without a specific color.
To solve the problem, we took samples of the cast parts in different shades of gray, picked the best ones, and cast our parts in the color we chose. It took us two days to do this, while the marketing team of seven people had been spending at least 15 minutes weekly during meetings to make a decision. It took them six weeks, and they still came up with nothing.
Why Speculative Discussions Lead to Nowhere
All these examples prove that rapid prototyping is indeed a powerful and useful tool that helps companies avoid losing money and time and make the best product possible. There is a popular joke about a meeting that could have been an email, but there are situations when a meeting or a number of meetings could have been a rapid prototyping session.
As a rule, when a team starts to work, they analyze the main constituent parts and quickly decide what to take as the basis and put that at the heart of the future product. There are a few reasons for this; it blocks further development, the choice is quite easy to make because it is rational, and the options are chosen according to some specific criteria such as cost, performance, the team’s previous experience, etc.
The problem often lies in the less important functions and blocks and especially in issues that cannot be evaluated rationally. They can drag the team into a black hole of lost hours spent on discussions, doubts, and attempts to imagine the best result.
What is Rapid Prototyping and When to Use It
Rapid prototyping is already ingrained in digital product design where ideas are tested with minimum viable products (MVPs). This process often involves users themselves because some design and hardware details are hard to evaluate without their participation. With the advent of prototyping technologies, teams can now greatly reduce the customer feedback loop, allowing for faster decision-making and gradually reducing future risks for their product.
The concept is not new, but, in many ways, the hardware industry is still ideologically conservative although technology is changing faster than the way we think and the way we work. It’s time for us to move from seeing our ideas as facts to understanding that they are just hypotheses that require testing. Assembling a model of a product or its part allows us to evaluate the ideas about it without throwing money and time away.
The idea behind rapid prototyping is to make choices easier, so you should use it when
- you have some ideas about the technical parameters of the product and several prototypes will help you to measure which performs better
- you have an unmeasurable property, such as color, surface, or shape which can only be truly evaluated when the team sees it in the real world
Rapid Prototyping: How To
You should always have a clear purpose for a prototype before making one. Prototypes are good because you can save development time by making them, but they can waste as much time as discussions if you don’t know exactly what you want to test and measure with them.
To make prototyping useful, you should answer the following questions:
- What will be tested and evaluated and how?
- How will you compare different prototypes?
- What kind of result will be enough to make a decision?
Strive to test minor questions when prototyping the minimum amount of parts (not the whole device, but a screen or a button), but always test major and most important questions on the whole assembled prototype. There are many dependencies within parts of your product that are sometimes easy to miss without assembling the device. Also, if you can test technical properties with your team, it’s important to run UX-related tests (interfaces, appearance, user scenarios, etc.) with people who know nothing about your product.
And last, but not least, learn some basics about statistics and logical mistakes because your tests will give you no information at all if they are not developed thoughtfully. If your experiment isn’t clear of possible noises and disruptions, then you won’t receive a reliable answer.
One of the most fundamental ideas about developing anything is that the earlier you define the problem, the cheaper it is to solve it. Initial requirements for development often have gaps, and it’s much more inexpensive to find and fix them during the systematic testing of the prototype.
If used right, rapid prototyping can protect the project from many potential risks. However, if you thoughtlessly do it without defined goals and methods, not only will you waste time and money without finding any issues and solutions to them, but you’ll also create more problems.
Keep in mind that the best ideas about improving a product still come from the users’ behavior and feedback, so you still need to solve the problems they identify. In most cases, when decisions about the product are based just on its teams’ perception, the project happens to have technical debt.
Of course, prototyping is not a cure-all; it’s a way to test hypotheses. Rather than argue about the right placement of an abstract button or screen, design teams can define the purpose and use of their product and test it using rapid prototyping.
Related Podcast Episode
Related Applications
Latest IoT News
