From a perspective of sheer design labor, the most difficult part of bringing a new Web site to life is production. At that point where the major design challenges have been resolved (what the home page and a few other key pages look like, how the site feels) and when those resolutions have been approved by the stakeholders, designers then apply that solution across all the constituent parts of the site: marketing pages, content pages, forms, search interfaces, etc. Typically, this is done with Adobe Photoshop or, recently for me, Macromedia Fireworks, in a fairly painful process of rendering “flat comps”; creating static, visually accurate representations of what the XHTML should render while also suggesting, rather awkwardly, how the interface will respond to user interactions.
Does this sound like a drag? It is, especially for sites with dozens of pages, like the ones we often do at Behavior. It’s not so much that the work itself is drudgery. It’s not; in fact, this work is the crucial evolution between concept and reality, when the design ideas put forward in early comps are expanded and embellished upon to create a fully-fledged system of interrelated parts. In production, the design becomes real. What’s a drag is how much effort it takes to build all of these flat comps; you could spend weeks trying to address all of the design problems that a site presents and iterating on those solutions continuously before even getting to the first line of XHTML. I’ve done that.
The Shortest Distance from A to C
So, I’ve been thinking a lot about ways in which to expedite the production process: methods of simplifying the labor or perhaps eliminating the need for that labor altogether. Rather than spending a lot of time and effort creating what are essentially guidelines for the final product, why not leap directly to the final product? Why not skip right to the code? In spite of its clumsiness, XHTML markup is one of the most direct forms of design execution available, and it’s just begging to be used with a sense of immediacy.
There’s a school of thought that advocates this as the leanest, most immediate way to achieve real results, and in many ways, it’s enormously attractive to me. But I’ve tried it — at least some imperfect approximation of it — and I’ve failed at it. I ran up against low-level browser incompatibilities, diverting time I should have been spending on creative problem solving towards the tweaking of CSS hacks. I’ve run up against the natural inclinations of clients to continually tweak designs and request new layouts that would fundamentally alter the markup I had thought was solidified. And I’ve run into inhibitions on my own creativity, fear of undertaking design solutions that might be too demanding of my coding skills or my time. For these reasons and more, it didn’t feel natural.
The Anal-Rententive Design Chef
Part of my failure can be laid at the feet of my fussy, nit-picky style of design — I have a tendency to pursue the placement of every last pixel until it conforms to some master plan. That master plan is continually evolving, and as cumbersome as flat comps can be, they are at least flexible in terms of continually and non-committally refining the rules of a design system. Moving too quickly to HTML would be in effect prematurely codifying those design rules; I just need lots of time to ruminate over them beforehand.
But part of it too is my own belief that, in essence, design is a process of decision by proxy, that virtually all forms of design are essentially frameworks for decision by proxy. Whether the principal design document is a mechanical, as in the pre-digital days of graphic arts layout, or blueprints, as in architecture, we are almost always creating only a representation of a product, not the product itself. We’re almost always at a certain remove, almost always laboring over interim deliverables that will be ultimately tossed aside.
But what attracted me to interaction design in the first place is the reduction of that remove, how it’s possible to have an idea and execute it in code and almost immediately arrive at the finished product. There’s no other design medium that facilitates that transition from head to hand with quite so much expediency, while also requiring so few raw materials. And with that distance narrowed so sharply, there always exists the temptation to remove the proxy altogether, to actually start molding the actual product without the blueprint. I’m not saying it can’t be done — I whole-heartedly endorse anyone who can manage it — but for me, I just need that proxy.
+