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, 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.

2) Coding a bit can be worse than not coding at all

Most of the developers I’ve worked with would be aghast if a designer attempted to meddle with their code. I showed one Jared Spool’s comment that ‘knowing how to code helps you identify bugs and flaws in the production code’ and he just laughed.

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.

Leisa Reichelt and others in the ‘yes’ camp think it’s fine – a perfectly valid term for people whose skillset and role includes elements of coding as well as having a hand in design decisions. Andy Budd and the ‘no’ camp think it makes unmerited use of the term UX as if it’s some kind of mark of quality, and waters down the complexity of the discipline of user experience design.

In some ways, I agree with Leisa Reichelt. I don’t really see the need for the absolutist categorisations and the militancy that often seem to crop up when people are discussing this industry’s job titles.  If you have a mixed skillset then why not use your job title to describe what you do as succinctly as possible? Isn’t that what a job title’s for anyway?

I also don’t agree that a developer with an interest in UX activities is just a ‘good developer’ as Andy Budd argued, or as Whitney Hess said, ‘a developer working in 2012’. There are plenty of good developers who know a lot about code and technical engineering, but don’t  have much knowledge of (or interest in) psychology. I don’t think that’s necessarily a bad thing. After all, the UX designer is there to represent the user. I’d rather work with a developer who I could rely on 100% to code a robust product than one with one eye on the design.

However, where I do agree with Andy Budd, and my only problem with the title UX developer, is that in some ways it does cause some damage to the meaning of the phrase ‘user experience’ because it contributes to a trend which seems to be happening anyway:

It makes people think UX means ‘web’.

Nearly all of the UX Developer job descriptions I’ve seen are focused around front-end coding.  Similarly, I’ve noticed many freelance projects looking for a ‘UX Designer’ and even ‘UX Consultant’ are basically looking for a visual designer and front-end coder, who, as a bonus, should give a passing thought to the usability of the thing before they build it. I think this is worrying because it narrows the role of user experience design right down, making it a subset of web design.  It makes it seem as if we can only design for the experience of people using a website and ignores the huge range of non-web-based interactive products and services out there. And in turn, this makes user experience less about strategy, less about people, and more about a particular technology.

I was recently reading Dr Susan Weinschenk’s article on The Psychologist’s View of UX Design, (which, by the way, is a great introduction to some of the psychological principals of design) and I couldn’t help but wonder if she was selling short the role of psychology in UX with this introduction:

“A king brings six men into a dark building. They cannot see anything. The king says to them, “I have bought this animal from the wild lands to the East. It is called an elephant.” “What is an elephant?” the men ask. The king says, “Feel the elephant and describe it to me.” The man who feels a leg says the elephant is like a pillar, the one who feels the tail says the elephant is like a rope, the one who feels the trunk says the elephant is like a tree branch, the one who feels the ear says the elephant is like a hand fan, the one who feels the belly says the elephant is like a wall, and the one who feels the tusk says the elephant is like a solid pipe. “You are all correct”, says the king, “You are each feeling just a part of the elephant.”

The story of the elephant reminds me of the different view of design that people of different backgrounds, education, and experience have. A visual designer approaches UX design from one point of view, the interaction designer from another, and the programmer from yet another. It can be helpful to understand and even experience the part of the elephant that others are experiencing.

I’m a psychologist by training and education. So the part of the elephant I experience applies what we know about people and how we apply that to UX design.

Now, I kind of think that applying what we know about people and psychology to the design process is the UX elephant – not just one small corner. Of course, the visual designer, the programmer, the project manager and everyone else involved in the development of a product will approach the project from a slightly different angle. Whilst each of them will (hopefully) have an interest in the user’s experience of the finished product, they all have other things as their primary concern – making it look attractive, making the thing actually work. The UX designer on the project is probably the only person who has the end user’s overall experience as their primary focus.

I’m by no means trying to put down the role of the programmer or the visual designer, by the way (that would be ridiculous – UX would be pretty pointless if we didn’t have anyone to make a design real.) I just mean that when your knee-deep in functions and variables, or vectors and gradients, then it’s a lot easier (and more efficient) to stay there, rather than wading back out to think about what psychological theory says users are likely to make of what you’re doing.

I think I would offer a slightly different take on the elephant analogy and suggest that maybe, like the blind men, lots of the other people involved in the creation of product have to get so close to their particular task that they may have to lose sight of the big picture. And perhaps that’s precisely why we need the role of a UXer on the project – to take that step back and look at the whole elephant, and to use what we know about the way people’s brains work to think about how the elephant will look to them.