Unexpected Consequences in Iterative Software Design

Since joining BlueGlass, I’ve come into contact with a lot of talented developers and sophisticated products at different stages in their development life cycle. To explore the tech side of our business a little more, I’m going to talk about our approach to the development life cycle. It’s not an approach that we invented, but it’s an important one. That approach is called Iterative Design.

A common belief is that software development happens like something out of the movie ‘Weird Science’. Someone gets a great idea, puts together a big list of requirements (no matter how outrageous), and then after a lot of noise and chaos, the perfect piece of software bursts out of a big mess wearing a halter top and ready for action. Unfortunately, that kind of assembly-line development doesn’t always work. It lacks checks and balances during the “big mess” part, and suffers greatly from the missing feedback that ultimately gives software value to a user.

Working on the Internet, we’ve all heard about great web ideas that were poorly executed or just never came to be. The advice I sometimes hear to get projects going is “Just Do It,” but how? I think the concepts of iterative software design that we use at BlueGlass might help some people get their own web ideas off the ground by starting small and concentrating on the most important part of any project: providing value to the user.

Iterative design is a process of software development that maximizes the benefits of prototyping, design, testing, and creativity. These are all very powerful things and they need to be arranged properly–like drunks at a wedding.

Put them too close together and its a big headache. Too far apart, and one of them might disappear because they don’t get enough attention.

The first phase of any product usually starts with a conversation that goes, “Wouldn’t it be cool if something did this…?”

At BlueGlass (and back at 3DogMedia), we design our biggest products for our most demanding client: ourselves. When we can’t find the right tool for the job, it probably doesn’t exist. And if that piece of software doesn’t exist, it should. Identifying that need powers the rest of this development cycle.

When we comes up with an idea, we let our brainstorming run wild. It’s not important to limit the features or the scope of a project here. We want to see the forest, not the trees, and we want to get a good mental picture of that forest because in the next phase, we’ll be chopping most of it down.

Once we’ve got an idea, the first step is creating a usable, working prototype. This is a big deviation from assembly-line software design and also the most important step.

In every idea, no matter how big, there is one part that can be put into use immediately. Sometimes the prototype is an experiment in the flow of “link juice,” or a content aggregation service. For example, if you consider Facebook the original big picture idea, Twitter would be the prototype phase: a method of broadcasting messages to groups of friends. Even that reduced version of the big picture clearly has value–even if it took me three years to figure out what that was.

With a usable, working prototype, everyone gets a good idea of where the software is heading and major misunderstandings can be rectified at a time when it’s cheapest to make big changes. This prototyping phase also has the invaluable effect of focusing developers on the most important tasks. Spending resources on anything that is not directly serving the original need of the user is a waste of time. The most valuable features of a product should get the most attention and by distilling those into a prototype, we make sure of that.

With a prototype that works in-house, testing begins immediately.

Too often, software design is run like the movie ‘The English Patient‘. It’s really heavy at the end and hard to pay attention to during the rest.

That pushes bugs and usability issues onto the end users–who are paying for it! Having a usable prototype early on creates a built-in testing team: us.

One thing I like to keep in mind when it comes to the testing phase is: a users’ instincts are always right. Anyone who thinks users need to learn how to use new software will find twenty unread manuals in their closet who beg to disagree. An interface should be intuitive. If a user testing a prototype clicks on a button and stares at the monitor as if expecting a result, something should have occurred. It’s up to us to find out what and make it happen during the next phase.

It might seem counter intuitive that a prototype is constructed before any design is done, but consider this, any small misunderstanding in the “idea” phase will be turned into a massive flaw in design. Design flaws are not always easy to correct. Sometimes it means having designed an infrastructure for a feature no one needs. But sometimes a mistake here means a costly redesign later.

During the design phase, we produce a set of milestones for usable prototype products that are tested upon their completion and refined in a continual process of design, prototype, test.

After some initial shyness, I’ve found that test users are as free with their suggestions as Charlie Sheen in front of a crappy webcam. This feedback helps create an interface that is both intuitive and uncluttered. However, while all user suggestions offer value, it’s important to avoid “feature creep,” the gradual

increase of the scope of a project that ultimately results in the delay of a product people can use. By keeping the basic priciple of iterative design in mind: provide maximum additional value with each iteration, we avoid becoming the next ‘Duke Nukem Forever’ (a game that has not come out in a long time even though everyone really wants it to).

Through the repetition of the above cycle: prototype, test, design, we gradually create a stable initial product. The ideal cycle of iterative design looks like a continual release of usable prototypes with a steadily increasing user base that seamlessly grows beyond us. Eventually, we move into the most exciting step of them all…

There have been some questionable interpretations of the Beatles’ song ‘Helter Skelter’, but I think it’s pretty obvious that the lads from Liverpool were singing about iterative software design. Once you get to the bottom, you go back to the top.

With a working version of a product, it’s time to pick a new part of the forest to hack into. By this point, we know more about our users, we know more about the strengths of our software, and maybe most importantly, we know what to improve in our development cycle.

So what are the unexpected consequences of iterative design? With the above methods, user feedback often turns a simple prototype into something much more interesting and valuable than the idea that spawned it. Just look at all the Google properties that came from the 20% time initiative. Look at Facebook. Look at how MySpace is dealing with Facebook.

If you really want a good example of the benefits of iterative design, there is only one product you need to investigate. Largely considered a success, this product has undergone 6,000 years of improvements and user feedback. It has been through so many cycles of design, prototype, and test, that the modern day iteration we are familiar with is completely unrecognizable from the prototype from which it spawned. That product is beer. Happy St. Patrick’s Day!