Designers And Developers: No Longer A House Divided

These days, both design and development are fragmenting into more and more specialized, nuanced disciplines. There is almost no such thing as a web designer anymore; one is an interaction designer, a visual designer, a user experience designer or something else entirely. The word “developer” ceases to carry meaning, too. What kind of developer? Back end, front end, full stack, iOS, Android, web or something else entirely? Job titles have become more specific, and yet skill sets are expected to broaden.

Developers needs to understand design, and vice versa, but neither wants to give up what they love most about their own discipline. It’s easy to fall behind, to feel pressured to keep a foot in each world. We might want to learn to code or design, but code what? Design what? Each framework or design principle has its own unique dependencies, an entirely separate set of balls to juggle while we learn. Furthermore, without a way to practically apply it — within our work or outside of it — that knowledge is easily lost. A designer or developer looking to learn the other discipline can easily become intimidated and confused about where to begin, no matter how many initiatives and resources are out there.

Cameron Moll tweeted about this feeling in early January, capturing very well the expectation of designers and the emotions that come with it. It also begs the question, why is there no similar expectation of developers, of teams, managers, project managers or any other member of the team? Why is the emphasis not being placed on teamwork and collaboration, on fostering a shared understanding based not on technical knowledge, but on interpersonal knowledge? Surely, strengthening interdisciplinary collaboration would create far more effective teams than teaching designers a coding language or teaching developers the ins and outs of Illustrator.

Then…

Four years ago, way back in 2010, Elliot Jay Stocks tweeted his surprise that web designers still exist who can’t code their own designs. Treehouse cited that tweet in its article “5 Good Reasons Why Designers Should Code” and in the context of the time, it made sense. CSS3 hadn’t happened yet. HTML5 was still a twinkle in the W3C’s eye, reaching its first public working draft only in 2008. The term “responsive web design” would be coined only four months later.

While it was an exciting time, the idea of a designer learning to code wasn’t entirely overwhelming, at least in retrospect, and it was about to become the norm. But the expectation was clear: “Learn to code” meant “learn HTML and CSS,” or learn enough of it to bring designs to life. Similarly, “design” was restricted to the Adobe suite and creating flat comps of website designs. There was a solid line between disciplines, but that is no longer the case.

… And Now

Things have changed, and quickly. The landscape of learning is shifting, too. Along with the aforementioned CSS 4 specification, which offers even greater control of styles, a whole host of resources are now popping up that are encouraging designers to learn how to code — and code everything. It’s not just about bringing a static web page design to life anymore. There are courses for iOS development and prototyping, and places such as Fast Company offer guides on how to get started, in case you’re at a loss. There’s Ruby on Rails, too, and the data visualization movement is continuing to gain traction.

It’s not just about turning PSD to HTML anymore, but about developing for iOS and creating web applications in Ruby or AngularJS or whatever else your company or customer is using. Design and code blur into one another with exciting concepts such as SVG animation and the various data visualization libraries. But this is just a drop in the ocean of possibility, and we can’t possibly be expected to traverse it all. Susan Robertson writes on A List Apart about being overwhelmed by code, by “the constant pressure to learn new things and keep up with all the latest ideas.”

This pressure isn’t surprising, but it is avoidable. To make sure that what we learn will be useful to us, we have to ask ourselves why the learn-to-code movement exists in the first place. It exists to foster inter-departmental communication, to make the process of creating a product that much smoother. So, perhaps, rather than focusing on understanding the mechanics of each other’s work (coding languages and Photoshop etiquette), we should focus on softer skills, on improving collaboration and communication from a holistic perspective. Learning each other’s discipline is only a part of this.

Finding A Common Foundation

As a starting point, we need to balance the expectations on both sides. Yes, designers should understand the workflows of development, but the same is true of developers (and project managers and whoever else is involved in a project). They don’t need to learn the details of Photoshop or Sketch or color theory, but knowledge of general design principles and processes is useful and will ease collaboration and communication. We can only become better designers and developers by learning to communicate better with one another.

Stephen Caver at Happy Cog agrees, saying that developers need to acquire an eye for design and encourage this empathy among teams. Stephen made the transition from design to development himself and offers the perspective of someone who has been on both sides of the fence, and he understands that the fence needs to be torn down. Similarly, Sam Hernandez, also a developer at Happy Cog, acknowledges the unique communication challenges of developers in particular, but he also says that star developers do not avoid them; rather, they find ways to communicate and collaborate with the non-technical team. These developers are empathetic not just towards design, but towards the product and client as well. They see beyond the minimum viable product.

Meanwhile, the design world is now seeing movements such as Brad Frost’s atomic design — design initiatives that borrow concepts from object-oriented programming. Designers can (and should) leverage tools such as Zeplin and Specctr to better communicate their designs to developers. Smashing Magazine offers a guide on creating design specifications that would be useful to the developer but not too time-consuming for the designer. The co-creation of style guides is an exercise that helps both designer and developer and that promotes understanding of each other’s discipline. The act of creating the style guide together is what is most valuable to this relationship between designer and developer, not necessarily the end product.

We forget sometimes how similar design and development are, both of which boast creativity as their foundation. Great designers and developers see creativity as a key part of their craft, but the connection between the two is rarely made. The term “creative” is used exclusively (and erroneously) to mean “designer.” Great code is its own form of artistry, and it is expressive and beautifully elegant when done well. In my opinion, a great solution to a development challenge shows ingenuity and imagination just as much as a design challenge shows logic and science.

