In Part 1, I argued that the need for a designer to know how to code what they create is based on the designer’s chosen professional path and the overall size of the project they are working on. This has resulted in a variety of great comments, both here on the blog and on the twitterverse. If you haven’t had a chance to read it, please check it out.
Having dealt with that side of the argument, I want to provide some thoughts on why it’s important for designers to know about code, understand what a development lifecycle looks like, and why knowing these two aspects of digital creation is vital to being a well rounded designer. As I mentioned in the previous post, my educational background is in Computer Science. There are very few aspects of the coursework that I use in my everyday work, but what I do use is the concepts and domain knowledge that came along with it. Because of the curriculum I have a fundamental understanding of Object Oriented Programming, System Architecture, and the theory behind programming languages and their structure.
How does that help me as a designer?
Having this knowledge allows me to understand the medium I work in, at its most fundamental levels. At a high level, I understand what the technical constraints are on a variety of technical platforms. This understanding ensures the final design isn’t super difficult or complex to develop. Later on in the overall process, when a developer challenges a design decision or offers up a suggestion, we can speak using the same language. We are able to collaborate more effectively on a problem because we have a shared understanding of the technical concepts that are required to make up a design.
How could this knowledge help you as a designer?
Effective collaboration
Being to speak the same language between you and another party is the first step to effective collaboration. This is something we do when working with users and business folks right? Why would it be any different when we are working with our technical peers? The good news is the craft of interactive prototyping is a great tool to use to facilitate a technical conversation. If you understand, at a fundamental level, how a particular interaction would need to be implemented, you are poised to better communicate that requirement to a technical team. Doing this with an interactive prototype isn’t the only option. As part of the interaction design spec, you could write out the interaction as pseudo-code. But, for the pseudo-code to be meaningful, it needs to be based on an understanding of the technical platform you are designing for.
More Marketable
It common to find that many User Experience Designers comes from either a psychology or traditional graphic design background. This background is necessary to effectively research user needs and behaviors, and to create a solution that meets those needs and supports those behaviors. However, if you obtain a working knowledge of the development side of things it allows you to contribute to areas of the design process that may not directly relate to user experience design. Also, your opinion on non-user experience design aspects of the system carries more weight. Other members of your team will put more trust in your designs and you, as they understand you’re not going to design something crazy and unmanageable.
Encourages Innovative Work
With solid foundation of what’s been done in the past and is currently being done within a particular technical platform, you are best prepared to design something new and innovative. Granted this depends on the project your working on, but innovation is possible on either the micro or the macro level. You will be better prepared to know when it’s time to break the rules and do something that’s disruptive or unfamiliar to either your organization or your audience. We already know this rule works out based on all the work that’s been done with design patterns. The best way to know when NOT to use a design pattern is to have an intimate knowledge of that pattern.
No Excuses For Not Learning
Knowing how to code what you design isn’t required to be a good, if not great, designer. But it doesn’t hurt. At the very least, a designer should have an understanding of the working fundamentals of the technical aspects of the medium in which he or she works. With the amount of information that is available online, in books, or even at local community colleges, the barrier to learn is very low. My recommendation to anyone that wants to beef up their skill set, or at least domain knowledge, on the technical aspects of the web is to pick up a book and build a “Hello World” application or webpage. Even doing something as simple as this will give you insight into what it takes to bring your designs to life and allow you to empathize with your technical peers.
If you are a designer who always goes to design conferences, break out of your comfort zone and attend a technical conference. Better yet, speak at one. It’s been my experience that technical conferences are very open to speakers from the design world. If attending, or speaking at conferences, isn’t your thing, go to local tech meet ups in your area. Not only is this a great networking opportunity for you but it’s a great place to find a mentor. It’s been said that to become a better design just design something. I’d refine this to say, “To become a better designer, design and build something…anything!”