It’s a confrontation that pre-dates the dawn of time (that would be 00:00 GMT on 1st Jan 1970 to you and me), the constant struggle and battle of wills between the web designer and the web developer. As the web designer creates beautiful sites, the web developer bangs her head against the wall as the designer has told the client that they can easily include some function that is stupidly complex to create.

Or maybe it’s the other way round? The web designer declares he is giving up because once again the web developer has failed to create a certain function in the way it was intended or has ignored part of the design and created their own layout to fit around the programming that they are doing.

Sound familiar? Depending on whether you are a web developer or web designer reading this you are probably agreeing to one of the scenarios! All around the world, right this very moment, you can be sure that web designers and web developers are tearing their hair out and blaming the other person for “putting that stupid design feature in” or “ruining a perfectly good design”.

But does it have to be like that? Can web designers and web developers work together in eternal bliss? Or at least amicably co-exist until the clients have left the office?

At Agriya, we try as hard as possible to make web designers and web developers get along, and here are some of the things we have learned…

1. Familiarity is Key

Our programming teams are made up of designers, developers, CSS coders and QA testers. In as so far as is possible, we ensure that the same teams stick together and are all located together. This not only builds the team bond but also allows each team member to quickly learn the limitations and potentials of web design and web development.

For example, one area that our designers are learning about is the role and capability of AJAX. We don’t need to take up much space for a login form when a simple bit of CSS and / or AJAX will allow a person to click a button and make the login box appear. However, the web developers need to know what the login box will look like or they’ll come up with something themselves!

2. Walk a Mile in Your Shoes

Although we don’t expect our designers to be able create layouts in Photoshop or for web designers to start messing around with lines of computer code, we do ensure that there are regular knowledge transfers between the designers and programmers. Every few months the entire company is formed in to teams and asked to create a fictitious project with various other team members acting as the clients. The most recent project was for an eCommerce store selling women’s fashion.

The ‘clients’ (other members of staff) would have to explain what they wanted and how they wanted it and the rest of the team have to work together to build it. By doing this everyone gets to understand not just what each person can and can’t do, but also get to experience how it is to work as a client.

3. Education, Education, Education

We have an internal system a bit like Digg (using our MarkIt software actually) where designers and developers alike are encouraged to share interesting new trends in web design and web development. The staff can then add comments and discuss how new trends and techniques will affect future web design and web development.

With the onset of HTML5 and CSS3, both web designers and web developers in our company are actively discussing how the new technology will change the way they do things. For example recently an article was published on SixRevisions about how to make a gradiented call to action button entirely from CSS3 code. This new way of doing things means that a web designer may have to change the way they do things and provide colour references, or maybe the web developer needs to learn how to find out what HEX colour the designer has used in the Photoshop file.

4. No Contracted, Freelance or Outside Designers

As far as possible we try to handle the design requirements inhouse as we have some highly skilled designers who all understand what can and can’t be done functionality wise. However, occasionally a client will submit a design that they got an outsider to do, which is fine, but we work with the client to understand if functionality should over ride any design or vice versa.

I remember where we worked on one website and the designer had created a title header using some Photoshop blending effects on the text. When our web developers created the website, the title headers were done in plain text which made them look slightly different to the original Photoshop image (they weren’t as smooth and didn’t have a drop shadow). The designer the client used was very upset that we had ‘changed’ the look of his design, but since the text was dynamically generated from the database there was no way the web developers could use an image instead of plain text!

In this case, the outside designer the client used wasn’t aware of the limitations of what you can do with programming.

So in conclusion, we think it is possible for Front End Web Designers and Website Developers to get along. But don’t get us started on what happens if you throw a usability expert in to the mix 😀