This morning I was reading through Quora (which by the way, is totally awesome and they just launched publicly), and found this question: Should user interface designers be able to build what they design? This is a topic I’m pretty passionate about, as I feel that it’s something that weighs on the minds of all young designers entering the field. Plus I tend to have an opposing view from a lot of people on this. I posted an answer to the thread, but then realized I basically wrote a blog post (I know, bad form) so I decided to post it here as well as it outlines my thoughts on the subject. The answer begins below…
Sorta.
I don’t think it should be a requirement to be able to build what you design. That’s about as silly as requiring an architect to know how to weld professionally. However, I doubt there’s an architect out there who doesn’t, at least, understand the concepts of how what they design is built (or maybe be able to tinker a little on the side).
The fact is this: being a designer and being a front-end engineer are two separate skill sets. If you’re great at both – that’s awesome. Pick one as your focus. In the 10+ years I’ve been in this industry, I’ve seen designers feel more and more pressure to learn how to code. The problem with this is that it ends up creating a whole lot of people who are mediocre at both because they weren’t able to ever really focus on one.
Now, that isn’t to say that you can’t be an amazing designer and an amazing developer. There are many examples of people who are. However, if you look at the people who fit that bill, they very likely started with one, then pursued the other. I see so many kids coming up in this industry who spend more of their time trying to wrap their heads around JQuery than they do UX. Here’s a tip: If you’re better at JQuery than you are at UX you’re a developer, not a designer.
This may seem like a convenient point of view coming from a designer who isn’t a very good developer, however, I’ve purposely gone this path. Why? I’ve spent my career around passionate, talented developers who were more suited to tackle the work, which allowed me to focus on being a designer. And every minute I didn’t spend writing code, I spent designing. I do have a baseline understanding of markup, and I can write some wonky-bordering-on-decent HTML & CSS, and that’s ok. I don’t get paid to do those things. They’re a hobby.
Here’s my caveat: all designers should understand what all applicable programming languages do to be able to effectively design for them.
I may not be able to write the code that will fuel what’s going on in my head that I’ve laid down in Photoshop, but I sure know how to design for it. That’s why I said “sorta” above. Going back to the architect example: If you’re designing something to be built using steel vs. wood, your thought process goes in a different direction and you have different problems to solve. Without understanding the benefits and limitations of your materials, you’re going to design something that will fall down.
In the end, it’s important to understand that a great designer is a great problem solver, and hard problems are solved with great ideas. Not all designers have great ideas. In fact, most don’t – and that outweighs the benefit of how fast they can learn HTML5, CSS3, or the ins and outs of the latest version of Adobe CS. I’m certainly not suggesting that someone with great ideas and a totally shit ability to execute on them in any fashion is a worthwhile hire, but a great designer is a great designer. Whatever else they happen to excel at should be a bonus, not a requirement.
5 Comments
You touched on a lot of things I completely agree with. I started working with the web by coding and designing my own sites, and have worked at a number of positions where the teams are small and the workload is shared. But, what I’ve learned is similar to what you’ve said. It is smart to focus on one subject at some point or else you may begin slipping in specialization and could easily end up falling behind in both. I see myself heading in the development direction. Not really by choice but by observing my own skill set.
I do think there is a lot of value in having experience in both. You can tell a person is really a designer when they throw in some sloppy jQuery they pulled from an example off a plugin’s website. And I see it too often. Maybe not completely related, but it is like when a project manager doesn’t have any experience in the topics (s)he is managing. Results in visible inefficiencies.
“I’ve seen designers feel more and more pressure to learn how to code. The problem with this is that it ends up creating a whole lot of people who are mediocre at both because they weren’t able to ever really focus on one.”
This is totally spot on and I couldn’t agree more but…
…I think one of the reasons that companies (especially in the UK) are looking for people with a wide range of skills is down to the current economical client. Its more cost effect to employ a designer who can also code than it is to employer and designer and developer.
It make good short term business sense, thats not to say its right.
I think we agree on some of the concepts and have come to opposite conclusions from them — maybe because I come from a more technical perspective. At least you recognize that you have to understand some underpinnings of the code — sadly not everyone calling themselves a designer understands that. Instead of a long theoretical answer, let me just give you a quick and somewhat superficial example of why anyone who claims to be “designing” for the web should at least be able to create a working html/css/js prototype of the page they design. It boils down to forcing code decisions out of ignorance of _quirks_ of the code through inexperience rather than out of what makes the most sense from a coding standpoint.
Gradients are big right now, and that’s obvious if you look at any style blog. The non-coder may not understand that it’s because they’re finally useful in most browsers via css3, but they know they’re trendy. How you implement them in your design can either facilitate doing them without extra images or force the coder to recreate the gradient in Photoshop and use images to make it work on the page.
If you understand how css3 gradients work in the major modern browsers AND how the Explorer filter gradients work (I mean really understand the quirks of both from experience using them, not just have used it once or read a spec once — and trust me, there’s _lots_ of quirks to gradients that you aren’t going to find in the specs), you can design your gradients and anything that overlays them off the bat in a way that works in the code AND you know what hex or rgba codes and what kind of color stops to supply to the coder. This is efficient and makes things faster for both designer and coder. You’re both speaking the same language.
If you don’t understand it, odds are your gradient will not play well with css3 gradients or IE filter gradients either one. Then the coder needs to be twice as proficient at Photoshop re-creation because they’ll have to first re-create the gradient as an image, maybe multiple images depending on the design, (usually from scratch in my experience because the flattened .jpgs coders usually get from “design only” designers are kind of useless — and re-creation of a graphic or gradient isn’t exactly easy most of the time) and then use their new image(s) as a background or sometimes as a combination of background and foreground depending on the design. It usually ends up needing extraneous non-semantic markup too, whose sole purpose is design. Besides the fact that this means your coder needs to also have stellar design and image editing skills to be useful, every additional image is another call to the server, which is generally best to avoid. The designer and the coder are not only not speaking the same language, they’re working at cross-purposes.
Now, sometimes it’s better to use an image, but that call should based on the rest of the code and design, not based on an ignorance of how it’s going to be implemented… and at that point, what’s the point of there being that designer at all? Most of what they’ve done is force a bad code decision and doubled the time of the coder. In that situation, the designer pats themselves on the back for only being a designer, but the coder has had to use both design _and_ code skills at a high level to get around the clueless design.
It goes the other way as well though. A coder with no eye for how a 3px jog in the vertical affects user reactions, or who doesn’t understand why it’s a radio button and not a checkbox, or why you need to create contrast between the text and the background, can create some highly unusable pages even when working from a well-designed flat wireframe.
It’s more productive to look at design as the ability to bend the rules of html/css/js to your will. You have to know those rules intimately before you can start figuring out where they bend and where they’ll just laugh in your face and smack you. This is not an either/or process and it’s not something you can learn by reading. You can only really understand it by doing, by using them regularly.
I guess, here’s the distilled point: Can you be good at either and barely proficient at the other? Yes, maybe, if you’re going to separate out things that are two sides of the same coin as though they were different entities, which is a false dichotomy. But to be great at either you have to at least be _good_ at both. Otherwise you do not have the experience to understand enough of what happens to account for all the things that need to be accounted for and someone else who does will have to make those critical decisions — or worse, the decisions won’t be made at all, they’ll just happen haphazardly.
I have to agree with you Jeffrey.
If you want to be a remarkable ux designer, at least understand how your design is going to become a reality. We can see the value of this approach by looking at newspaper designers, who are used to designing ads or layouts for print material, and are now trying to design for the web and failing miserably.
Great advice and solid insights.
Well said, Jeffrey. I tend to find that people have the opinion of whatever they do tends to be the right fit. It’s good to hear someone else bring up the mediocrity/single focus comment in this age of “web professionals” that can claim to do everything. If you are spending 6 hours debugging css commands, that is 6 hours that you aren’t designing and possibly refining your craft. There are some very talented people who do both and I envy them, but I think there is a lot to be said for designers who obsess over the visual details that push the UX field forward.