Why Do Designers and Developers Fight?

About a year ago, Ryan Scherf wrote a really good article for Smashing Magazine, describing to web designers how to effectively work with web developers.

Although Ryan categorically stated that his article “is not meant as a slam on developers”, he did receive quite a few vicious responses (have a quick skim through the comments and you‘ll see what I mean!).

Ryan’s article stuck with me a bit, so I wanted to try to resurrect the issues it confronts and try to put a developer’s spin on it.

Why were people so nasty to Ryan?

Before we get going, I want to say once again that Ryan wrote a really good article and that I think that you should all read it before continuing with this one. However, there are a few points that I think were the cause of some of the more aggressive replies he received.

  • The first picture in the article is the infamous one with the tree swing lying on the ground, suggesting that developers can’t understand business rules/logic.
  • The designer is presented as the person in charge of the project.
  • He doesn’t qualify “Some developers just get it” with any definition of what “It” is.
  • He doesn’t specify what a designer is

However he was BANG ON THE MONEY with the following points;

  • The designer/developer isn’t always the project manager, and the project manager has the potential to stuff up the whole thing.
  • Don’t make promises you can’t keep!

We’re going to leave the project manager out of this and focus purely on the relationship between the designer and developer. The other important thing to note is that the client is not always an external customer. In fact, they can commonly be someone internal to your own company (e.g. “the sales team”). All references to the client from here on in refer to both situations.

What are web designers?

Part of the reason that Ryan received some of the responses he did is because he didn’t define exactly what the differences are between a developer and a designer in terms of skill sets and their expectations of each other. The skills of a designer and a developer overlap considerably more than people seem to think. Although the definitions of “web designer” and “web developer” will vary between individuals and companies, in my experience the following matrix describes the skills required by each discipline in an ideal world:

Web Designer Web Developer
XHTML EXPERT EXPERT
CSS EXPERT WELL VERSED
Jquery/JS WORKING KNOWLEDGE EXPERT
Server side scripting WORKING KNOWLEDGE EXPERT
Programming NO KNOWLEDGE REQUIRED EXPERT
Graphics programs EXPERT WORKING KNOWLEDGE
User experience/Aesthetics EXPERT WORKING KNOWLEDGE
Knowledge of the business model EXPERT EXPERT

In fact, I’ll go a step further and say that (in my opinion) if you are lacking these skills, then you shouldn’t call yourself a web designer/developer until you get them!

Now, we don’t live in an ideal world, and unfortunately due to the various GUI’s / Tools and the interpreted nature of the web, it is actually quite easy to ‘blag it’ as a web designer: “As long as the page looks okay it doesn’t matter what’s behind it” – yes it does matter and poorly coded HTML drives developers and professional web designers nuts.  Everyone has their own opinion of what a web designer should be and this is usually at the heart of any designer/developer disagreement.

We also don’t live in a world where every project is the same. There will be some projects where you don’t need a designer at all, and others where you don’t need a developer at all. Smaller projects will generally only require the first three skills, and as shown in the matrix above, both disciplines (ought to) possess these. In these instances, it would almost be counter-intuitive to have both a designer and a developer working together on a project that either of them could adequately complete on their own.

The other thing that should be apparent from the above list is that the web designer is NOT just a creative: developers expect designers to care just as much about how the site is coded. Remember: You are both engineers and there does exist beauty in the code of a well-written site (not to mention SEO gains).

As you get further down the list, the differences between a designer and a developer begin to become more apparent. Everyone has their own idea of what developers are and what designers are, and I don’t really want to get too bogged down on that point, but in my experience the above table accurately describes the differences. The rest of this article proceeds on the basis that the above definition is a valid one (if you disagree, please feel free to comment).

The other thing to qualify here is Javascript: Up until relatively recently, this has been within the realm of a developer but with modern technologies such as Jquery, people are now writing controls aimed at  designers. They painstakingly build them such that the installation of these controls is incredibly easy. They do this so that you don’t need in depth technical knowledge of javascript to be able to use them. A developer’s expectations of a designer probably won’t extend beyond being able to install these controls and possibly being able to comprehend a bit of Jquery.

Know your role!

I’ve already mentioned that the definition of a web designer is quite fuzzy. The role of a developer is hardly ever called into debate, whereas the role of a designer is questioned all the time.

The above matrix describes what I believe to be the required skills of each party: this does not mean that each party will actively be using those skills in the development of every project and usually these skills will be seperated out as follows; A good designer/developer combo will probably involve the designer working with the presentation layer technologies (graphics programs/HTML/CSS/bit of JS) and the developer working on the rest of the functionality. A good developer will limit the designer’s exposure to anything beyond that to some easy-to-understand code nuggets within any server-side page.

The ONLY exception to this seperation is the business logic, which both parties need expert knowledge of before pen is put to paper at all.

Aside from the aforementioned installation of third party JavaScript controls, the general  rule is that the designer does the research and designs the presentation layer/user experience (including coding it), and the developer does the functionality / back office and assists the designer in helping their ideas come to life.

The key word in that last sentence was “research”, by the way, and we’ll come on to that in a bit.

Developers DO know about design!

