This morning I picked up on a conversation on Twitter between Dave Malouf, Dan Saffer, Markus Weber and Russ Wilson about whether designers need to have technical knowledge about the code and technology they design for. I jumped in and argued that “knowing code limits creativity”, referring to my comment on Tim Brown’s blog post forming versus coding which was specifically about design and synthetic biology but applies to the discussion:
[regarding] component vs system design and the requirement for coding skills … my thoughts are designers should understand the capabilities of the technology but not get down in the nitty gritty of binary programming or DNA coding. Whilst such knowledge can facilitate and expedite interactions with the developers or in this case biologists designers should keep at a distance in order to not confine themselves to a box of “things we know we can do”.
As I touched on in a recent blog post on system thinking applied to design specification something will be lost when there is too much focus on individual components. Designers will add more value at the collective, the system, the interplay of components – and leave the challenges of implementation to the developers and biologists.
Not that the pointy end of implementation requires any less creativity than designers – in fact coders can apply as much design and creativity trying to bridge the requirement-capabilities/constraints chasm as the ideation/visualisation “designer” designers.
Whilst accepting that coming from a software development background that’s shaped my career I am trying to distance myself from coding. I accept that knowing PHP, ASP, HTML, JavaScript and CSS has helped me design feasible, efficient interfaces that I can then describe to developers in programmer-speak … or in the case of web front-end development actually implement as even with my rapidly dwindling skills currency I can still code standards compliant best practice web application interfaces better than most devs I’ve had to work with.
As I further raised in the discussion on Twitter:
You don’t think knowing what IS done doesn’t limit what COULD be done? You don’t think or design in terms of jQuery widgets?
What I was saying is that working with LEGO or Meccano or plastic toy soldiers puts you in the mindset and mental box of working with those pieces and typical configurations. Designers need to throw out the recipe book and let developers come to the table with the feasibility assessments.
Dan Saffer early on in the to-and-fro linked to this article on ignore the code Designers are not Programmers by Lukas Mathis who says:
I believe that being able to program can be a negative attribute for people who are responsible for designing the user experience. Designers who know how things are implemented or, even worse, who have to implement their own designs are in danger of impeding the quality of their designs.
In response to Markus Weber’s question to me “How would a UX designer perceive the statement that programmers should be able to design?” I replied:
If programmers CAN really design, good on them. I’ve done the one-man-show gig before. However it’s VERY hard to switch between the coalface dev mindset and the big picture design mindset.
… followed by a response to Russ Wilson:
Programming is about technology and binary, design is about humans and behaviour. Very different headspaces to occupy.
Dave is of the opinion that it’s ok for designers to know to be able to code – in fact he believes it can help them ensure the product is then implemented correctly according to specification. While in my experience that’s certainly true I believe that whilst designers might know how to code if it’s not their job they should step back and allow developers to step up. I’ve seen what happens when programmers are pushed into the “Just convert this pile of spec into code”. It’s not pretty. As designers we have a responsibility to innovate and facilitate in all areas of project execution – and it’s what developers are always asking for. In fact it’s what people in nearly every occupation I come across asks for “Involve us earlier!” … but I digress.
Read more in Dave’s wrap-up post of this morning’s discussion Why designers do need to know code …
// purecaffeine.com: user experience design, social experience design, social media, Gov 2.0, design thinking and service design blog by designer Nathanael Boehm, Canberra, Australia. Licensed under a Creative Commons Attribution-Noncommercial-Share Alike 2.5 Australia License.
{ 10 comments… read them below or add one }
It’s funny I always find the people who can design but can’t code, are always bagging those that can. Belittling the coders with things like – “oh that’s a technical thing… that’s not important” I just roll my eyes and remind people – this is interaction design, it is technical, its not fine art!
The anti coding goes on saying the coding designers are very limited in their designs as they are always thinking about code.
The only solution is that they should go get a brain wipe and become real designers that can’t code. Yeah right!
No matter who they are I have found that when they say this face to face, I just get this tinge of jealously from their body language. Maybe they are just a little bit envious of the folk that have a few more skills.
Personally I just don’t understand their issue!
I’m forever designing things that are well, a pain to implement. Do I think about how it’s going to be build while working on the interaction design. Well no. I think about the interaction. It’s only at the end of it all, I look back on the spec and go – “oh no, how are people going to build that”, often having a mild panic!
Also I don’t think it’s hard to change hats. I just put a little space and time between the processes, a kind of mental reset.
Should designers understand code, should be they be able tell if the dev is being lazy and can implement the design. Yes! Just like devs should know a little design. A good solution comes from a team effort.
That’s an ad hominem. A person’s motivation does not change reality; why somebody says something doesn’t change whether it is true. If somebody is truly wrong, it makes more sense to attack his or her argument, rather than what you perceive the person’s motivation to be.
Besides, you are assuming too much. I wrote my post precisely because I do both, and know a lot of people who do both, and have personally experienced the issues this causes. I think it can be okay for somebody to do both design and coding, but it requires acknowledging the accompanying issues, and consciously dealing with them, rather than just pretending that there are none. This is the reason why I wrote about it: I noticed that it is better for me to consciously deal with the dichotomy between design and code.
I think this is the point we are all trying to make. It’s better to have two people who can fully advocate for their respective areas of expertise, without being compromised by their “second hat.”
– Bruce Mau
I agree that not knowing the technologies limitations brings “stupid” questions that push developers to find ways to go around those dead ends. And that really is great! But often, I also find designers that are not aware of the possibilities of a given tech. Are they bad designers then? I don’t know how to judge that.
I know that less meetings, and a design that doesn’t need a bunch of “sorry, can’t do that” sure would help having the already late project done on time. Sure kills the creativity, right? =(
As a Dev, I would love that the designers that I work with would be a bit more educated on the tech side. They hate when I use LOLcats as placeholders, and I hate when they force “important” design choices that cripple the project (performance wise).
It sounds like designers are presenting fully formed designs at these meetings? I suspect you probably don’t have much influence on the design process, but generally speaking, it would make more sense to involve developers early, showing them how storyboards and sketches look. That way, such problems would be caught long before these meetings.
After all, this isn’t just about the front-end. Developers often also have to implement or change the back-end so it provides all the features that the front-end requires, so involving developers early makes a ton of sense.
I’ve been in design and UI engineering for a long time now (almost 20 years), and I think the line between UI designer and UI developer is blurring… and should blur.
As UI designers we should be more like sculptors and less like architects. Know your medium and get your hands dirty to bring form to what you have designed.
You could also argue that “knowing anything limits creativity”. We’re born and each day we live siphons our ability to be truly creative as we’re tainted by our interactions with the world.
It seems like the only solution is to put toddlers in charge of design. The only problem is the child labor laws…
In my own opinion, it’s healthy for any professional to understand the details of their craft…even if those details are commonly handled by someone else. It helps them understand how their contributions are woven into the larger tapestry. This enables them to better interact with the team. I see far more positives than negatives.
Nice article though. Thought provoking. :)
A designer/developer faces two main challenges; laziness and the opportunity to make design decisions based on development hours required.
If ambition and budget exists a designer/developer is in an excellent position to design thorough, complete user experiences and produce innovate interfaces.
As a designer who’s worked for the last year with a designer-developer and slowly got my head around PHP etc, I think designers should at least understand code, and have to do the whole ‘being on the other side” at least once so that they know what information to communicate. (Having banged my head with a wireframe that wasn’t to pixel scale and with no RGB colour specs, I’m now a lot more careful on that thing!)
On the other side, my designer-developer friend has found that she’s in great demand for theming as she understands the meaning of pixel perfect when it comes to images/typography etc.
It’s not so much about designers being able to code as being able to have empathy and at least speak some of the same language as developers.
I am a UX designer specialising in forms. I design forms for people, but (usually) don’t build them.
Often I describe this distinction with the analogy of an architect versus a builder. An architect comes up with what should be built, the builder builds it.
In this parallel, it is important that an architect understands something of materials and construction methods. There is no point an architect coming up with something fabulously creative if it simply cannot be built (affordably or at all).
Similarly, I think it is important that a designer understands something of development. And developers should ideally understand something of design. That way, we can, as Vicky says, empathise with each other. But also—and perhaps more importantly—it allows us to have more constructive discussions where together we come up with the best solutions. Two people with their own area of expertise and no appreciation of the other’s are never going to be able to really communicate.