Rapid Prototyping is being able to quickly provide a proof of concept solution to a problem. It is not developing a fully-featured, production-ready application. Rapid prototypes may only provide one function or only a partial solution and are often needed in a short timeframe.
Rapid prototyping is best for situations that need solutions based on a short schedule or where a fast fail is preferred. Why would someone want to fail fast? If the solution does not meet the needs of the user, then failing fast, allows for a quick change of direction and refocus of resources on a different solution, which might prove to be more useful. Another reason to fail fast is if you are unsure if something is possible. Maybe an API doesn’t provide the data you need and a quick prototype that pulls from the API will tell you that so you can look at other options.
When the requirements are not clear, or the environment will lead to rapidly changing requirements or direction. If the customer is not quite sure what they are looking for in a solution, providing them with a quick prototype will help identify what works or not, which will then help with identifying requirement details and priorities. Perhaps you are working in a cyber field, where adversaries change tactics often. You’ll need quick solutions often if you want to stay ahead of them.
Prototypes are also very useful when the system will have a lot of user interaction. Developing using evolutionary prototypes will allow for feedback on ease of use or correction of requirement details at each iterative delivery. Eventually, you’ll have a good idea of the full scope of requirements and needs of the customer which can then be documented and handed over to a production application development team.
We choose Rapid Prototyping for several reasons. As mentioned above, one of the reasons would be a short deadline. A solution is needed quickly, or any solution delivered after the deadline will be OBE. Other times it makes sense to use Rapid Prototyping include:
To be clear, none of these prototypes are production-worthy solutions. At best when we mention a complete solution, we’ve identified all the requirements and have proved the solution, which is now ready to be given to a production team.
Rapid prototyping should be done in a sandboxed or development environment. Since these types of prototypes do not go through thorough testing and are often throw away scripts to test feasibility, they should not be used in a production environment. Depending on the needs of your prototype and the permissions you have, you may even decide to prototype on your local machine.
While you should prototype in a non-production environment, you should still know the limitations or availability of resources on the production system to ensure you are prototyping something that will be useful and provide accurate proof of concept/feasibility. Such as does the system the final product will be run on having the same accesses as the system you are prototyping on. If the systems are on different non-connected networks, then access to specific data or an API may not be available on the other network and therefore your prototype may not prove feasibility for your customer.
When requirements first come in from the customer and it has been determined a Rapid Prototype is the best solution, work with the customer to prioritize the features. Determine which features are must-haves and based on the customer’s requirement schedule, scope the prototype so the highest priority features can be delivered on schedule. As the schedule allows, build, demo, and incorporate feedback to add additional features.
There may be cases where you are developing a prototype and making a well thought out assumption will enable you to demo a feature quicker than verifying details with a customer. Due to working closely with the customer, knowing the environment and the fast build, demo, feedback loop you have established, go ahead and make assumptions, you will soon have a chance for the customer to verify your solution.
Prototypes don’t need to be pretty; they need to be functional. They should be user friendly and not require intensive training or large manuals. Functional may mean different things during different development stages of your prototype. For example, when doing extreme prototyping, a static HTML website can still be functional in that it is demonstrating relationships and flows between pages and layouts.
You also should not skip over security when prototyping. While it seems like adding in security will add to your timeline, and it will, it’s also very important to ensure data remains secure and access is not given to those who don’t have a need to know.
Prototypes often have short deadlines or are being developed against a high level or generalized requirements. Be prepared for requirements or priorities to change and be okay with stopping development mid prototype development and switch to a new priority. Dropping one prototype doesn’t mean your work wasn’t important, just means the customer has new higher priorities that need to be worked.
In part two, of our three-part rapid prototyping series, we’ll look at “How to Become a Rapid Prototyper.” Being able to rapidly prototype solutions means being knowledgeable across several technology areas, remaining flexible, and being able to learn new technologies quickly. These skills will allow you to choose the best approach to the solution.