jump to navigation

the wrong ways you talk to your web guys August 27, 2009

Posted by That Guy in Experiences, Seen Elsewhere, Technology Trouble.
Tags: , , , , , , , ,
trackback

I really need to stop reading Smashing Magazine because every time I do I find more things that my company refuses to get right. Today it’s communicating with developers.

As a designer, you don’t need to have every single page thought out before starting development, but it is helpful to stay ahead of the developers. Plan your features accordingly, and make sure you at least have some type of structure (HTML, etc) ready to go when they need it. It is a lot easier for developers to come through on a polished page and insert data where it is needed instead of creating the page from scratch and having the designer come in after them.

It’s more likely that the marketing department will come to you with a vague drawing born of a brainstorming session, and said drawing will be full of features that you can’t provide because either they don’t exist or because your company is so enamored of its walled garden that you’re not allowed to use that new technology. And they won’t give you a full design, either; they’ll give you some chunks of artwork and hope you can get it to work. Oh, and if you don’t use their fonts, they’ll bitch until you build a ton of tiny JPEGs full of font (that you’ll then have to change 60 or 70 times apiece) because that font is the linchpin — the linchpin — of the project.

It is also important to try not to change the design while the developers is in the middle of developing that specific feature. […] As designers, we should try to avoid any type of refactoring of the UI as we can. It is tedious work for developers to go back and change HTML.

Changing a few things here and there is acceptable. Changing the entire focus of the project? Not so much.

It is also important to not drop off the project here. At the least, be available by e-mail so the developers can contact you about issues with your designs. Respond quickly to ensure your developers are staying on track with the final product. Once again, be decisive in your communication. Most of the time, the real data doesn’t match what you mocked up, and there are many issues you will need to work out in conjunction with your developer.

Let’s repeat that part:

Most of the time, the real data doesn’t match what you mocked up.

Learn this, marketing departments. Learn it and remember it.

Avoid Feature Creep

I’ve got a whole post on this that I’m in the middle of writing.

As designers, we can quickly turn around designs in a few days and be done with it. Unfortunately, this is not the case for development. The ratio of design to development hours is not even close to 1:1. Make sure your deadlines allow enough time for the developer to implement the features, as well as any back and forth time for questions.

What is born of a series of meetings usually ends up being coded over the course of two weeks, with the lion’s share being done furiously at the last minute because someone — or, more likely, several someones across multiple departments — didn’t bother to get their deliverables in on time. Of course, it’s the web guy who always gets in trouble when this happens.

Don’t rely on your developers to write perfect code, as it will never happen. You can’t always rely on developers to test their code to make sure it functions properly, fulfills requirements and ultimately works in the manner you described. But remember, developers don’t write buggy code on purpose.

As fewer people are doing more with less, it’s become virtually impossible to get anyone to proofread your stuff. You can show it to people and they’ll say “oh, that’s great, that’s perfect”, but they won’t proofread. They won’t take an hour or two to read all the text, check your spelling, and click every button. (That’s what interns are for, if you’re lucky enough to have them.) In the old days, my boss used to want me to send him everything so he could proofread and check it. Of course, he never did, and then it became my fault when something was wrong. If companies can’t be bothered to have someone make time for quality control, then why are we developers trying so hard in the first place? We’re just going to get in trouble for every single mistake we made trying to get the project done on an impossible deadline.

In an ideal world, none of this would happen. But we’ll never have an ideal world, so let’s just try to educate our bosses on the right way to talk to us. If we’re lucky, we won’t get fired for it.

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to FurlAdd to Newsvine

Advertisements

Comments»

No comments yet — be the first.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: