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!
You can use Adobe Version Cue for PSD version control. You can even go back to old versions of a document and set it as the current version if needed. Adobe Bridge handles organizing and viewing the files.
Adobe Version Cue, is/was an amazing versioning resource… Until CS4. Now it is more like a hard drive “Adobe Drive” (+) but viewing versions is a little more vague and non-intuitive (-) .
With that said, it is still a very nice tool for versioning with all Adobe files.
It delights me to no end to learn other designers name their files in the most ridiculous way, and also use _final_final_final as a naming convention. It also tickled me to learn someone else out there names their folders
OLD CRAP
Thank you for confirming I am normal after all.
Love the site!
Mindy,
Great post! I’ve recommended it to our project managers, who are the connection between our clients, agency partners, developers, and designers. You can imagine that if it’s possible for our in-house designer to accidentally imply functionality that is out of scope in his design, it’s very possible for this to happen when our agency partners are providing the design. One of our fixes has been to try to provide a better education to our agency partners as to how we actually implement their web designs (many of them have print backgrounds). I even wrote a newsletter about this last month called Designing for the Web Today.
- Chris
Good stuff from both of you. I have an education in software development, but I’ve always been into the visual arts, and considered going to school for graphic design instead of computer science for a while. I ended up choosing to finish the tech stuff and work on Flash projects because it’s a good combination of both. For personal projects, I often pick up the design work as well as development work. What’s most interesting to me is that my behaviors tend to skew towards the task I’m doing. For instance, my design stuff doesn’t go into any sort of version control system. I throw concept art into an Archive (OLD CRAP) folder, and it sits there in case I need one of my seemingly great and unused ideas again.
So how is Git working out for you? We are hosting more of our projects at work on GitHub, but have been hesitant to move the designers over. They are most comfortable using Subversion GUI clients. Have you found the command line to be usable or do you know of a good Git GUI client that you could recommend?
You and David did a great job on this topic!
Why have I never checked out Version Cue? I’ll have to look at that. I use Bridge for browsing a lot - not so much for tagging things with meta data, although I see how it can be useful.
Jeremy, as for Git I plan to write a post about it on Inspire in the next few weeks. I’ve really enjoyed using it on my latest project - so much so that I did an internal presentation for the design team on how cool it is. I also posted an intro for designers at Web Designer Depot: http://www.webdesignerdepot.com/2009/03/intro-to-git-for-web-designers/ In the article I explain my combo method of using GitX with Terminal (Mac). I’m getting much more comfortable with the command line which is a good sign - I’m not a super technical designer, so if I can do it they can too!
Mindy, thanks for the link! I’m glad to hear that it’s been working out well for you. Definitely looking forward to the upcoming post. Always looking for ways to help the designers and developers I work with get along better.
At the company I work for, I’m the designer almost all the time and the developer more and more often, so I’m fortunate that I usually have the ability to keep my development process in mind while creating a design.
I fully understand the frustration of a missed spec, as one small detail being missed or added after the fact can seriously blow the scale of a project out of proportion. The problem I see most in my job is when the design/development team is let down by a slip like this by the administrative/communications team. Using Basecamp to collaborate has been one of the best choices our company has made, especially since we work remotely from our own homes 90% of the time. Missed specs are much less common now.
As far as version control of PSD/AI/SWF/etc. files goes,Version Cue is definitely a solid solution. It took a little getting used to for me as I used to keep about the same kind of organization mentioned in the article, but I’m really glad I adjusted to it. I see some people have mentioned it above, and I would highly recommend using Version Cue with Bridge. Definitely better than having folders called “OLD CRAP” or filenames like “final_final_final”.
Great post!
This really touches on exactly the sort of stress I was going through today (as a developer).
‘10 Things Designers Do To Piss Developers Off’
So very true! I’ve always leaned on the side of sending lots of chocolate to my developer. It works.
(my post, linked above, talks about this very same thing)
When they design divs with rounded corners on top of a complex background.
When they make layouts that compromise content quality (like an element that is designed with a fixed vertical height, but the content can be anything, meaning you have to deal with the decision of trying to cut off with “...” at the right place, or add a scrollbar, or cut off the content entirely…
When they design a complex module or page that can only be achieved through a whole bunch of nested, floated divs and added markup to the layout, and have dynamic content, and shift dynamically with the content because it would break the design otherwise.
Haha. Let it out Andy!
I suppose it’s been rather fortunate that I’ve been designing for Expression Engine for a while. Not that there’s major development in that, but it has given me an idea of some of the limitations I need to remember when laying out a design.
I would also second Version Cue. I’m using CS4 and it’s the best (for now) that I can find. The admin side of it also allows you to create, schedule, and restore backups. (Actually, not sure on the schedule part.)
I happen to like the new Adobe Drive in CS4, so you can navigate your project files without opening bridge.
Some things still seem a little weird when checking in/out files, but it keeps me organized and versioned. Very easy to go back to another version. Seems a little much that you have to run a server on your local machine when using it just for yourself. I kind of wish there was a lighter way to version control that didn’t use as many system resources. Bridge is kind of a hog too.
Good article.
Also, something we’ve run into with web design/development projects:
Incompatible javascript libraries. For instance, ModX wants JQuery but you build your front end using something else.
Incredible. I’ve spent a little time on both the design and developer side of this fence and had to laugh at several points made by both Mindy and David.
It’s kind of funny, though--one of our old PHP developers was just as bad at versioning as anyone. Here’s a sample from a web directory:
grid-pageBAK.php
grid-page-old.php
grid-page.php
Both of your articles are a nice insight.
As a printer, I’ve been evangelizing against the use of ‘final’. There is no final. The printed piece is final. A number before the .psd is the best solution. The corrected file would read Myfile2.psd
The small bit of web work that I’ve done makes this system more nebulous (but perhaps more important), as some sites are just never final. So what do you folks do for constantly evolving sites? how do you track the changes?
nice work here.
-mat
Mat,
To answer your question about version control for web work - on the design side we keep a master repository of PSDs for all client work, including any updates. Designers regularly back up their work on a central server so anyone can access those files should they need them.
On the markup/code side, unless we’re building the site in EE everything is usually in a version control system. Like you said, things are constantly evolving and it pays to keep a revision history in case you need to roll back to a previous version.
EE has it’s own (somewhat limited) built-in revision history, but I always keep my markup templates backed up locally as well.
Nothing worse then designers who do not really understand how a browser works or how HTML functions. Creating a static print design is one different then a dynamic ever change web site.
Whenever I meet with the creative team, I leave the meeting shacking my head.
Hey David
I hope you read the companion article to this one about the things developers do to infuriate designers.
There is responsibility on both sides to, if not know exactly what the other has to go through, then at least to see there are challenges in both positions.
It sounds like you have an excellent opportunity to run some quickie workshops/seminars for your designers about the basics of browser operation and HTML function. Maybe even team up with a friendly face from the other side.
You are, after all, creating something together, so you’re part of the creative team.
-mat
The #1 that pisses me off is similar to the spec change not anticipating that the page you’re designing may not be as long as you’ve designed or that it might be shorter or that the font-size you’ve designed mightn’t be the same on someone’s else machine.
Basically not anticipating that you’re designing a fluid and dynamic screen, not a static and “finished” product.
My biggest gripe would be when you get designs with fixed heights, especially if it’s a site with a lot of variable content.
Print/graphic designer are so used to fixed dimensions, it really takes them out of their comfort zone when you tell them there aren’t any :)
Really had to laugh at the “add to calendar” button, can’t recall the number of times I had comps delivered with buttons for functionality no one knew even existed!
Hey, when do us designers get to help collate our top 10? And can it be 50?
Being a designer and developer I will design a website and most of the time I will develop it. When designing a website and knowing that I will be developing it, I will make sure that everything I include in the design I can do when I develop it or I will do some research and see if I can find out how to do it.
I guess the real question is: are designers disorganized, or do they just make DIFFERENT sense than Developers?
Sure, I also do the whole final-final-final4 convention, but that’s usually in relation to me having made a final, handing it off, and somebody requesting changes be made to the final.
Much like websites, if our documents have embedded files, changing names breaks our files and it’s easier to append an extra ‘final’ on there than go into all the old files and update links every time we need to save a newest one.
Now, my big question is this: although it looks like chaos to a dev, do other designers inherently understand it? I looked at the article, and the comments, and the conclusion I got is that designers speak a different, yet unified language, and developers speak another unified yet different language. Yes, I understand both and I’ve worked alongside both types for a long time. I lean more towards designer, but I understand the merit of the dev language.
Maybe it would be nice to see devs make a move towards understanding and ‘reading’ designer-speak and we can meet somewhere in the middle from now on, okay?
Next entry: jQuery + Type + You.
Previous entry: A Graphic Look at SXSWi 2009
Recent Comments
Maybe you should update the post mindy; not ebody reads the comments.
- Ionut Popa on 'Genius Ways To Use Photoshop Smart Objects'.
- mindy on 'Genius Ways To Use Photoshop Smart Objects'.
- Erik Wallace on 'Genius Ways To Use Photoshop Smart Objects'.
Subscribe to Comments RSS