There seems to be this myth that developers are a bunch of soulless architects whose sole job it is to fulfil the designers’ “vision”, but developers care about web design too! If we’re taking my skills matrix as a given, a designer will care just as much about the underlying code as a developer does, and a designer having the creative vision does not absolve them from producing well-structured, standards-compliant, extendible HTML and nor should it. The meat and potatoes of a website is its HTML, CSS and JavaScript, and you both have to work together to make sure that these are perfect.

Just because a developer doesn’t do a designer’s role does not mean that they don’t understand what a designer does, and as a result a developer will have some expectations of a designer (possibly a lot more than a designer will have of a developer). The following is a brief list of things an average developer would expect a designer to do;

  • Hand code all of your HTML and CSS – DON’T USE DESIGN VIEW
  • All code should be standards compliant and semantically accurate (no hacks)
  • Test your HTML in all major browsers
  • Keep up to date with web design trends and technology
  • Base all decisions on a combination of instinct AND science

If you’re a designer reading this, I can tell you that from a developer’s perspective that last point is a real fire starter, bassically because whereas many designers will always try to break conventions, most developers will try to STICK to conventions. It’s what seperates the men from the boys in the designer world – basing entire decisions around doing something “edgy” and “risky” is going to result in your users getting annoyed and your developer losing their hair.

I was hiring a designer a while ago and I asked the following question of every candidate;

If there was a sliding scale of design, and at one end was gut instinct and at the other was a scientific knowledge of what is effective and what isn’t, where are you along that scale?

And every single candidate said “instinct all the way”. This is really not what I wanted to hear as a developer. Our role is perhaps not as glamorous as a designer’s, as what we do is largely described as “behind the scenes” stuff. We are being asked to trust someone else to make good design decisions and we can really only do that if we know that sufficient research has been put into those decisions. Simply telling a developer that they’re “not a designer” and therefore “don’t get it” isn’t sufficient: Give us some evidence that you’ve thought about what you’re doing and that you’re not just working off some gut feeling! I couldn’t have put it better than Jason Gube of sixrevisions did last week:

When you’re designing, you have to ask yourself “Why?” a lot. All design choices should have a reason; that’s what makes it design, not art.

“This is technical, therefore it’s the developer’s job”

One of the most common places I’ve found that developers and designers will come to blows is with dynamically generated HTML. Some designers, particularly those not familiar with server side scripting, are perfectly fine coding HTML that works for specific cases, but will struggle when the HTML is required to work for multiple cases. From a developer’s perspective the coding of HTML in these circumstances lies with the designer, and does not become a developer’s job just because it’s suddenly not hard coded onto the page. Remember guys: Don’t get the word ‘complicated’ confused with the word ‘technical’.

In dynamic applications, it is far more likely that the designers will be working with pages that include server side scripting (such as asp or php). None of the html books that they’ve read will have any of this in, and many designers can find it quite daunting at first. However: Just because it is not standard html does not mean that it suddenly becomes the developers job to change / design / create it: the format of the underlying HTML should come from the designer even if it’s eventually the developer that ends up creating the code that generates it.

Scope Creep

The other biggie is scope creep. Ryan does mention this in his article and makes some very good points. Whilst not always the case, it is usually the designer that ends up doing a lot of the client interaction and producing the mock ups. Remember always that deadlines may be PART of the requirements: designers should not write cheques that they can’t cash. It’ll annoy the client, it’ll annoy the developer and it’ll probably also annoy the designer. Now you’re all annoyed, where’s the gain? Designers: don’t promise something to a client before consulting the developer you’re working with. However, this may become a moot point based on the following comments about scope creep.

Now: scope creep isn’t always the designers fault! Clients can be very persuasive and if it’s the designer that’s dealing with them then you can’t blame them for a client’s insistence. Most developers will not mind a framework change, as long as it is a logical one. Web design is one of the few industries where the customer is not always right: what the client thinks they want is not always what they actually need. This is because it’s possible (in fact quite likely) that the client will have little or no web knowledge. Often both the designer and developer will find themselves contending with a client who tries to dictate the details of something they know nothing about.

One of the other expectations that developers will have of designers is that they will be able to diffuse situations where the client is asking for something that will not benefit them and will waste everyone’s time. Developers HATE “yes men” type designers, and professional web designers should hate them too.  Having said that: as the client usually holds the purse strings, we sometimes don’t have a choice. Some people simply will not listen to experienced professionals. If you don’t want to fall out over it, designers: just make sure that your developer knows you tried your best and developers: believe them when they say they did!

Conclusion

The key areas that developers and designers fall out over are;

  • Designers not possessing the skills required to be web designers.
  • Scope creep due to designer not managing client expectations.
  • Noddy design decisions purely based on a designer’s gut feelings

The main problems stem from differing definitions and conflicting expectations of the roles of web designer. The main expectation of a developer is that they are able to bring the designer’s ideas to life, but it mustn’t be forgotten that the developer will also have certain expectations of the designer. There is absolutely no need for any tension to exist between these two disciplines so long as you both know your respective roles and know what your expectations are of each other.

Further Reading

Other articles I found relating to this topic;

About these ads

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