November 8th, 2006
(Part of a series on Web App Trends. Also see: Users as Developers)
Have you ever noticed that many successful web apps seem to change a lot? The designs are always being retooled, changed, improved, upgraded, tweaked?
This is a trend we’re seeing more and more of. Many teams are changing their development process to speed up iterations. Instead of taking months to roll out a new release, they’re breaking it down into smaller parts and releasing them more often. This helps to reduces risk, the smaller the change the smaller the risk and the easier it is to figure out what is working and what isn’t working. Taken to the extreme it would be science: test one isolated variable at a time and iterate accordingly.
One of our clients recently told us, “the faster we iterate, the faster we learn”. In his view, the quicker they release iterations, the quicker they can improve on them. They call this on-the-job-training, referring to the app as being tested by the actual users while they’re using it, as opposed to traditional pre-release testing.
So how fast can app iterations get? Well, teams are all over the map. Another team we know takes about 4 months to make any change to their web app, even the smallest text tweak. If they want to change a navigation button to read different, it takes 4 months. The levels of corporate hierarchy and business rules simply take that long. Interestingly, the product inventory on their site is updated daily, by a completely different development team! They have fully separated their application framework from the products they’re showing in it.
Most teams are faster, though. Mike Davidson, who founded Newsvine, a social news app, recently wondered if two week iterations were fast or slow. Apparently, for some teams it is dreadfully slow, as they update as fast as they can.
I spoke with a developer of QVC.com at the UI Conference who said they often update their site several times a day. Their promotions practically demand it. One promotion might run out in twelve hours and they have to get it on the site and taking orders as fast as possible. He said they also do extensive A/B testing to see what sorts of promotions work and what ones don’t. But they bypass that slower testing method when they need to get a promotion up quickly.
Iteration for iteration’s sake is probably a bad strategy. But many teams are moving to fast iterations to both learn things faster and sometimes simply because their business rules demand it.
So, how fast are your iterations?
Note: This post grew into an article: The Freedom of Fast Iterations: How Netflix Designs a Winning Web SiteTweet