Changing Designs Mid-Project

Can it also come in firetruck-red?

It's a common and often inescapable event—the developer is halfway through building the product, when the client/designer says "actually, could you change it to this instead?"

If the change is massive, the answer is clear.

Massive Change Example

• [Client] "Instead of a blog about poodles, can I have a kind of game where you feed poodles and teach them new tricks?"
• [Developer] "No, my contract is to make you a blog for X amount of dollars. If you want something else, we need to make a new contract with a new price, new product, new deadlines."

The problem, however, lies in the small changes. It's the little things, the things that "shouldn't be too hard, just a minor patch."

Minor Change Example

• [Client] "Hey, I decided to change the button graphics, so each button looks like a poodle's face, is that ok?"
• [Developer] "Sure, I'll just swap the images out"
• [Client] "Great! Oh also, you know that fancy loading animation, the one with the dog chasing the cat? I don't need that anymore..."
• [Developer] "Oh, ok, I'll take that part out."

These small things are too easy to request—and the developer is often courteous enough to say yes. This encourages more small changes, because it worked so well the previous times. Eventually you have a churn of tasks that ultimately lead the project round in circles.

The True Cost of Change

Here are the problems with changing designs in the middle of a project:

• Time—requesting more work from the developer will increase the time taken, leading to missed deadlines.
• Money—either the developer does more work for free (developer loses money), or the client has to pay more for each change (client loses money).
• Stress—the extra work stresses the developer out. The more changes taking place, the less confidence the client will have in the current designs, stressing the client out. These stresses might be minor, but they can add up.
• Motivation—when the developer has to undo previous work, he is aware of the time and energy wasted. When the developer is asked multiple times, he is very aware of the time and energy wasted. When the client asks him to do a new feature, the developer is hesitant to commit time to something that might be thrown out like the others.

Solution

The ideal solution is that the client spends a bit more effort into getting designs he can commit to, instead of "well, we'll plan ahead this far and see how we can improve it as we go."

However, concrete designs almost never happen—there are always some things that need to change. When this happens, the client should avoid asking for constant small changes, and the developer should avoid saying "yes" to them. Instead, the client should make a note of each little change request. After a month or so, both the client and developer should sit down, look at the list of changes the client has compiled, and think it through.

Putting a month's collection of small changes into one meeting will give perspective on the impact these "small" changes have. Perhaps the result is to update deadlines, or pricing. Perhaps the changes are put into a "2.0" of the product, to be worked on after the release of the original.

A stable, laid-out, seldom-changing design will give confidence to both client and developer. Work can progress without hesitation or second-guessing. Don't think a small change is a minor inconvenience. Fight back. Stand your ground. Give thought to your direction, and march boldly on.