William Yarbrough

All too often, as developers we’re struck with changes. It’s much harder on designers (everyone has had a single creative thought once, so people often try to wrestle design from the professionals), but it still impacts developers when changes are made after the site’s been coded, the information architecture’s been signed off on, and the design is finished. I’m going to discuss a few ways to handle each.

INFORMATION ARCHITECTURE

Why do we fuss and preen over this stuff? Because it works. A recent A List Apart article by Keith LaFerriere details why we need to educate the client on IA, it’s place in the construction of their Web project, and what it does for them down the road. Bringing the client in at this stage allows them to see what the shape and functions of the site will be ahead of time.

This doesn’t mean we sacrifice flexibility of the project – we all know change is good – but it allows the flexibility to be controlled: the sitemap needs to be changed and re-signed every time a change is encountered, navigation schema is signed off on once taxonomy and site map are decided, etc. We use this framework to teach the client why it’s important. One of my favorite Creative Directors put it this way: “You don’t do design without a plan. It won’t matter how pretty, how amazing and flashy your site is; without a clear navigation and structure to your content (one that your users will enjoy using and find intuitive) your site will always fail.” I like that way of thinking, it puts the client in a frame of mind that A comes before B comes before C, even if all they understand is C.

DESIGN CHANGES

Let’s face it – design changes suck. Knowing that, these are most common, but often easiest to quench. Because every client’s a junior designer, they all want little tweaks. It’s important as a designer and developer that the client understand that every comp and wireframe is its own entity: every piece of that comp works with every other piece of that comp to make a working model. I know tons of creatives and they all say the same thing: don’t change the design, don’t tweak anything. Tell them what the root problem is and they’ll find the best solution. Often times clients want to make changes because things present deeper problems. Why did the client change the color? If it was hard to read, then there might be a better solution than the awful crap they did.

Because changes will and do happen, what is to be done? If the changes are page level, sure (barring a design destroying idea) it’s not too bad. A template level change is much worse – we’re looking at much larger, time consuming changes. Education, again, is the best medicine. Ask why a client likes or does not like an element. Explain why you made the design choices you did. It’s a shame that many designers must justify their designs, but there are a lot more people who don’t get it than do.

INTERNAL ISSUES

This is what the clients never see. This is the changes that get made in house. These are many times beneficial to making a great product go live, but often times the team cannot get a party line, cannot get with the whole program. In these times it’s best to follow workflow protocol. When good workflows are put in place this step rarely gets bogged down. Being as buttoned-down as possible internally with reflect on the work you do for the client as well as the perception of the group in the marketplace. Keep a consistent workflow and procedure in place and this will be the least of your worries when it comes time to change.