Designers should know how to code… (yawn)
Recently I tweeted “A [web] designer who doesn’t code is like a print designer who doesn’t understand bleed, creep, halftones, trapping and paper finishes.”
It instantly got retweeted and quoted around the design community, for a few brief exhilarating moments of wonder my push notifications were going crazy. It generated some good responses, some negative comments and provoked some interaction with a few trolls. I lost a bunch of followers but I gained a lot more a few hours later. Of course, my opinion is that I firmly believe that a digital product designer can’t be fully successful without knowing how to code (by this I mean, html/css, understanding the principles of coding and a degree of javascript for prototyping). Again, I’m talking about coding in the context of being able to code and understand the principles. I don’t mean designers should be front end developers. I don’t mean designers have to be great coders. A designer who codes doesn’t have to be a designer who ships code or writes any production code at all.
I had considered how the tweet was worded. “A designer who doesn’t code…” is fundamentally different to a “A designer who can’t code…” because “doesn’t” shows a degree of unwillingness. If somebody is unable to code but willing to try then that represents somebody who has the mindset of a good designer.
You may be thinking I’m reading quite deeply into one of the 340,000,000 tweets sent that day. But it came across to some as elitist. Because it was elitist. I meant what I said but the way it was said reflects a problem with the industry and how dogma is stifling debate. Wording it this way doesn’t help anybody.
I could have said “Are you a designer that wants to code? I’ve just written an article containing some reasons why it will help you”.
We’re discovering new things, doing groundbreaking work and building amazing products in quite a unique period in history. There is no better time to be a designer. Yet after fighting for years against bloated processes and trying to become more lean are we now process obsessed, dictating how things should be done, what type of way they should be done; designers should code, web pages should be responsive?
But what’s wrong with that? Well, there’s certainly tremendous value in documenting and publicising new learnings, methods and establishing standards. But there’s also a land run of designers and developers staking claim to new methods and phrases. Sadly it often appears to be for the sake of our own egos rather than progress. There are standards that need to be set and those that discover new things deserve due credit but a degree of elitism is choking potential collaboration. Are we starting to channel our thinking by clamping down on processes? Are we focusing on our design approaches rather than the end goal? Should a website be responsive, adaptive or should we just consider its ubiquity?
Is the outcome that jargon is slipping into our world? Are we intimidating new designers by focusing on design processes instead of thinking about what we’re designing? New designers should learn principles not jargon.
What do you know about how I work?
Some of us don’t have the choice in what workflow they adopt. We may not have the choice in what constitutes an MVP. We definitely don’t have the choice of who we work with. We may do remarkable work but are hindered by internal processes and pressures. The stakeholders and product owners may be happy to ship something in a certain state that we ourselves consider unfinished and gut-wrenchingly awful.
Do we consider the context when we rip somebody else’s work apart? Sure, there’s bad design and some terrible ideas and experiences out there. But sometimes the app you’re looking at, the desktop site that breaks apart in the palm of your hand, the awkward “Please close this page and view on a desktop computer” message may have been the only way to bridge a development phase while still using some ghastly legacy CMS that your product is governed by. There may be just a few days until the next release where a conscientious design team has solved the problem and are about to roll it out. Often there are many factors out of the control of a well-meaning and talented designer who had to ship. Not everybody works for a startup. The reality is that if you’re not building something new your decisions will often be about compromises along the way to releasing your design vision (which often may feel like even the Universe won’t exist by the time it launches). You know your product and the compromises you may have to make, other designers often will have to make similar sacrifices or cringe temporarily while things out of their control are forced to happen. I guess ultimately we should critique, but don’t complain. This way we’ll not contribute to cultivating a fear of failure and the thinking that “everything has to be 100% right.”
You need to get out more
As a community we’re suffering from device fatigue. Who thought that we’d end up designing for devices as diverse as fridges? More articles and resources than ever are appearing and keeping up with the momentum of change in the design field takes a lot more than skim reading a couple of articles each week. Frameworks, boilerplates and grids need to be tested, experimented with, played with and learnt from. There’s so much good work to be done so why waste your time fighting petty battles over which way is the right way to do something? You may have the time but it’s probably better spent descaling the kettle.
Design’s about breaking the rules not adding them back in.
Our language shapes us
Terminology is very important. Of course, an important part of design is being cautious about the terms we use because they can shape our thinking.
Every human being is unique in a myriad different ways. One way we differentiate ourselves from each other is by our names. Our names play the most vital role in our overall individuality. But there are other Bens. There are other Susies. There are other Ruddagars. We never come face to face with two people that we know called John and get totally confused. We have the capacity to understand who is who since their name alone is not what differentiates them in this particular context. We do this by absorbing the little bits of information all around and working out the differences in a fraction of a second.
In a similar way we may be shaped by unnecessary naming conventions and terminologies. We will definitely be shaped if defining them is our motive. Do we really need to debate over what the differences between responsive and adaptive design are or whether break points should be called tweak points or which grid to use/not use?
Semantics matter. But during a unique period of discovery design’s about figuring stuff out and solving problems with the available information and practices around us and adapting it to our own unique requirements. Patterns, semantics and paradigms are tremendously important. But sometimes you have to look beyond a method or even beyond a name.
Are we more concerned about building with terminology over building something ubiquitous?
You may recall that I said I gained more followers than I lost when Tweeting about designers who don’t code. Would I have been better off if I’d never tweeted and kept the people I originally had?
We’ll keep discovering but we won’t always be right. Design is about humility and a willingness to fail. Let’s not discourage it.