In a previous blog post I have tried to pinpoint the evolution from data, to information, to knowledge. There are many parallels to be drawn between the way knowledge evolves and how an Online User Experience gets optimised. Both do not hold an absolute truth, but aim to anticipate to an ever changing environment (or user requirements).
The concept of falsification also applies to software development. Agile development (Extreme Programming, scrum,…) entails one simple rule of thumb: we shall prototype!
In many ways this is similar to a draft piece of information that seeks to be challenged. In its essence prototypes demonstrates a concept. A virtual solution for a defined objective. The prototype is never finished but suitable for a specific audience as an intermediate step of development. Prototypes become candidates and in turn these become published as beta versions.
Google has embraced the approach of releasing beta versions of their services to the wider public. In fact, in the their first decade it was considered a privilege to test a Google product. People lined up to test gmail, google maps and google wave. Google had to control the influx via invite-only policies. Participation was never as hip.
The beauty of software is that it can be distributed, enhanced and updated at practically no extra cost. This would not be possible with hardware. It enabled a unique element to the supplier-customer relationship. Customers can be introduced to products and services free of any charge or commitment. The so called beta-phase of new products facilitates an environment where the currencies are usability and feedback. It is a market where suppliers offer a prototype and give users the opportunity to test their (immature) product. In exchange for their feedback the product is free of charge, hereby enabling future releases to follow each other up relatively quickly. Products are co-designed between supplier and beta-user to fit both their needs more closely then ever.
Iterative development explained
Building a software application alliteratively is similar to building a car. Traditionally software (particularly applications) was build in a ‘waterfall’ approach, characterised by five distinct phases:
- requirements capturing
- design
- build
- test
- run
In the car analogy this would mean that the future house owner explains to the architect what kind of house they would like. The architect would verify his understanding with a number of basic questions like, how many people will be living in the house or how many cars would the garage need to cater for.
So far, so good. Once these basic requirements have been clarified the designer will move on to more detailed questions or even make a number of assumptions on the future car owner his behalf. Two seats of 5 seats? A sedan or hatchback? All the way down to details like the colour of the car. As the questions get more detailed the owner might lose the imaginary insights to make informed decisions. He might want to get familiar with the size of the engine before he decides on the type of tires. Making these detailed decisions in the earliest phase of the project is likely to be too much of an ask.
As a result the ultimate delivery of the project might not live up to the owner his expectations, simply because he could not imagine all the detail he was asked to decide on in the design phase. Or even worse, the designer making assumptions that prove to be against what the owner wished for.
Below a typical waterfall phased approach where the end result is the first ‘functional’ product that a user can actually experience.
Projects as complicated as a car or an intricate internet portal leave too much room to assumption in the design phase for the simple reason of the ‘imaginary limit’ of both the designers and the future users.
This is where iterative development comes in. Let’s revisit the house analogy and break the delivery up in a number of phases as we have done in the initial example.
We begin, as in the initial example, with the requirements capturing phase. The designer will ask the basic questions to base his high level design on. Objectives like getting from A to B, and leisure use rather than commuting are important.
Subsequently the manufacturer will step in and create the first prototypes. And, importantly, nothing more then this. Prototypes are not the first stage of the final product, but rather a vehicle to elicit the user’s needs. By a process of continues evaluation the user is involved from the early experiments until the final product. Such a product might start with a ‘lab experiment’. In our car analogy this might be a skateboard or bicycle that shows the way the user engages with the prototype. As the user will insist on more detail (e.g. making if motorised and speedy) the prototype will evolve. Specific requirements, like feeling the wind through your hair, that might never have surfaced in a traditional process, will determine the end-state of a product that is truly used and loved by customers.
Because there is a minimum level of incremental investment at every stage, changes (even changes of mind) can be easily worked into the plan at relative low cost.
In a similar way this is true for software development. Requestors, future users even designers and developers find it difficult to envisage a future product straight from the drawing board. That is why the design is, like with the car, split in several levels of detail. The first prototype (playing) will define the high level scope. From there on every iteration will go through a repetition of phases.
In short,
Iteration 1:
- The definition of the objective
- defining a high level need in the market and the definition of ‘success’
- Capturing the high level requirement
- what does the blue sky solution look like
- Feasibility
- inventory on constraints and limits
- Scoping
- Set the boundaries of the project and verify if the user objectives are met by the design
- Build
- Build the high level specifications into a (clickable) prototype
- Prototype and test
- verify if the user objective is met by the high level functionality (no eye-candy required)
- Feedback
- Ask direct feedback on prototype and user expectations
- Incorporate feedback in low level design
- tweak the current prototype or move on to lower level design of the next phase
- Iterate
- move on to the following iteration
Iteration 2:
- Capturing lower level requirement
- Scoping
- Build
- Prototype and test
- Feedback
- Re-iterate
Iteration x: …
Developing alliteratively, whereby the requestor is continuously involved, does not only keep the cost of rework down, it increases user satisfaction substantially and even allows for changing insights during development. The latter is of more and more importance in an accelerating world of contextual eCommerce and pro-active support capabilities where big projects can span for 12 to 18 months before final delivery. An iterative approach will keep the requestor engaged and the ultimate delivery fit for purpose.
The Minimum Delightful Product
It is tempting to develop your entire wish list of features before going public. From experience we see that the quality of individual features suffers under the pressure of time and cost. Besides that, as the example of the car has shown us, new ‘undiscovered’ requirements do not surface early enough to swiftly find its way in the design.
Alternatively an MVP (minimum viable product) is developed first so it can be exposed functionally to a friendly audience and incorporate their feedback incrementally until each feature truly excites and delights your users with an optimal quality.
