A List Apart recently linked to an article by Joshua Seiden titled, “Designers shouldn’t code” is the wrong answer to the right question. Joshua’s article is actually a response to Wayne Greenwood’s article, Unicorn, Shmunicorn—Be a Pegasus.
Both authors discuss important topics like different methods of approaching problems, which details to focus on & job security, so I urge you to read them. But to be completely honest (and hopefully not belittling), I think we’re over thinking this.
Designers should know just enough code so that they understand the technical constraints of a project and are able to reduce any potential issues during the execution phase.
What is meant by “code”
Joshua does a great job covering this in his article mentioned above:
Second, “code” is such a broad term as to be essentially meaningless. What do we mean when we say this? Do we mean back-end programmers writing APIs in C#? Do we mean full-stack developers writing web applications in Rails? Do we mean front-end developers working in HTML+CSS+Javascript?
In this case we’re definitely talking about front-end code, as Joshua goes on to say. I can’t think of any valid reason a designer should have to worry things about frameworks, database adapters, frameworks, etc.
Be a t-shaped designer
What does it mean to be a t-shaped person? Basically, it’s someone who excels in one area, while still being generally knowledgeable in other related areas.
Some things you should know as a t-shaped designer:
- Basic HTML & CSS (Box model, floats, positioning, page flow)
- Interaction (What happens when this is clicked? How will this adapt to a phone or tablet?)
- Performance (How will 4 web fonts affect page load time? Will this require any 3rd party scripts?)
- Accessibility (Is there enough contrast? Is this typeface legible at this size?)
Having a general understanding in the areas listed above doesn’t mean you need to become an expert in them. I can also guarantee you that you won’t have to design in the browser, understand Sass mixins or know the difference between a rebase or merge in Git. Heck, most of the time you probably won’t even have to write code.
(But if you do end up writing code, it doesn’t need to be great either. It should hold the same value as a sketch on a whiteboard or piece of paper does.)
Going forward
Developers don’t want designers to start writing production-ready code, the same way designers don’t want developers to create interfaces. There will always be a need for a dedicated designer and no one is trying to diminish your role on the team.
Things move quickly in the web industry and that means constantly learning new things and stepping up our game. Don’t look at these extra responsibilities as burdens, instead see them as a new challenge.