To Code or Not to Code

John Kolko, a well-respected colleague in the interaction design world, just posted his thoughts on why designers must learn to code.  As he points out, he's not the first to suggest this, and in fact, there have been several conversations in blogs and on IxDA that I've observed over the years. For myself, having been a software developer and architect prior to moving into Design, I can say that having that background and the ability to understand not just code but the capabilities of platforms and the challenges of, for instance, working with asynchronous communication over the Web versus more direct, synchronous connections, latency, etc.--general software architectural considerations--does help. At the very least, it reduces some friction and iteration.

On the other hand, even with my dev knowledge and experience, I work with devs who I consider to be much more knowledgeable and wizards--they can code things that I can't, or at least things I'd have to spend a fair bit of time figuring out how to do. They're so good, in fact, that I still find myself asking for "too much" at times, with my faith in their ability to deliver. So the idea that a designer learning the basics of coding eliminating all of the "asking for the impossible" is not exactly a realistic sentiment, nor can the average designer I suspect become the code wizard they need to be in order to fully account for the design they want to express. The danger then becomes a designer who thinks he or she understands the limitations of the medium (based on his or her inadequate knowledge) preemptively precluding better design options.

John cites Jared Spool's earlier post on 3 reasons why learning to code makes you a better designer. Jared's first point is most compelling in my view--to better understand the medium you work in. I don't necessarily agree with his suggestion that this makes you "know what's easy" and what's not.  What may seem really hard to one coder could be child's play to another--because the latter has experience implementing a design like it.  In other words, it's about known versus unknown. I don't think it's helpful for a designer to try to guess at levels of difficulty up front. Even I have been surprised by this in both directions (sometimes I think something is hard that my devs tell me is easy, and vice-versa). It is helpful to know that something would require magic and is totally impossible with current technologies (e.g., mind reading or telekenetics), but it's not so helpful to try to guess, for instance, how long it would take to execute on something that at least seems possible. One of the common complaints I've heard from devs is designers asking for the impossible, so as long as a designer stays within the realm of the possible, a dev can help determine difficulty. Plus, it's important to realize the vast differences in experience and skill and how those can impact any particular dev's ability to execute (or even prototype) a design idea.

To Code

So should a designer learn to code? I'd say without reservation yes--learn to code something. Anything. Having just that much experience with some aspects of programming is helpful, but I'd say it's more important to learn the high level capabilities of the particular platform you're working in. It's not particularly helpful to be able to write a simplistic program in C#, to understand the syntax, or even how to create a domain model, what the differences are in type visibility, the difference between something being on the stack versus on the heap. That kind of knowledge is barely useful to a designer, but it's important for a developer. But just having some experience with flow control and basic data structures will help some.

On the other hand, learning what sensors are available on the devices that you are developing for, what they are capable of, what input modalities are available and which will be more commonly used, whether or not people will be connected all the time or not, how they will be connected, some basic grasp of what is executionally intensive for your environment, what kind of network latency you have to work with--these are important things to know as a designer that can meaningfully inform your design choices, even before anyone writes a single line of code. If you're dealing with existing data entities or services, learning what those are and what they are capable of, those are important and helpful. If you're dealing with browsers, learn about what the particular challenges and capabilities are of the ones you intend to support.  If you're going to spend time understanding your medium, these are the kinds of things that are far more useful than language syntax and "being able to code." 

Another benefit of learning about coding is reducing the language barrier between you and the developers and having some idea of the challenges they have to face will help smooth discussions.  But this one is definitely a two-way street--devs need to step up and learn the language of Design, and the basic concepts and concerns. I had the T-shirt above made. It can be taken two ways, but the point either way is basically the same:

1. A dev reads it and chuckles, "that's not real coding--there's a lot more to coding than that. It doesn't make you a developer."
2. A designer reads it and says, "yeah, that's the point, and being able to draw a wireframe on a whiteboard doesn't make you a designer."

The moral is that learning the basics of your complementary disciplines is helpful, but don't imagine for a second that understanding the basics makes you a professional. At best, it can help communication, and no matter what, a healthy mutual respect is necessary, including a deference to each other in what you are respectively good at (and paid for). A designer who has learned to code shouldn't presume to second guess her devs, and a dev learning design fundamentals shouldn't ignore his designer's designs in favor of what he thinks is a better design. 

Not to Code

Just as there are good reasons to learn to code, it is important to be mindful of the pitfalls. As I touched on above, there is some unavoidable bias that comes with knowing how to code. There are flavors of it. One is just eliminating what seems like a good, reasonable design because you don't know how to do it. Another one is the inverse--to choose a design just because you are familiar with it and think it is "easy." This latter is especially dangerous when you have to contribute to the code yourself or are under pressure of a deadline (and who isn't, right?). There is a time to make design compromises, and up front during design generation is not the best place for them to occur.  Take the time to explore even design concepts that are "hard."  Correspondingly, it is easy to get distracted in the "how" to make a design, when that is not appropriate. 

Another pitfall that I didn't immediately think of, but Jenifer Tidwell did (of the UI patterns book fame), is that when you learn to code, you might be asked to code more than you would if you didn't. It certainly depends on the company, but I can attest from personal experience and discussing with other designers that almost without exception coding is generally perceived as more valuable than design. After all, you can make software without Design, but you can't make software without coding. The outcome of coding is a product (bad though it may be); the outcome of Design, without coding, is essentially just an idea (freakin' awesome, though it may be) and "deliverables" of some sort that reflect the idea but are not the end product.

No one who knows him would say that Alan isn't opinionated, but the underlying gist of what he's saying is important to keep in mind--if even "professional" developers are commonly seen to be "criminally incompetent," it pays to keep in mind what was mentioned above--trying to guess at difficulty is not particularly going to be helpful. Ask a developer to estimate something he hasn't done before, and you will usually get a famously inaccurate guess. (How much more inaccurate will it be for a designer who has picked up some basics of coding?) When faced with an unknown, the most important thing to do is to prototype and prototype fast and cheaply. If it's a question of technical feasibility, do it on the target platform, get the dev who is going to build it involved. If it's a question of exploring interaction design, use the many tools you have to simulate a design and try it out.

This is where I depart from some of my colleagues in Design--learning to code so that you can prototype is not a great reason to learn to code. There are so many ways to prototype designs before writing code, and surely people will keep creating tools to help with this so that you don't need to code for this purpose. Sure, if no tools suit your needs and you have a very specific, high-fidelity design you need to test, then coding skills can come in handy. But the drawbacks of learning to code for prototyping are that you will be tempted to bypass lower fidelity when it is more appropriate, invest too much time and effort just coding a simple prototype, when you could effectively explore it with tools that don't require coding. 

If you learn to code (or worse, have a coding background), you have to actively guard against these pitfalls. Trust me, it takes time to break bad habits, and it is a challenge avoiding falling into new ones. If you are going to learn to code (or already know how), just keep these pitfalls in mind and do your best. You don't have to learn to code to be a good designer, but it can certainly help in many cases.  One thing I can totally agree with John on is that Design doesn't stop after the initial designs are done. It is crucial for designers and developers to work closely throughout implementation, and who knows, just doing that may begin, after some time, to give you the understanding of your medium (and your colleagues' perspectives and vice-versa) so that learning to code, as such, will be less important than it may seem at first glance.

First, be true to good Design; second, learn what you need to in order to see it through to completion. A great Design is pointless if it is not realized in the final product.