deeplocal: Design and Development for Humans and Machines

As a designer, people are sometimes surprised to learn that I write code. A good friend of mine is a talented furniture designer, and I doubt anyone is surprised that he understands joinery and actually makes things. It makes sense: to design a good chair, he has to know how chairs work. To me, we’re both doing the same fundamental thing, developing fluency with our materials.

So why is it that so many interaction designers don’t program? (I’m not going to delve into a dissertation about what interaction design is; in this case, I’m referring to designers who work with people and digital machines.) In my experience, interaction designers tend to be among the humbler, or at least nerdier, subsets of creative professionals, so I don’t think it’s that we feel designing software mechanics is beneath us.

I think the challenge is that, until relatively recently, the barrier to entry into writing software was dauntingly high. I remember my sophomore year of college, after finishing a semester and a half of introductory programming classes. I had learned all about variable types, data structures and principles of object-oriented programming, but I still had no idea how to actually program anything I could actually see. Disheartened, I dropped programming and went back to my diagrams and screenshots.

Then something happened. I took a programming class for artists and designers, taught with Processing, an open-source Java library and IDE for visually-oriented programming. Suddenly I wasn’t implementing arraylists and sorting strings, I was editing pixels and animating shapes. Suddenly I wan’t limited to conveying interaction through indirect descriptions, I could specify interaction explicitly, through code. Approaching programming as hacker, rather than as a computer scientist, lowered the barrier to entry because I was focused on the end-experience rather than the computational theory.

Hacking has it’s limitations. As I learned more about software, Processing and I eventually had a falling out. As many developers have criticized, larger programming projects just became too unwieldy to manage inside Processing. It’s like trying to write a novel on post-its. So switched to writing programs in “real” java, and then C-based languages, along with some web development (less hacking) and microcontroller programming (lots of hacking) somewhere in between.

Recently, Dave and I were working on an iPhone project, and hit a couple nasty bugs. The app was compiling and running error-free, but things were just not happing the way they ought to be. So I paid a visit to my old friend. By making quick proof-of-concept sketches in Processing, we could quickly isolate, test, and solve problems, and port the code back into our main project in Xcode. As Nathan would put it, it allowed us to let poor solutions fail quickly, so we could develop better ways to solve the problem.

Processing works best as a prototyping tool. It’s allows programmers to put aside lower-level optimization and strict object-oriented principles and quickly hack together some code that works. Hacking makes it easier to approach code as a beginner, and faster to “sketch” ideas as a more experienced programmer.

For design, understanding basic programming is as important as drawing, diagramming, speaking and Adobe-ing. It’s another means to communicate ideas and, moreover, it’s sometimes the only way to accurately describe digital interactions. For development, I think it’s important to differentiate between prototyping and production. If you’re building a proof of concept that won’t be part of production code anyway, don’t be afraid to hack it.