Pitfalls of Building a Product Prototype

Software products can be designed and built in many ways. Quite often, it starts from a prototype. Based on the prototype it’s decided whether to improve and iterate the idea, take it to a different direction, put it on hold to wait for better times or just ditch it. But sometimes the prototype or a demo ends up to be a final product and that’s not the right way to go.
Goals for prototyping
There are different goals for prototyping. It varies from testing an idea of a product using UI mockups to implementing a quite extensive feature set. Sometimes prototyping is needed to understand a new technology or testing different solutions to reach a target or to get performance right. The goal really depends on a case. In this post we focus mostly on software prototyping where the mentioned goals can be applied.
Building a prototype
All stakeholders, who are dealing with a prototype, must understand it’s a prototype. Prototypes are often quickly put together without thinking much of modularity or performance at all. If the prototype is built in this way, it’s better to throw it away after prototyping phase. The final product should be designed based on the found solutions during the prototyping phase.
Building “too good prototype” may look and feel final, but usually there is still a long way to go before reaching all the functionality and the final product quality. Unfortunately, also a “bad prototype” may end up as a base of a real product too.
If the team is very experienced, the prototype quality might be better than some other team’s final product. Or some parts of it can be used as building blocks when the final product development starts. Even in this case, there usually is some work to do such as unit tests need to be implemented, code may not follow coding guidelines or code needs to be reviewed before it can be moved or merged to the correct code repository.
Internal quality, Internal UX

Internal and external quality is a topic which isn’t talked too much. Usually the internal quality of the prototype is not very high. Prototype might not be scalable or it doesn’t have a modular design. These sort of decisions effect to an external quality — end user may have a bad user experience because the product is not internally robust, has bugs, isn’t responsive or because of other problems.
Internal UX, is about how developers experience working with a product. Badly designed software is difficult to maintain, fixing a simple bug may require way too much work, complex implementations are difficult to understand and so forth. These decisions have direct effect to the external quality and UX. This is one of the biggest reasons, why a prototype should be ditched after it’s done.
How to avoid these pitfalls?
Like I mentioned, I’ve seen products which have evolved from a prototype to a product in-not-planned-way and it’s always pain in the ass to make things right after that. So here are four guidelines how to avoid that situation.
1 Make a plan and a schedule. Schedule time for a prototype, schedule time for planning, schedule time for a design and schedule time for the final product. If everything is planned and scheduled, the target should be clear for eveyrone.
2Clear communication! Make sure all stakeholders know what a prototype is and how to continue after prototyping phase.
3 Do prototyping only using UI mockups to test the UX, UI design or a concept. Use a tool like InVision, Principle, Easee or what ever tool you think is appropriate as long as people who are trying the prototype understand it’s not the final product.
4 Don’t let sales people to show the prototype for clients. If they do, make sure they (sales team and a client) understand it’s a prototype and it can’t be used as a product. Also make sure they understand how big effort it takes to implement the real product.
Prototyping raises mixed feelings for me. When it’s done right, it’s a powerful tool to test ideas and functionality and it might lead to a great product. When it’s done wrong, it’s a damn expensive exercise just because people didn’t wake up early enough to say:
We need to throw the prototype away and start building the real product!
If this post wakes up even one person who can stop a prototype to become a base for a real product, I’m more than happy. It is also good to highlight that fixing the product afterwards takes much more time and is also an expensive road to choose.
In these cases I’d say the problem is in a company itself — how work is planned and how management, sales or R&D works. Essentially it is a problem in communication. If you recognise this situation, it’s time to stand up and fix the problem now, before it’s too late!
Thanks for reading my blog.

