Article summary
“Should software designers code?” I have heard this question asked over and over again within the design community. There’s not a definitive answer, but if we extrapolate the question and ask it in a few different ways, I think we can better understand the role a designer plays in writing code for projects.
Should Designers Understand Code?
Absolutely. Code is a language, and while there are a lot of languages, they share similar structures and rules. The important aspect is that code, no matter the tech stack, has rules and best practices.
With these rules and best practices come limitations, or great cost to develop. Being able to talk about some of these limitations, but more importantly, accept that not everything can be accomplished in a particular stack, will greatly help a designer when discussing options or viability for a feature with a developer.
Should Designers Write Code?
Maybe, but probably yes. Understanding some basics of code, even if it is just hacking through the inspector, can allow the designer to make quick changes, right within the browser, that are rendered in real time. It doesn’t take much of an understanding of HTML or CSS to start changing attributes on styles, or removing/adding elements to a page to see what it affects and how.
To be honest, that was the best way I learned how to code—that, and finding a lot of answers on Stack Overflow.
Now I will hack together a quick page in HTML, CSS, and jQuery to test interactions, animation timing, and element sizing. None of this is production-level code. It’s not properly formatted, it’s not optimized for speed, and barely any of it would/should be used by the development team. But they could use my prototype, or even parse the code, to get an idea of the desired outcome.
(Some people believe that, in the future, practially everyone will know how to code. Children’s games and toys are already incorporating the concept of coding or programming. Much like being bilingual in traditional language is important, having the ability to speak “code” could very well become a necessary skillset, and not just in building software.)
Should Designers be Required to Code?
No. Production-level code is a skillset that takes developers a lot of time to master, and even more time to keep up with new technologies as they come into the market.
More importantly, such a requirement would limit a designer’s ability to come up with solutions. If designers are only designing within the parameters that their development skillset allows, they might not be fully exploring all of their options, as they would through other forms of rapid wireframes and rapid prototyping.
Couldn’t designers figure out how to build it?
Well yeah, they could, in time. But in a world of timelines and budgets, forcing a designer to learn a new development technique or hack something together produces poor results that take more time and money to develop. Would you ask your plumber to also do your electrical work? Sure, he or she could figure it out, but you’d still be paying by the hour, and the result might not be ideal.
Now, Let’s Flip the Script
There is a lot of pressure on designers knowing how to code, but should that be a two-way street?
Should Developers Understand Design?
Absolutely. Just like code, design is a language. As designers, we have rules and structure, not necessarily dictated by limitations of technology, but by established and proven interaction patterns. Designers don’t (read shouldn’t) make decisions on the way a feature functions without a specific purpose. We strive to meet mental models and expectations and work to validate any assumptions.
As a developer, having a basic understanding of Human-Centered Design and focusing on user goals can go a long way toward creating productive collaborations and getting buy-in from a designer.
Should Developers Produce Designs?
Maybe, but probably yes. Design is such an abstract word, and much like code, there are varying levels of fidelity or refinement that can go into creating a prototype. Sketching wireframes on a whiteboard or mapping a workflow in a visual manner is an important skill to have and utilize.
Here at Atomic, design is a team sport. Having developers contribute, in some fashion, to early wireframes or design critiques is important, and it generates the best results. Having designers and developers agree on how a feature should work goes a long way toward getting buy-in and understanding when “real” development starts.
Should Developers be Required to Design?
Absolutely not. Just as designers shouldn’t be required to code, developers shouldn’t be required to define feature requirements or produce final mock-ups and documentation. Especially when it comes to final UI, we have developed a refined skillset utilizing design elements like hierarchy, color theory, balance, space, unity, etc.
While developers are ultimately responsible for the feature working, designers are responsible for determining if the feature should be built in the first place. Putting that dual responsibility of how and if on the shoulders of one person or a team of developers is unfair.
Finding Balance
In the end, it comes down to finding the right balance of responsibilities. If you are a designer who is comfortable opening up a text editor and coding, and you can utilize that ability in an effective and responsible manner (budget, timelines), then go for it.
If you are a designer who is unwilling to try to understand what your development team has to do to implement a feature, this might not be the industry for you. Going back to my traditional print design days, I may have never been able to operate an offset printing press, but I understood how it worked, its capabilities, and the expense to produce a design.