Stop Pissing Off Your Designers

David Eisinger, Development Director

Article Category: #Code

Posted on

A few weeks ago, our local Refresh group pitted me (representing web developers) against Viget designer Mindy in a battle for the ages. Our talk, “Ten Things Designers Do That Piss Developers Off (and Vice Versa),” offered a back-and-forth look at some of the issues that crop up between web professionals. Despite the overwhelming strength of my arguments, I won’t deny that she got some good shots in. Here are some of the key lessons I took away.

Stay off the bandwagon

One of Mindy’s best points was the tendency of developers, when selecting technologies to use on a project, to go with what’s new and hip rather than what’s the best fit or what will yield the best final result. I think we can all relate to learning a new technology or technique and then wanting to immediately apply it to whatever we’re working on.

Technology bandwagon-jumping goes hand-in-hand with another common problem: over-engineering. In my experience, when a chosen technology is a bad fit for a project, it’s typically because it’s too powerful. An over-engineered solution is a nightmare for the next developer — in a past life, I maintained a Spring-powered, Lucene-searchable monstrosity running on dedicated hardware that would have been better served with a WordPress install on Dreamhost.

When selecting technologies, stick with the best fit, whether that’s what you know best or what will lead to the best final product. If you’re just dying to try out some new technology, do what I do: redo your personal site (in lieu of actually posting any new content to it).

Avoid the knee-jerk “No”

Picture this: you’re sitting at your desk one morning, happily reading Hacker News, when an IM window pops up on your screen. It’s your PM, and she’s got a new feature request from the client. It’s not a major change, but it will involve a substantial overhaul of the messaging system you built. What’s your response? Be honest — you give her seventeen reasons why the requested change is a bad idea.

When discussing feature requests, keep in mind that the ultimate goal is to create the best product possible. Requirements change, and though it sucks to complicate elegant solutions, sometimes change is necessary. As an added benefit, if you avoid staying “no” instinctively, when a truly bad idea lands on your plate, your objections will carry a lot more weight.

Remember: you are not the user

Mindy noted a trait common to many developers: a lack of empathy for the user, or rather, the mistaken idea that we ourselves are the typical user. In other words, developers are prone to creating features that they would want to use, regardless of how well they might serve the actual audience of the site.

When deciding on geeky features, it’s important to keep your audience in mind. If you’re designing a site about web productivity, by all means, go nuts — bookmarklets, keyboard shortcuts, customizable RSS feeds, the whole nine yards. But if your site’s intended audience is, say, gardening enthusiasts, your time would probably be better spent elsewhere.

But in the end

We all want to create the best web sites possible. Disagreements arise about definitions of “best”; while a designer wants a site that’s attractive and intuitive, the developer wants one that is stable and maintainable. In the end, these qualities aren’t mutually exclusive — the highest-quality websites have them all.

Mindy has posted her thoughts on the talk, and our slides are available on SlideShare. And if you’re in Durham (or lesser nearby cities), come on out to the next Refresh meeting.

David Eisinger

David is Viget's managing development director. From our Durham, NC, office, he builds high-quality, forward-thinking software for PUMA, the World Wildlife Fund, NFLPA, and many others.

More articles by David

Related Articles