The Problem with Wireframes

I've written before that I enjoy creating wireframes, but that doesn't mean that I see them as ideal tools.

The very characteristic that makes wireframes so helpful—that they integrate content, engineering, visual design, information structure, interaction design and UX in a single document—is also their biggest liability. Expecting a single individual to possess all of the requisite skills to create them is unrealistic.

A solution would be to make wireframing a tightly collaborative effort, with practitioners of the various arts working side by side. But have you ever worked on a project with such a wealth of time and resources? I thought not.

One of the most intriguing alternatives to wireframes are page description diagrams, introduced in 2002 by Dan Brown in an important Boxes and Arrows article (which included this excellent poster). And yesterday, D. Keith Robinson added his own perspective and experiences with page description diagrams. It's a must-read—and includes some thoughtful comments.

I haven't yet tried page description diagrams, but typically complete what I call "page descriptions" before drawing wireframes. These text documents inventory page content and interaction, summarizing its purpose and role, listing every element, and specifying all entrances and exits. While they feel like a duplication of effort (and can be a real headache to keep current during multiple iterations), engineers especially appreciate them as a source for more detailed information than wireframe callouts permit.