Another perspective on our industry’s debate about designers learning to code
We’ve all spent a lot of time over the last year or so debating (or watching others debate) about this idea that designers need to learn to code. This argument sometimes makes it sound like we as “coders” are already impeccable designers who would never need to consider brushing up on our design skills. It also continues to imply that a designer and a coder are different roles. I believe that it depends.
What is a designer?
As far as the web is concerned, I used to think a designer was someone who spent time in Photoshop making comps of a web site. They would be focused on things like layout, color, and typography. And in that sense, I used to consider myself a designer, since that’s what I did. And even though I have always coded my own designs, It was always the stuff that dealt with color and layout that I considered to be “design”. Now, I don’t think any of those skills make me a designer, even if they are tools for design. So then, what is a designer? Better yet, what is design?
Design solves a problem.
When I realized this, it woke me up. I had all the skills to build a web site, but that didn’t mean I was a designer. It didn’t mean I was solving problems. Sure, when I started out, I asked my clients what they wanted in a web site, and built a few pages. But I wasn’t consciously identifying their problems from the beginning, and I certainly wasn’t setting out to design something that solved those problems specifically.
So, back to our question: What is a designer?
A designer is anyone who is tasked with focusing their energy on solving a problem or a set of problems. This can be the task of a single person, a team, or even an entire company. In fact, companies that create web sites to solve the problems of other companies are in the business of Web Design. If we’re good, we continue to get new work based on our ability to solve problems. Need to increase your visitors? We’ll design for that. Need to increase your sales? We’ll design for that. Need to gain loyal subscribers? We’ll design for that.
So, should Designers Code?
In my opinion, this question is phrased wrong, and it forces the person answering it to answer with the wrong perspective. To me, the real question is “Should designers be able to implement their own solution.” Now that’s a question we can answer. And to that I say, we will always live in a world where some designers can implement their own solutions, and some can’t. Because of this fact, the answer will always be “It depends.” And I believe that if we do not accept this, we will not move beyond this argument. Anyone who is stuck on one side of the fence of this argument is not seeing beyond their own immediate situations. This is not a question that’s limited to the web industry. Our industry just happens to be in an interesting time.
We will always live in a world where some designers can implement their own solutions, and some can’t. Because of this fact, the answer will always be “It depends.” ...If we do not accept this, we will not move beyond this argument.
What do I mean when I say it depends? What I mean is that it’s not so much about shoulds and shouldn’ts in regard to skills so much as it is a matter of resourcefulness. People come up with solutions to problems all the time. Implementation is the hard part right?
Implementing A Design
Implementation bridges the gap between a design and its solution. Sometimes we actually call the end-product a Design, when really it’s the result of design and implementation, a solution. So, a design is not a solution until it is implemented. Some people only go so far as to identify the problem, but others are fully capable of coming up with their own solution. In either case, what do people do if they can’t design or implement? Well, if they’re serious, they hire someone. In the web industry, sometimes we’re hired for the full deal. We’re presented with a problem and we need to design and implement a solution. Other times, we are brought in maybe just to implement a design.
A design is not a solution until it is implemented.
It’s at this time of transition where design tapers off and implementation ramps up that roles become a little fuzzy. What should these roles be? Well, it’s a matter of resourcefulness, not skills, so the question becomes “How well can you collaborate?”
Now we’re getting somewhere. The reason we keep asking the same question over and over might have less to do with the fact that people should learn additional skills, and more to do with the fact that we should learn how to work together differently. There’s really no need to get all exostential here. If the people responsible for designing a solution are not collaborating with the people implementing that solution, there will always be room to debate this notion that one should learn more about the other. But, if you think about it, what are you doing when you’re collaborating? You’re learning from one another. There will always be organizational structures that have some people more focused on solving a problem, and some fully dedicated to implementing the solution. When you collaborate, there’s less room to make assumptions on your own, and more opportunity to make informed decisions together. When you collaborate, you rely on each others expertise. You uncover the limitations that you have to work within.
There’s certainly no down side to a design-minded individual learning more about the skills needed to implement something. However, I think there’s much more progress to be made in our ability to adjust our organizational structures and workflows to allow for better collaboration. Let’s stop dragging old workflows into each new project and ask what needs to be done to solve the problem. Let’s redesign our workflows around skill sets as a way to encourage learning new skills. Let’s collaborate.