On Designing Behind the Curtain
On a recent interaction design mailing list to which I subscribe, someone launched an extensive thread with this post:
As an Interaction Designer I think it’s a foundamental matter to have a deep knowledge of “how it works behind the scenes” what we design for people to use.
The question is: which language (HTML, Java, Javascript, DHTML…) do you think an Interaction Designer should be fluent in and at which level?
It’s a thought that has crossed my mind many times, and presumably others, since it lead to a flood or responses. It’s also not the first time this kind of post has shown up on the list. My response was as follows:
A great thread going on here! I wanted to share my insights/ experience, especially given the unusual place I’ve find myself in professionally during the past couple years.
These days my freelance work is largely divided between UI/UX efforts, where my core deliverables are wireframes, site-maps, etc. and then something referred in as *Creative Coding*—it doesn’t really have a working label as of yet. In this second role I design/develop tools in OpenFrameworks (C++) and Processing (Java) to generate graphical elements for television commercials, print advertisement, and installations. It’s not work that’s in constant demand, but when it is, there’s a small handful of designer/developers, who are called on to it do it, largely for companies with a presence in the tech industry. Another way to describe what I do is that that I write code to make rich, sometimes generative, techy images, that would be incredibly difficult to create by hand or in Photoshop. On these projects I typically work with art directors and often resort to quick-and-dirty code, because I’m not trying to create a bullet-proof app—I’m often just trying to crank out an element or two that comes closest to what the client is looking for. These elements then get exported, and finally inserted into the commercial or print ad. Then you’re done. There’s no user testing, just ratings to follow. I enjoy coding in this capacity, because it puts me in the design seat, though it’s difficult to define best practices, since it is a fairly niche role.
Recently though I was asked by a client to design and develop an application that the compositors could use to generate video elements on a television commercial. This put a whole new spin on things. Suddenly I had to take some of the best practices from other work in UI/UX and apply them to an app I was responsible for building from start to finish. This quickly became a much larger task, as you might imagine, and I had to make some compromises to the usability of the application, that wouldn’t have been acceptable outside of this realm, but were fine in the commercial world of lightening fast turn-around.
On some other more traditional UI/UX projects (web apps and so forth), that aren’t for fortune 500’s, the coder in me has tried to work my way into a development seat of sorts, while designing the application at the same time. This usually is a response to the design not looking or behaving the way I’d described within the final visually treated wires. I follow-up by suggesting some CSS to engineering. When that doesn’t help, I write the HTML/CSS myself, and finally, when things still don’t match up, I wind up in the environment committing changes and so forth directly, tweaking Javascript, etc. At this point, things can become quite a headache, as I’m spending some of my time deploying changes with the engineers, while spending the rest of time designing what’s next. I start to see my design choices impacted and compromised by their level of difficulty in terms of implementation, which does not always lead to the best overall solution.
The takeaway here, and coming from a relatively code-savvy Interaction Designer (who actually loves coding), is that as a designer, unless you are working on a project like a microsite or some specialized non-customer facing app, where the design and development are both in your hands, it is probably not wise to go so far as to be committing code changes within the actual environment. You will likely find yourself in a world of frustration. You may also find your creativity pushed to a more granular level that requires an entirely different discussion. On the other hand, if you have the inclination, it might be a good exercise to try. The farther you push your role, the more you are going to learn. In retrospect, I could have handed off engineering non-dynamic HTML pages with styling and basic scripts, but instead I got my hands dirty working in an ever-changing, dynamic app, with some components that only work server-side. Then when I found I’d made enough changes to the build, I eased back into the more traditional wireframe/designer role. On a future web project for a company like Microsoft, I will never have this kind of opportunity (nor would I want to), but at least I can shed a little bit of past engineering wisdom into my deliverables, and understand the limits of what is possible with currently technologies.
In closing, to an interaction designer who wants to learn to code, I recommend checking out www.processing.org . It may not give you a coding background that translates directly to the applications you would design in the real world, but it’ll open your mind to the world of variables, arrays, and objects, and give you appreciation for the fact that the web is broken up into separate layers to manage different pieces of an application. It may also lead you to do some out-of-the-box thinking in terms of the way your expertise in UI/UX could apply to other domains.
