Stop Driving Your Developers Crazy

A few weeks ago, I had the pleasure of presenting at Refresh the Triangle with one of Viget's crazy talented web developers, David Eisinger. Our original plan was to get up there and talk about how designers and developers can collaborate effectively, but we're both pretty snarky so somewhere along the way our talk title became "10 Things Designers Do To Piss Developers Off (and vice versa)".

As we battled it out putting slides together and making long lists of things we hated about our web counterparts, I found myself becoming much more aware of my "designer quirks". A few of David's points rang especially true, much to my embarrassment. It's hard for a designer to admit they aren't perfection on a stick.

So what hit home the hardest? Well, for starters...

Designers Break Functionality

David's example was a form that worked but wasn't pretty. After the designer touched it, it was beautiful - and broken. We certainly don't mean to break things, but I know I've done this countless times without realizing it. Sometimes what feels like a simple change to me - like updating a class on an element or making a submit button an image - interferes with scripts that the developers have working behind the scenes.

Fixing it:

The best way around this is to test everything you do after styling, even if you think your change was minor. If you're working on something you know might have Javascript attached to it, communicate with the developers to make sure the changes you're applying won't affect their functionality.

Designer Version Control Is Whack

A sample image from David's slides:

Actual snapshot of a typical folder on my harddrive:

Yep, his example looks pretty familiar. I have tons of revised PSD files lingering on my hard drive taking up space. I even create a folder for each project called "old artwork" where I ferret away all the unused-but-not-useless old files I just can't let go of. My files are named in vague and inconsistent ways. God bless the poor soul that ever has to figure out my "system" should I disappear off the face of the earth one day.

Fixing it:

There's no great way to do version control with big binary files like PSDs. At least, not one that I know of - got any suggestions? Until someone solves that problem, being more consistent with naming would be a good first step. When working on front-end development, though, there are some great version control systems out there that we should embrace. I've been using Git on my latest buildout thanks to our developers, and I've become a believer in the usefulness of version control. Knowing I can always go back should I break something royally eliminates a lot of anxiety

Designers Change Specs Without Thinking

David made a great point with this one. It's something that isn't talked about all that often, at least in designer circles. (Devs are probably ranting amongst themselves plenty!) It's far too easy to add complex functionality to your design without even realizing it... much to the dismay of developers who have to implement your grand ideas. If the design comp has already been shown to a client, the problem is ten times worse.

His example was classic - a (non-Viget) designer created the following snippet in a comp:

The problem? The designer put an "Add to calendar" link in there, which looks harmless enough until you realize that the site does not have a calendar or any notion of a "user" to create a calendar for. That's a pretty big change to the specs for one little link.

Fixing it:

I've been especially aware of this one since hearing from David, and have caught myself doing it on several occasions. When we're designing, our job is to come up with the best possible solution for the client and the users. For this reason, I don't think we should be focusing too hard on implementation when designing a layout - especially considering we don't know what kind of magic the devs can come up with to make something work. What we should do is know the specs inside and out before we jump into Photoshop and start throwing down layers. Being clear on the specs will make it harder to accidentally add a bunch of bells and whistles. It's not wrong to add functionality if it makes sense (and fits the budget) - but knowing what you're asking for is important. That way you can be extra sweet when you show your layout to the developer and point out that "itsy-bitsy little change" you made.

And A Zillion Other Things

I'm pretty sure there are a few developers out there with notebooks full of complaints about designers... which is natural, considering how much differently we look at our work and the world. Designers have their own lists, of course. But a little tension between designers and developers isn't always a bad thing - it helps to push your work to the next level. And at the end of the day, we're all passionate about making a great product which means we do have some common ground.

Don't miss David's thoughts on the talk, and check out our slides on Slideshare to find out what other designer quirks you might want to be careful about. And if you're in the Triangle, be sure to come to our next Refresh meeting!