came across this at http://csswizardry.com/2011/09/do-de...-need-to-code/
Is a web designer really a web designer if they can’t code?
A lot of the arguments revolve around the (false) fact that ‘designers can’t understand what they’re designing if they can’t build it’. This argument suggests that a web designer who can’t code is a fake who’s just blagging their way if they don’t know/understand how to actually build the websites they design…
This is wrong. By this token I should understand MySQL and programming and Project Managers should understand design theory and programmers should be able to manage clients. There’s a reason we have different job titles; people do different jobs.
A designer who can build websites is a designer–developer, a designer who can’t write HTML/CSS is a designer.
Designers should work with developers
One reason, I think, that people believe that designers should be able to code is that they need to honour their designs, they need to be sure their designs are buildable by being the ones who have the responsibility of building them.
The problem is not that designs need to be buildable, it’s that developers should be permitted to send designs back and make compromises. Designers and developers need to collaborate, not be combined. Designers need to keep pushing the envelope, making tricky and outside-the-box visuals that push the work of the developer forward. The developer needs to be able to work back the other way, show the designer the boundaries that cannot be broken. Designers shouldn’t lead developers, developers shouldn’t lead designers, there should be a happy middle ground where teams work together, specialising in their respective areas but understanding and appreciating each others’.
A designer who codes badly is less use to a developer than a designer who can’t code at all. Developers need designers, not bug making machines.
But the client was shown a PSD that needs to be honoured…
I think this may well be one reason why people believe designers should code; the situation where the client has seen a PSD and thus expectations are set. A developer hasn’t seen the visuals and is all of a sudden expected to build something he’s had no input in. For the most part this may not be the case at all, but it definitely could be…
The remedy here might be to make sure designers only create things that they can build, achieving this by making sure designers can code.
This is fixing the wrong problem, the problem here is a lack of communication and a lack of collaboration, not a lack of skills. Designers and developers should work together from the outset, working in the browser to ensure that a) the team is working as, well, a team and b) that a client is never shown a PSD (showing a client a PSD in 2011 is just foolish).
The recurring theme is collaboration… Designers and developers need to coexist, not be one and the same.
HTML and CSS isn’t easy…
…but it is easy to do badly. I know loads of designers who can make the most stunning visuals but their code is not a strong point. Sure, they can write HTML and CSS, but it’s not where they specialise or excel, in much the same way a lot of developers have no design sense.
A designer who writes bad code is less use than a designer who can’t code at all. Once a designer writes poor code then either a) a decent dev has to come along and spend time bug fixing, or b) poor code becomes a tangled mess off spaghetti CSS and browser hacks.
Do not undervalue the importance of HTML and CSS, they are easy to do badly, but hard to do excellently. You need excellence in both design and development, so leave each role to its respective person.
These rules introduce restrictions
If a designer needs to code what he’s designed then he’ll design to what he can do, not to what can be done. This is a fundamental mistake to introduce.
A designer who isn’t restricted by a secondary skill set will produce things outside the box, push the envelope and keep innovating. A designer who is limited by their dev knowledge is hemmed in, scared of pushing the boundaries for fear of creating themselves work they cannot complete.
By forcing one thing you are restricting another, this is not a good thing to bring into your team. What you need to do is keep the contact and collaboration (there it is again) between design and build to ensure that everyone is achieving their full potential.