Developers look at designers and see artists, while designers look at developers and see mathematicians or scientists. While this may be true at the surface, it does both professions a disservice. During a project, an excuse of “I’m not artistic” is accepted from a developer who isn’t interested in design, while “I’m not a coder” is not accepted from a designer. These excuses are reductive and unnecessary; creativity is an undercurrent of both disciplines, and the sooner we appreciate this, the better.

Mindsets, Not Technical Details

So, once we scratch the surface, we begin to realize that the learn-to-code movement, despite its ubiquity, is a small cog in a much larger collaborative machine. Picking up a language or grasping the basics of Photoshop is arguably easier than learning effective collaboration and communication. It is more quantifiable, more discrete, with a beginning and an end, but it might not always be useful. The emphasis should be on empathy, collaboration and shared understanding — softer skills that aren’t quantifiable, but far more wide-ranging.

Paul Lloyd states, “Instead of viewing ourselves in terms of discrete roles, we should instead look to emphasise our range of abilities, and work with others whose skills are complementary.” We should bring developers into kick-off meetings, and designers to backlog meetings. Brad Frost reminds us, “The modern web design process requires intense collaboration between designers and front-end developers,” and though he advocates for HTML and CSS specifically, this can be expanded to other languages and frameworks, as projects require them.

This communication and cross-disciplinary empathy are just as important as the techniques, methods and development frameworks used to take apart a problem. If a designer learns FramerJS to better communicate their ideas to developers, or if a developer jumps into Photoshop or Invision or CodePen to illustrate why a particular solution would or wouldn’t work, this is an example of using the tools around us to expand not just our own internal knowledge, but our knowledge of others. We focus so much on technique and method that we sometimes forget to remember and to internalize what was learned from the process on a human level, rather than a technical one.

We want to demystify development for designers, and vice versa, build bridges rather than burn them, get rid of the reductive excuses and gain an appreciation for the alchemy of creativity and logic that both designers and developers are products of. This is the kind of learning I want to see in the future. So, let’s learn not how to code or design, but how to communicate. Let’s meet each other halfway.

Meeting Halfway And Moving Forward

In this environment, becoming overwhelmed is easy. It’s difficult to choose what to spend our spare time learning, to make sure that our career benefits in the long run. Designers should learn as much code as they’re interested in learning. The same goes for developers with design: Grasp just enough to foster a relationship, not to be a great designer — you don’t have to be. Mastering each other’s discipline doesn’t matter as much as learning each other’s process and quirks. There is also no guarantee that the coding or design we learn for one project will be useful (or even relevant) in the next, which can be disheartening. There’s no need for a designer to go through a full course on Ruby if none of their forthcoming projects would benefit from that expertise.

Make no mistake, however, the efforts required to better collaborate and empathize are hard. An interpersonal learning effort is just as (if not more) difficult than taking a class on development or design. We don’t finish it with a project or an app prototype, something that is easily evaluated. It is continuous, but just as important. Designers and developers share so much — creativity, passion, a genuine motivation to create great digital experiences, apps and interfaces — and we have spent too long creating a cultural divide between us. We should work next to each other and share wins as well as losses, share processes and mindsets, ask questions in order to learn our coworkers’ quirks, strengths and curiosities. Balance specialization and generalization.

Personally, I’ve been afraid to specialize. The favor exhibited towards jack-of-all-trades, particularly in job postings, is implicit and is often overwhelming. I wasn’t sure what would be most useful to learn, and it all takes time — I didn’t want to make the wrong choice of language, paradigm or framework. Learning interpersonal skills wasn’t even on the agenda; it should have been.

Having arrived at Myplanet, I’ve found the sprint retrospective to be an incredibly useful guide for my own development, be it in code, interaction design or interpersonal relationships — I can ensure that I’m improving in areas that matter. Within our retros, we discuss what’s gone well and how to build on it, what hasn’t gone well and ways to improve. This kind of constant adaptation was new to me, but it was exactly what I was looking for. In this way, I’ve learned that whatever skills I develop are of practical use, and I’ve found myself worrying far less compulsively about specialization, generalization and the myth of the unicorn. Whatever I learn on the side, I learn because I want to, not because I feel I have to.

For example, as a result of retros, our team has co-located in order to facilitate communication. I brought up some worries I had about the technical side of a project, and as a result got the opportunity to learn more about Drupal. I also know which method of communication to use (verbal, email, Skype, NERF gun), according to whether my developer colleague has headphones on or what time of day it is. This seems obvious, but it’s the kind of information that we don’t get unless we ask for it, and I find it just as valuable as learning to code. Retrospectives aren’t always easy, and they’re just one example, but whatever technique we use, learning that empathy is important.

As the industry fragments further and further into specialization, unicorns no longer exist, and nobody should aspire to be one. Instead, specialize in what you love, and learn what sparks your creativity and curiosity. Learn whatever helps you to execute your vision or opens up a world of possibilities. Foster appreciation for each other’s craft, rather than attempt to learn something you don’t care for. Resources crop up every day: Bret Victor’s Learnable Programming and Dynamic Pictures, as well as iulang, HackDesign and many others. Use them to get to know your team, to collaborate with them, rather than mirror them.

This personal knowledge is far more transferable than any one programming language or design principle. Learn how your colleagues think and why they indent code the way they do or why they choose certain typefaces over others. This is the kind of learning that is invaluable, the kind of personal improvement that I believe makes us far more accomplished than learning the intricacies of coding frameworks or typographic differences when the person next to us already knows that. Learn collaboration and appreciation, and we’ll all be the better for it.