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:
|Server side scripting
||NO KNOWLEDGE REQUIRED
|Knowledge of the business model
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).
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.
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!
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.
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!
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.
Other articles I found relating to this topic;