The software tools of the Interaction Design field, specifically the design of applications for spaces, non-consumer facing post-production tools, and the array of screen-ready digital devices, that access content running directly on the web or through downloadable native applications, are rapidly changing.

Some tried-and-true best practices and deliverables of the field survive, while others cease to accomplish their goal effectively, in communicating design direction to project managers and  engineers.  New graphics and vocuabulary, for instance, to describe gestures for touch-screen devices, are now routinely a part of design documentation for applications that are built on that technology.  But that is not enough for every application’s unique needs.   While an abundance of the applications, past and present—in the realm of 2D forms, flat text, and buttons—can be wire-framed and spec.’d out to a ‘T’, many of the emerging applications pertaining to 3D gestural interactivity, data visualizations, and other modalities of interaction and presentation, can no longer be properly conceptualized or prototyped on paper or within a traditional desktop publishing application.  

Fortunately for designers, there will always be WYSIWYG design applications and templates to aid in the creation of new design deliverables.  However, bringing these tools to market won’t move as fast as technology changes.  Another way to look at this, is that once these templates or pre-built solutions exists, much of the design process is phased out, and the need for design becomes less so.  So for the application designer who wants to be on the cutting-edge of technology and add value to new design domains, getting one’s hands into code—the very language of technology—can offer a great benefit to the design process.

Henceforth, the way we as application designers understand the function of code, needs to be reassessed.  Traditionally we associate code as part of the development process, which follows design.  But code can also coexist or even be merged into the design process.  This possibility with code in design is not a new one, however it can benefit from being reassessed periodically, given the rapid advances in technology and tools.  One age-old argument, is that programming is better left to a more traditional development workflow, however not all creative exploration translates to project requirements and engineering best practices.  Some programming efforts may be better off guided by art direction or other kind of design oversight.

At some point in the future, I want to present a couple of tutorials, where I address specific cases in which I’ve depended on programming to do my job as an application designer.  This certainly isn’t the case for every project that I encounter—I still wireframe for form-based applications all of the time, and recognize this planning format as a likely staple for application design, even a hundred years from now.   But as a general guideline, if I can’t fully imagine or describe a concept in a wireframe, that properly communicates an idea to an engineer, than I attempt to code it myself—be it a simple prototype or in some cases, what becomes the end solution.  These kinds of challenges are among the most exciting and difficult that I encounter as an application designer, and I am eager to shed some wisdom.