in Prototyping

New Article at Boxes & Arrows on Prototyping with XHTML

I’ve got a new article at Boxes and Arrows called Prototyping with XHTML. The article really came about because, time after time, I’ve found myself in conversation with a fellow UXer, and we’ll be discussing design methodologies, and I’ll tell them I’ve relegated wireframes to just being refined sketches, while instead specifying my design with XHTML. And inevitably, they’re curious and want to learn more. Problem is, there isn’t a lot written about this way of working, which is why I decided to write the article. That, however, is not to say that this is some methodology that I conceived of. On the contrary, I’m aware of many many others who work this way.

The first time I heard about designing with XHTML was in 2005 at an IA retreat in Asilomar, where Christina Wodtke bluntly proclaimed that we should “stop doing wireframes.” I was both skeptical and enticed. I had been doing wireframes for years, and was pushing the practice to an extreme with excruciatingly detailed designs defining every last element on the page, and annotating them in tome-sized specifications documents.

Christina later sent me the slides from her presentation, “First Things First: IA and CSS,” which she gave with Nate Koechley at WebVisions 2004, and which described a method for representing information architecture not with the familiar diagrams but instead with some kind of weird DIV tags and CSS classes and what-not.

Looking back, I think I my reaction to their ideas was like someone riding a horse and buggy for the first time being told about an automobile. I just could not fit the idea of using XHTML markup to communicate a design solution into my wireframe-based mental model of the IA practice. But at the same time, I knew that designing with wireframes is fraught with problems, from the lack of a standardized notation understood not just by stakeholders but, most critically, by developers, who have to build the darn thing based on them, to the confusing overlap between wireframes and design comps, to the abundance of information not inherently communicated in a wireframe that therefore needs to be explicitly explained in droves of labor-intensive annotations, that inevitably become out of date. And on and on.

So I tried to fit Christina and Nate’s XHTML-shaped peg into a wireframe-shaped hole, such as trying to get annotation references to appear ‘on top’ of the XHTML, which in hindsight is akin to early designers of the automobile creating steering mechanisms modeled after horse reins. In both cases, it was an attempt at working in a new paradigm with your mind stuck in the old one. But major forces of change in the last several years, in terms of how websites and related technologies are designed and built, served as the undercurrent that washed away old thinking. Most important of these are the migration among software developers from waterfall-oriented methodologies to agile and iterative methodologies, as well as the increasing predominance of web standards and all the best practices associated with it related to XHTML, CSS, and JavaScript as the pro forma method for building websites.

Today, I could not imagine specifying my design with traditional wireframes. Yes, they are still part of the process, but they function as explorations of an idea and not the instructions of what to build, and are discarded once the design has evolved beyond them. When designing the user experience for standards-based websites and applications, I am instead using the same technology developers use to implement the product—XHTML, CSS, and JavaScript—as both a prototyping and specification platform. So, for an introduction into what that all means, check out the B&A article.