Four reasons why I don’t think a ‘designer’s gotta code’

Jared Spool started this debate last summer, but recently his tweet, ‘The ugly truth: Designers who can code will squash designers who can’t code in the marketplace’ got me thinking about it again, mostly because he hashtagged the tweet, ‘designersgottacode’.

I don’t think a designer’s got to code.

I mean, I don’t think there’s anything wrong with a designer who can code. Generally, of course, it’s better to be able to do something than not be able to do it. And let’s face it, the principles behind HTML and CSS are pretty easy, so getting a handle on the basics, at least, probably can only be a benefit in terms of your career.

But I don’t think a designer has got to be able to code, and in fact, regardless of whether or not they’re able to code, I think it’s often better if they don’t do it.

Here’s why:

1) It makes it tempting to cut out UX activities

If you’re recruited for a role where you have to design and code, there’s often a risk you’ll end up focusing on coding.

Project managers (or business owners – anyone who has an interest in the budget) always want to see tangible products. Stuff they can sell, stuff they can deliver to clients. Coding the website has to be done. If it’s not, then you don’t have anything to show for yourself. All the research and planning are unlikely to impress without a finished product. When budget and time are tight, when the project manager is looking for places where work can be trimmed down, you can bet it will be the UX design activities that are viewed as expendable luxuries.

Of course, start-ups are likely to want someone who can design and code (and project manage, too, probably). One person is cheaper than two or three. And if they hire you as a UX designer who can code, than they tell themselves and their clients that their products are the outcome of a user-centred design process, even if, in reality, the design activities have been cut from the project.

Maybe if you have a solid background in proper software engineering (as Jared Spool does) then this would work. Or maybe if you were working on a simple website, it wouldn’t be too dangerous. Generally, though, for a product to be robust, it needs to coded by someone who really knows their stuff, and to get to really know your stuff in the world of software engineering takes a long time. I suspect that someone who had spent time building up their UX expertise would not have had the time, practice or focus to be able to be a really solid developer too. I think there is some truth in what they say about Jacks-of-all –trades.

3) You don’t need to be able to write code to understand it

Many of the arguments around needing designers to be able to code focus on the point that it’s easier to design well if you know the capabilities of the media you’re designing for. That’s true, but you don’t need to be a coder to understand how it works and how something will be built.

As you work with developers and talk to them about the feasibility of various ideas, you pick up more and more information on how things are put together. You get more of a feel for how different elements of the code talk to each other. This kind of knowledge is great, but it’s not the same as being to write code. It’s possible to understand how code works without being able to spot a missing semi-colon on line 265.

4) It takes your focus away from the user

This is the most important one, I think.

If you’re going to be coding your design yourself, even if just to the prototype stage, it’s going to be much more tempting to taint your design decisions with a little bit of developer-centricity. Often when developers I’ve been working with have made design suggestions, they’re asking to have features designed in a way that’s quicker or easier to code, or that lets them try out something that they think is a particularly neat coding solution. My experience has been that when you’re as intimately involved with a product to have seen its insides, you’re not in the best position to see if through the eyes of a user.

This leads me to conclude this post in the same way as I did my previous post (on UX developers): Designing a user experience should be focused around people, not technology.