More often than not, designers have rightfully been accused of retreating into their cocoons of ignorance as soon as their work of creating a web design is finished, leaving the dirty and more hands-on work of putting it up on the web to developers. This apathy is prevalent not only in the web-building industry, but also in software and game engineering.
The hard truth is that the buck of development should stop with designers. For optimum efficiency, designers should not only be concerned with painting the bigger picture but also building it! In this article, I’d like to share with you some reasons why designers should learn how to code.
Designing Realistic and Doable Designs
With a clear image of how the final product will be actualized, a designer will come up with more feasible and practical concepts. Being an integral part of the development process, they carry the responsibility of ensuring their designs translate well into a web-based medium that takes into account: usability, web accessibility, and achievability. A user-friendly website is not only a picnic to navigate from one page to another in a clear and concise flow of logic, but also provides a user with all the information they need without being too overbearing or cluttered. The only real way to know if a web layout works or not is learning how to build it yourself.
Virtually all products designed but implemented by different parties never satisfy both sides’ expectations, especially when it comes to intangible products like websites, software, or games. It normally comes down to a compromise between what it should have been and what, in reality, it can be. Whereas the general idea is captured, it is seldom replicated verbatim. The panacea: designers should preach water and drink it too! This avoids confusion, misunderstanding, and misrepresentation.
Convenient Iterative Development Process
A design, in practice, should not be absolute. By this, I mean that it should be flexible and affable to change without distorting its intrinsic essence to meet the systems’ technical constraints. These repetitive and necessary alterations can only be realized by the original designer. A designer slash developer can iterate more quickly where necessary, rather than having a developer resubmit the design to the designer, who is rarely at hand, to implement the alterations. This situation can create friction – and it often does – between designers and developers.
Better and More Harmonious Results
I often like drawing parallels between software, web, or game development to orchestral music where the designer is the composer and the developer is the ensemble’s maestro or conductor. Imagine if the latter had the composer’s score? Wouldn’t the symphonies be awesome, captivating, and unadulterated? Not only were they crafted by a master craftsman, but conducted by their creator!
Shorter Development Time
The designers doubling up as coders implies that the design and coding processes occur at least sequentially, if not concurrently. This results in a shorter development timeframe – and who doesn’t care about efficiency?
Designers become More Marketable
Modern day designers worth their salt need to up their portfolio, and up their game, if they want to remain relevant; it’s no longer enough to have one set of skills. Oftentimes, we’re required to wear various hats: designer, front-end developer, content writer, and project manager.
By learning to implement what you design rather than leaving it orphaned in the hands of developers – you increase your value. After all, citing design and coding skills in one‘s resume does not hurt. On the contrary, it makes one less redundant and indispensable, a life and death determinant in these financially tumultuous times of corporate restructuring (read: mass retrenchments) and downsizing (read: firing).
However, in so much as designers should also code their innovations, there are downsides to this scenario.
Quoting Lukas Mathis in one of the controversial article about the topic called "Designers are not Programmers"1:
If the designer implements his own designs, he is beholden to two different goals: Clean code and great user experience. These two goals contradict each other. If you have to implement your own designs, you’re bound to compromise for the sake of code quality, which is bad for your interaction design.
Designers who implement their own designs face two issues: They know when a neat new idea will create messy code, and they know about all the existing code that would be touched by a change to the user experience. The two goals are at odds, because the user experience is all about the little details, and those little details all end up being messy bits of code you would rather not have to write.
This aptly summarizes the hard stance taken by web development purists. They are of the old school of thought that advocates for clear-cut lines between design and development. Apparently, designers create for humans, developers create for computers. Thus, UX designers should design the best possible user interface and leave the developers to make the best possible programming decisions. While this holds some merit as I’ve found myself trying unsuccessfully to abstract my mind from the code when I’m working on a user interface, it is ultimately more convenient to have the technical and usability constraints in perspective.
All said and done, the scope of a project under development may ultimately decide the designer’s and developer’s role. A small application can be pertinently handled by a program manager2 while a large system will definitely need specialized personnel!
References and Footnotes
 Mathis, Lukas. "Designers are not Programmers ". ignore the code.
 Spolsky, Joel: A term he used to describe designers-cum-programmers. "How to be a program manager". Joel on Software.