Iterative Evolution
The project is over: designs have been verified, the code has been deployed and everything is published. Now what? Well, of course: we iterate.
Why Keep At It?
When a project is first completed people just want to leave everything and go on holidays. Things are working, more or less, and the promised functionality is here. But very few applications are really successful as they were initially designed. In fact, very few applications are even useful as initially designed.
The reason is our inability as designers to imagine how the real flow of an application is going to work out in practice. The best designs come out of a static application, or at best a mock up thrown together in some wireframe tool. Once things work it is time to optimize: this button is hard to find, this other widget would be more useful on this other place, and so on. And it is not only the external interface: new functionalities will probably come handy to complement the existing ones.
Conversion
Let us take a look at web applications targeted at the general public, where there is a more objective reason: conversion. How many of your users are actually buying anything? How many do register? How many do even get to the second screen? A single conversion is one of your users that becomes a customer. But what if there are hundreds of new users and only a few conversions?
It makes more sense to talk about percentages: if traffic suddenly increases it is reasonable to expect a proportional increase in conversions. So conversion can be measured as the proportion of users that become customers, usually expressed as a percentage. If only ten users reach your site on a given day and two buy something then you have an astounding 20% conversion; but if those two come from a thousand visitors then the conversion is a lousy 0.2%. Conversions to paying customers are usually a few percentage points, say: 1~3%. Anything lower and you have to seriously rethink your strategy or your product; anything higher and you have a serious hit in your hands.
But it is not reasonable to just measure the desired outcome and expect it to grow: each one of the steps required to become a customer should be measured carefully to find out how many of your users make it – and inversely how many are lost in the way. The numbers may scare you. The result is usually presented as a funnel: at each step of the funnel a higher percentage fall out, and at the bottom lie conversions. Leads are an intermediate step: they represent potential customers, and they are an important milestone. Simply put, someone that clicks through an offer is a lead.
Iterative Improvement
Each iteration should be guided by a metric to be improved, and conversion is the perfect fit: if we are doing things right it should improve steadily with every cycle.
Sometimes progress is not so steady: if you keep adding and removing a feature, for example, then you are stuck in a circle. It is important to be on the lookup for these situations and prevent them as fast as possible.
Sometimes asking for quantitative improvement can introduce a certain degree of delay into the process: should you start improving your system before you are measuring? The answer is: yes, of course! Just be sure to be able to collect metrics before the changes are deployed.
The speed of progress depends on just two factors: the duration of the cycles and the span covered in each iteration. Cycles of one week will probably take you there faster than if they take one month, something which sometimes cannot be avoided.
Then there is the question of pure software engineering: how to create requirements, build a design, develop the code and test it in just one week? Or in one month? There are many agile methodologies to choose from; just keep in mind that the goal is not to follow a methodology but to improve on a software system.
Peeling The Onion
How can conversion be improved? Easy: just asking users. But this apparently trivial task can be quite hard to accomplish; people pay specialized firms lots of money to find out what their users want. Focus groups, recorded usability tests, and remote testing are all expensive. Online questionnaires have a negligible response and can actually harm your conversion; not to speak about feedback tabs.
But it can be done. Usability testing can be as easy as asking a few people to use your application and later requesting their opinion. Do not be afraid to ask your coworkers, friends, family and even passers-by. The most visible mistakes and omissions will usually be easy to spot and will require just superficial questioning, while more elaborate problems will be harder to elicit. You have to make sure that testers are motivated; a small prize in return for the effort is usually enough. Also, be sure to receive the feedback in a neutral fashion, or everyone will feel compelled to sugarcoat their responses.
If you want to follow some method there is hallway testing, one of Spolsky’s 12 steps to better code. It is not hard to do: take five random people, give them tasks to do with your application and stay behind them to see what problems they encounter, or what they expect to find and don’t. Take notes of everything, and do not help unless asked. When they have finished, ask people about their experience. Finally digest their suggestions with the development team.
At each iteration some obstacles will be removed, peeling one more layer back. Then new obstacles will appear which were hidden by that layer. Potential users may tell you what problems they had to accomplish their tasks. Even more important is to find out about missing features, but users may find them hard to pinpoint their unfulfilled needs: finding out a solution to a necessity may require a lot of imagination and sometimes creativity. Users will be able to spot these unfulfilled necessities, and that is what you need to listen. Then be sure to provide it!
When to Stop
Not everything can be improved forever: after a number of iterations our efforts will be wasted. How many layers does the onion have? The answer may well be: infinite, there are always details to improve. So let us rephrase the question: how do we know that we have reached the point of diminishing returns?
A lead rate of 17% should be our most immediate objective. That is the percentage of innovators and early adopters combined, and they are very likely to use your applications. But you have to reach the early majority before your application has a significant appeal. Of course not everyone will be converted to a customer; they might not have the money. But at least they should enter your store and browse around.
Perhaps you will not be iterating your designs eternally, but as a practical matter you should always keep improving your website. Even if the conversion rate is good and customers are satisfied: Amazon has not stopped improving their website, and few online shops think that they have already enough customers. The same is valid for any other web applications out there: keep improving, even if you are not iterating every week.