Red Cherry Calgary Web Design

Red Cherry Calgary Based Web Design Company Discusses Designers and Developers Are No Longer a House Divided

As the web continues to evolve at a breakneck, Moore’s-law pace, the divisions between traditional design and development are increasingly shifting.

 

Calgary, AB -- (SBWIRE) -- 07/06/2015 -- The "learn to code" movement is also gaining momentum among designers, but we'd be hard pressed to find a similarly strong movement for other disciplines within a team. Perhaps there should be.

We should all be striving to learn, but the question remains, what exactly should we learn? Maybe it isn't as simple as "learn to develop" or "learn to design," but is about learning to communicate and collaborate, to respect the nuances of each other's craft — and the artistry and reason that they both demand in equal measure — without attempting to master it for oneself.

The editor's draft of CSS 4 arrived in early February, and while the possibilities are exciting and plentiful, it's very easy to be overwhelmed by them. We're still fully exploring the fringes of CSS3; for those just starting in the coding world, just knowing where to start can be akin to finding a needle in a haystack. This growth and progress is both a blessing and a curse, and it raises questions about the lines between design, development, creativity and logic, how the disciplines fit together and where we fit in.

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 we'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 our 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.

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.

About Red Cherry
We are a digital marketing and software agency that stands out from all other agencies. Our team of talented and creative individuals work closely with us to deliver rich and engaging solutions that drive qualified traffic to our website and convert that traffic into sales. Red Cherry has offices in both Kelowna, BC and Calgary, AB. We work closely with them to develop a comprehensive digital marketing campaign for Facebook, Google, Twitter, Remarketing (largest ad network), Pay Per Click, SEO, and more. Providing website design in Calgary for over 10 years.

We are also a full scale software development firm specializing in web development and apps development.

Let's chat 888-401-6668 or visit http://www.redcherryinc.ca/