By Tim
Categories: Design | UX Design
I’m feeling left out. There is a sudden, surprising upsurge in the number of designers extolling the value of code. That’s not to say that designers are arbitrarily acknowledging the beauty of a well-formed operator overload in C++. No, they’re clamouring for courseware for front-end development. Designers want to be developers.
Serendipitous mythical alignment
I was in the room at the IA Summit when Jared Spool posited the notion the most valuable member of the team is now the designer who can code. The mythical UX unicorn who unto us is born with the divine skillset we never knew we didn’t have. Since that day, there has been a scrambling, iterative fine-tuning of that message into a 140 character CV that seemingly defines a new generation of designers. If you’re not signed up to codeyear.com or attending a bootcamp on JQuery, then, well, really, what kind of designer are you? You just design things?
This conflagration of seemingly impossible-to-combine skillsets comes at a most opportune moment. Times are tight. Resources are expensive. Why would clients pay for a designer and developer when there’s this pointy-headed horse over there that can do it all? You only need to look at the job boards and recruitment sites to know that the designer developer unicorn has become a reality, because you can get paid for it.
The benefit
There is always a good reason to further the understanding of technology and the sooner that can be embedded into the education system the better. Traditional ICT courses have always tended to focus on the appropriate use of others people’s product, such as, say, Microsoft. They’ve never really proposed a way you might think about building your own products. That understanding of the possibilities and constraints is also very handy for a designer to be pragmatic about implementation and build of a design solution – that’s to say, if you can empathise with the delivery partner, you can maybe bring that knowledge into your design activity and be more efficient or scalable or, well, nice, or whatever.
The problem
Being understanding of the build and development requirements of the design deployment, however, is one step short of having to do the build and development yourself. Because, as any developer will tell you, development is hard. You can’t walk out of a programming bootcamp and create an elastic list faceted search implementation for a retail site with 100% uptime, any more than a developer can walk out of a design bootcamp and interpret 120 sessions of user research and convert those insights into conceptual designs that provide a framework for extensible, platform independent, simple, elegant design solutions.
If you really want to be a developer, change your course. Bring a design sensibility to that career. But don’t feel you need to do both. And don’t pretend that being a developer can make you a better designer. Feel free to extend your knowledge and get a better understanding, but stop short of re-defining yourself.
Your thoughts
Fabien said:
I don’t think anyone is seriously pushing the idea that the designers should be the one delivering production ready code. If someone actually is, I’d be the first to agree with you that it would be a terrible idea.
Getting designers to learn the basics of “code” (really html/css) is all about, as you said “understanding (...) the possibilities and constraints “.
Basically, if you are making a wood sculpture, you need to understand the properties of wood. You don’t learn them by drawing picture of wood or looking at wood photos, but by actually sculpting wood. And if you are making websites, you need to code a bit understand how they are made.
Some engineering heavy companies like Google go as far as demanding that all their interaction designer code what they design themselves. This is their only deliverable: code that work. Not a
powerpoint / axure / whatever simulation of code that work.
Another great benefit of being code-savy is that you can push back when a lazy developer say “can’t be done”.
The lack of a basic understanding of how what the web (or apps) is made of is often one of the few blind spots of many great ux people (and agencies).
Tim said:
Hi Fabien. Good points there about how learning enough about build and implementation can enable designers to be more pragmatic in their design activities, especially when working with developers. Thanks for the comments.
Simone said:
I perfectly see the point raised by Fabien, I think I’m an hybrid between UX and a ‘soft’ coder, it’s really difficult for me to explain my skills. But this morning I came to this article, that’s exactly what I think on this topic, and I feel kinda relieved.
By the way, 5 minutes later I received a job spec saying “building complex and responsive design user interfaces with JS” and I fell off. Responsive design with Javascript. If this hype around Javascript will go on I guess in two years agencies will ask to build wireframes in JS.
I see the point to design having a good spot on how the code will behave, but all these agencies looking for designers that can code hardly it’s a plague. The forma mentis and skillsets of a good designer is not based on the full understaning of a loop cycle or conditions or a for/each. Hard to understand.
It looks like everything should be done in jQuery or some JS framework. I’m scared.
Rob Varney said:
Further to this article, I discovered this debate here: http://bit.ly/IWxmbV
It’s an interesting way of breaking down the role of “designers”. Another rich seam of argument and lively discourse.