I got into a spirited discussion on Twitter with some designers this weekend. I don’t know why, as I don’t often get sucked into Twitter debates, but the topic at hand was of interest. As we went back and forth, it dawned on me that it may be of interest to our clients as well.
Basically, the argument circled around the position a designer took on Twitter, stating that “design” and “development” are being combined into a single discipline and that is a bad thing.
I take the opposite point of view. Designers that can code are not only the future, they’re better for clients and agencies in the long run. They add value to teams by bringing a multi-discipline approach to the table, removing one cog in an already complex machine of development and production. This, in turn, translates to clients in the form of faster work product with less billable time and to agencies as the ability to streamline front-end production.
To understand why this makes sense, you have to look back at how the Web itself developed into its current state. In the past, designers would work solely in tools such as Photoshop to render “mock-ups” of website designs. Those designs would go to clients for presentation and approval. After a revision process was finished and approvals were granted, the designs would go to developers to code and implement into HTML.
Back in the day, most teams utilized the same developer for both back-end and front-end efforts. It was easy for a back-end developer to “slice” HTML, as the language and technology was not complicated. Most websites were consumed solely on desktop or laptop computers, so a fixed resolution was utilized, such as 1024x768 or 800x600.
However, over time, technology changed and delivery methods began to expand to include mobile, tablet, and other types of devices. This ushered in the era of “responsive” web design, where web pages would begin adapting their experience based on the device on which they were being viewed.
With that advancement, languages such as CSS, JavaScript, and HTML became much more advanced. In addition, front-end packages slowly became available and grew in popularity such as Bootstrap, jQuery, and hundreds like them, which added complexity to front-end development. Over time, it became clear that front-end web development was no longer just an annoying step for a back-end developer, but rather a discipline of its own, something that required deep knowledge and understanding.
At this point, front-end and back-end development divorced—though today’s technology is trying again to bring them back together…sorta.
While logical, this separation made the development world much more complex. In many ways, the technical advances of the internet have slowed down the development process in that it added new skills and team members to a process that was already multi-dimensional and required many different players. As a result, one particular area of project turmoil is often the hand-off of creative design to front-end developers.
This is where the idea of designers who can code comes into play.
As technology advances, capabilities advance. And that means designers can do much more with the medium we call the Web. As such, websites today contain more than just pages that scroll and contain text and images. They are experiences unto themselves, and designers have become quite adept at utilizing these new capabilities to craft stunning interactive. It’s an exciting time to be both a developer and a consumer of digital products—especially in comparison to 1999!
However, this new technological shift has coupled front-end development to the complete opposite end of the spectrum than where it started. Now, front-end development is design-centric, not necessarily a technical component.
If the folks I was arguing with on Twitter are reading this, I have thought about a few reasons why a designer who can code is more valuable than one who can’t. And I believe there is a benefit to everyone from the client to the consumer.
First, a great designer already must know the capability of code to be effective. Otherwise, there is a disconnect when they hand off their designs. How can a designer render a cutting-edge experience if they are unaware of the capabilities of tools such as JavaScript, CSS, and HTML? They’re just throwing darts in the dark if they don’t have this understanding.
And it can’t be just a top-level understanding. To be truly capable, you have to understand the depths of these languages and how they translate to a visual display. This means knowing down to the HTML attribute what code can and can’t do. And you need to understand the differences in browser experiences, and how devices can render the same code differently. A designer who is not up to speed with this knowledge is doomed to waste time, present concepts that aren’t even achievable, and ultimately, derail a project.
One could say that a designer who is unaware of the capabilities of code is more of a liability to a project than an asset.
Secondly, the collaboration between a designer and a developer takes a lot of time, effort, and resources. It isn’t unusual for a designer to spend half their time documenting their work for a front-end developer, a task both parties find lacking in creativity and relatively mundane. Once that tedious step is done, the front-end developer will begin rendering according to their understanding of the documentation.
<sarcasm> Surely, this will end up working well! </sarcasm>
In this scenario, the designer is almost like a client of the front-end developer, and an entire new level of communication and collaboration occurs that can result in disconnects. This is avoidable if the designer can simply implement their own code. They can avoid the excessive documentation, communication, and QA. It’s one person doing all of the work, and so there is less room for error and miscommunication. After all, it’s hard to misunderstand the intent of the designer when that designer is you.
Finally, designers who can code can also work in a more agile fashion, in some cases skipping entire steps of the process to iterate faster. For example, old-world design methodology included designing all pages in a project. Today, a designer can code based off of wireframes and a “north star” view of the project from a design perspective. This means that instead of presenting customers with design renderings, they can actually deliver coded pages that are reviewable via web browser, giving clients a view of actual progress in an interactive setting. It’s a much more powerful presentation for both parties, and it gives a proper preview of the entire experience as opposed to just images. With responsive design, it makes life much easier. There’s no need to mock up each scaled format for clients; you can just code out the entire experience and they can test it themselves—all with lower budgets and faster time to delivery.
Now, this isn’t to say that there aren’t projects that could benefit from a separation of these skills. Of course there are. If a project is of a large enough scale that requires these tasks to be performed in a waterfall process or similar, it makes perfect sense to have two separate parties handling different parts of the project at hand. There is simply never a hard and fast rule about resource allocation. But a designer who can code is a much more valuable player at an agency or enterprise because they have the ability to perform essential tasks themselves without bogging down the work of their colleagues.
So, how does this affect you as a client and consumer of digital services?
Well, the first is that you should have a sense of security knowing that designs you see and/or approve are actually buildable because the designer who laid them out is capable of making them work in a practical setting. There isn’t a big risk of your designs changing later because you approved something that isn’t buildable. And your overall project billings should be lower, as implementation time has been reduced.
One last major benefit of this approach doesn’t come into play during an initial build-out, but rather in a maintenance or continuous improvement setting. If you are a marketer that is concerned with improving your lead generation efforts, what workflow is better for you? Receiving designed assets for you to approve or revise, then sending for back-end dev, and finally integration into a platform? Or simply working to iterate a developed HTML file that you can experiment with in a production environment faster and without additional development resources? The answer should be obvious.
I don’t think it’s a bad thing for designers to guard their craft and capabilities. No one wants to be told that to be effective, they now need to specialize in more than one area. But the reality of the situation is that designers and developers are here to drive value for customers, and it’s hard to claim that you are going to deliver value when your workflow is slower and your time to iterate is longer than someone who is capable of more efficient production.
Of course, if you disagree, you can tweet me @pjczech and we can debate it further!
