Iterative Design

Iterative design is not just a one man show. It's a see-saw process that will add balance to any project.

Photoshop can only get you so far. Designers have a very good idea of what an end product should be, and create designs based on the assumed end goal. Unfortunately, designs can't cover every base and possible outcome. It just doesn't work out that way. Sorry.

What is “Iterative Design”?

This is where iterative design comes in to play. Like stated above, Photoshop can only take care of a simple line of scenarios. As a developer starts to bring a design to life, he or she should take the time to work with the developer. It’s never a good idea to just send a design document over and let the developer work in the dark. It’s not very nice.

Iterative design is a back and forth process. Functionality comes from design, and design can arise from functionality. In many situations, the developer would remember some very important piece of functionality that was either not written in the spec, or highlighted in a design comp. In any case, it is up to the designer to come up with a solution to complete the steps.

Conversely, a designer might have thought up a very clever answer to a question that was never really asked. Will that element make it into a finished product? Sometimes it does and sometimes it doesn’t. But still, that step is part of the design process.

The Job of the Designer

The designer doesn’t exist just to make pretty pictures and follow orders. If that's the case, then that designer’s abilities are being wasted. A designer has to think not just of the design in hand, but the design in real world situations. How will a site be used? What enhancements can be made to the layout to increase usability for the end user? Is this design actually in line with the client’s ultimate goal, or is it just empty "overdesign"?

Following written orders line by line doesn’t really allow for much independent thought. Now it’s not fair to say that orders are made to be broken in this case, only bent . . . and not in a bad way, either. When you get down to brass tacks, the designer's job is to effectively read between the lines, figure out what the client is really asking for, and come up with a clever solution to reach that goal, but in the same vein keep in the basic layout of the spec.

The Job of the Developer

The developer's job runs parallel to that of a designer's. Sure, the obvious job of the developer is to, well, develop. But in actuality, a large chunk of the developer’s job should be spent keeping the designer in check before, during, and after the actual design process completes within a project.

How? Simple. The developer has to make sure that what the designer has produced falls within the realm of the project goal. Nothing in the design should be unnecessary, unrealistic, or flat-out wrong. The design must both be logical for both the developer (in terms of development time) and client (is this the functionality that was asked for?). If either of these focus points are left out or glossed over, then the project is on the fast track for failure.

For this workflow to be successful, the developer should be working with the designer early on. Multiple meetings should take place, and the designer has to understand what the developer hopes to be building in terms of functionality. With this in mind, development time should be much shorter and the design step should be more linear, with less backtracking, to shoehorn functionality into a design. Take baby steps, Bob.

Teamwork is Key

This usually isn’t the case in large-scale projects, which logically is the best place to use iterative design techniques. Most of the time, the designer designs and passes it down the line to the developer. That’s the only interaction between the two parties. The developer would just start building out the design in code as the designer moves on to the next project.

This is the point where so many designs fail. It may look good in a browser, but it isn’t really helping the client or the end user. With careful planning and teamwork between designers and developers, the rate of success goes through the roof and development time goes down.

It’s a win-win situation, folks. Work quality and efficiency goes way up and the client is better off because of it.