I’m a big fan of the theory behind evolutionary prototyping. It’s particular focus on eliciting correct and consistent requirements lends a particular vigour to the product development lifecycle.

 

Evolutionary prototyping is a lifecycle model in which the system is developed in increments so that it can readily be modified in response to end-user and customer feedback.

– construx.com

An evolutionary prototype will undergo a series of iterations based on user and client feedback, and will eventually become the ‘live’ solution. These differ from throwaway prototypes – a UX mainstay – because, while these prototypes inform product development, they do not become part of the final solution themselves.

With the ongoing clarification of existing requirements, as well as the discovery of previously missing or unknown requirements, the iterative development practice of evolutionary prototyping offers marked benefits: the reduction of waste (code re-use); the early consideration of risk, and; the elimination of requirements creep.

However, the primary advantage of this development approach is that developers get immediate feedback. Therefore, the risk of building the wrong system is greatly reduced, ensuring you’re not just getting the design ‘right’, but also getting the ‘right design’ (Buxton et al, 2006).

Essentially, evolutionary prototyping is a ‘lean’ (build, measure, learn) approach to product development, and, while I’m surprised that it’s not  more widely adopted as a product development process, it’s not too difficult to understand why.

 

Evolutionary Prototyping processEvolutionary Prototyping (imgur.com)

 

This might be down to the fact that much prototyping nowadays takes place as part of the UX function, and most UX designers do not code. By definition, UX prototypes are throwaway and to a certain extent, wasteful.

While great for ideation and early stage research, such prototypes can lead to a lot of head scratching when it comes to developer handover.

The downside to evolutionary prototyping is that they can be difficult to plan and cost. How many iterations will be needed? Also, this approach can lead to a ‘code and fix’ type development pattern, with an end product that works, but not an end product of high quality.

One way the approach can work and be cost effective is to take the lead from more progressive companies, and startups who require ‘lean’ approaches just to survive. These companies promote a UX Designer / UI Developer hybrid function – or UX Engineer – team members who can drive forward the front-end development as part of a user-centred design approach and iterate on an interactive prototype based on UX research and user testing feedback.

 

Facebooktwittergoogle_pluspinterestlinkedinmail
Taking the BS out of design decision-making
Onboarding and Interaction Cost

Leave a Reply