25 Jun Prototypes and their salutary effect on customer satisfaction
Regardless of the increasing number of people appreciating agile methodologies of software development (i.e. Scrum), popularity of traditional methodologies (based on detailed documentation, specification of requirements and closed budget) is still significant. When compared to projects managed according to the Scrum methodology, the main disadvantage of traditional methodology is larger likelihood of discrepancies between a customer’s expectations and the final result of a project. Such a situation is highly unwanted especially in questions as meaningful as implementations of the CRM systems.
Luckily, in such cases prototypes and mock-ups come to the rescue. Depending on the level of complexity of a project and a customer’s preferences we can distinguish a large variety of options when it comes to presenting planned functionality of ordered software to its recipient beginning with a simple draft of UI made by an analyst and ending with a proof of concept. In spite of extremely different level of complexity and time needed to produce prototypes of a particular type, their common denominator is their beneficial influence on customer satisfaction.
Speaking about software prototypes made as a part of a project managed with a use of traditional methodologies, a very accurate analogy to the construction industry arises. A situation in which a software is developed based solely on a specification of expectations can be compared to building a skyscraper basing only on guidelines provided by investors who disappear in the moment of the beginning of a construction and show up again when a building is completed. The odds that a skyscraper will meet their expectations is extremely low regardless of how well the job was done by builders and architects. Convergence of a built skyscraper and investors’ expectations would be definitely more likely to occur when investors would have a chance to make reference to a digital visualization of a building or even a scaled model.
Prototypes are equally important when it comes to software development. The larger is the scope of custom functionality implemented within a project the more time is needed to prepare a prototype allowing the customer to confront his expectations with the effects of analysts’ work. Nevertheless, even such a simple thing as a mock-up of user interface allows to diminish the possible discrepancy between customer’s expectations and results of a pre-implementation analysis. For the most demanding customers there is also a possibility of ordering a proof of concept (POC) which is a partly-functioning software allowing a customer to verify planned functionality. It practically does not leave a chance for any understatement. To bring closer the idea of software prototypes, let us take a look at those two extreme options.
Mock-up is basically a set of UI visualizations aiming to present key functionality of the software on specific usage examples without telling about used technology. This sort of a prototype is often called “vertical” because it provides a recipient the possibility to take a look at a particular static image of a system. Mock-ups are especially useful when it comes to defining a navigational structure of a system and logical relations between its elements.
POC, on the other hand, is a much more comprehensive prototype. It provides a customer not only with a possibility of feeling the system but also an overview of technology and processes that will occur in the final product. POC can be also called “horizontal prototype” because its main goal is to present a concept of the software in the widest possible scope. After an approval, proof of concept becomes the most important reference point for the developers team telling them how a system should work. This option of a prototype eliminates nearly every chance of understatement and – in spite of the costs that follow this option – it is often used especially in meaningful and complex projects.
Naturally, there is a broad spectrum of middle ways such as – for example – making shallow modifications in demo versions of existing systems. An important point to note is a fact that a decent prototype makes it drastically easier for a customer to imagine how an ordered software will look and work at the end. Thanks to that, projects managed with traditional methodologies does not have to stand out from Scrum-based projects in the area of customer satisfaction.
