Throwaway Prototyping vs Evolutionary Prototyping

Pavithra Jayasinghe
2 min readJun 15, 2020

--

Welcome back to continue prototyping. Let’s dig more for two types of prototyping.

Throwaway Prototyping

Throwaway prototypes are developed from the initial requirements but they are not used for the final product and not an alternative for written specification of the requirements. It enables quick prototyping and commit to throwing the prototype away. If the users can get quick feedback on their requirements, they may be able to refine the requirements early in the development of the software. Then changes can be done early in the development life cycle.

Throwaway prototype has a short project timeline and easier and faster to develop the interface. This type of prototyping can be used at any time in a project by any of the project’s personnel. Throwaway prototypes actually do nothing, it’s just presentation only for a limited purpose. Soon it will be starting to become a thing of the past. This type of prototyping is not getting used as much now.

Evolutionary Prototyping

Evolutionary Prototyping is considered to be the most fundamental form of prototyping and this prototyping type is also known as breadboard prototyping. The main concept of this prototyping type is to build a robust prototype and constantly improve it. These prototypes are built only with well understood requirements instead of acknowledging all the requirements. It allows developers to add features or make changes that couldn’t be devised during the requirements analyzing and designing. Developers are helped to develop part by part of the system considering the usability aspects and this type of prototypes are delivered a working system to the end user.

Evolutionary Prototypes assist to,

  • Appear new ways to improve the system
  • Increase the chance of having the client satisfied with the working system
  • Use with the requirements which are not defined
  • Deliver the system fast

There are some drawbacks using these prototypes.

  • Require a management
  • Avoid requirement documentation of the system
  • Undetermined design ideas
  • Expensive long term maintenance
  • Loose information during improvement changes

I will be back with the term fidelity with my next post.

Thank You!

--

--

Pavithra Jayasinghe

Business Analyst at Surecore (Pvt) Ltd || Trainee Business Analyst at Mobitel (Pvt) Ltd Sri Lanka