How to avoid prototyping pitfalls and maximize results
Lately we receive a lot of requests for developing a prototype for online financial services. We notice that there seem to be many different understandings of what a prototype is, resulting in a lack of focus.
In this blog we address the most common pitfalls and give you tips on how to maximize the result of your prototype.
It is unclear what a prototype is
It is not surprising that there are multiple views on what a prototype is. There are, after all, multiple purposes for which you could use a prototype. This however, emphasizes the importance of making choices of what to develop in a prototype.
The first question to ask yourself is what you will be testing. An example could be to test the look and feel of an online financial service. We see this often being used for convincing internal stakeholders. Such a prototype focuses on visual characteristics of a product or service and less on functionalities. Another example of what you could test with a prototype is user experience. An example is testing a client onboarding flow. Such a prototype focuses on interaction with end users.
Tip: Formulate clearly what you want to test with the prototype. This allows you to focus on what needs to be developed to facilitate this.
It is made too complex
A prototype is not the same as the final product. Though this sounds obvious, we notice that people often think of the final product in terms of business logic when defining what should be in a prototype. The result is that functionalities are defined in detail and are expected to function as such in the prototype.
An example is showing a cost overview of a financial transaction. The final product will of course have certain business logic that calculates the correct cost amount based on variables. In the prototype however, a set of static data might be sufficient for testing the transaction flow. Using static data instead of business logic reduced complexity and development time.
Tip: Constantly ask yourself whether the prototype requires business logic or not. In many cases it is sufficient to use static data.
No time to iterate
The strength of a prototype lies in iterating on test results and feedback to improve the prototype. You get feedback early on that allows you to adjust when necessary. An additional benefit is that processing feedback in an early stage generally has less impact than making changes at a later stage.
We see that budget often is sufficient for developing a prototype, but does not allow for iterations.
Just as important is it to remember to validate the results of an iteration. Once you have test results and improved the prototype based on these results, you need to validate whether the improvements indeed made the prototype better. The whole idea is to move away from assumptions.
Tip: Reserve budget for iterations based on test results and feedback, not only for developing the prototype.
Prototype code is used for the final product
It is tempting to continue developing on the code of a prototype. A lot has been thought of already, some pages are online and buttons seem to work. Though it seems efficient to use the prototype code, often it is not.
The reasons for this are that the prototype code most often is not optimized and does not meet final security and quality standards. Examples are an online prototype where not all browsers are supported, where no validation on data entry is being made or where interaction is hardcoded instead of dynamic based on variables. Though this is fine for the prototype, it is not something to go live with.
Generally speaking, a prototype must be developed in a short period of time and has specific goals. This results in developers having to take short-cuts, which is fine when developing a prototype. In our experience it is often faster and more effective to develop new code than to iterate on prototype code.
Tip: Write down test results and formulate points for improvements when developing the final product. Ignore the prototype and start fresh.
Each prototype is unique and serves its own purpose. Nevertheless, there are lessons to be learned from past experiences. By using the tips above, you ensure that you can achieve max result with your prototype with less effort.