Wilson Miner’s comment about wireframes today on Twitter inspired me to start a conversation in response to the issue of separating visual design and layout from the wireframing process. I have a solution I came up with, but I want to see solutions you might have come up with, too. You show me yours, I’ll show you mine.

This is a common situation I have heard and seen several times in my short time as a User Experience Designer, and it’s not just when the person creating the wireframes is the person doing the visual design. I don’t think the problem lies so much with who creates the documents, but more with the documents themselves.

Standard wireframe documents look so much like a web page layout, we ask viewers to use immense amounts of imagination to divorce that which the wireframe is trying to communicate from what its visual representation is communicating.

Sometimes regular wireframes are just right

In the book Communicating Design by Dan M. Brown, the Challenges section of the Wireframes chapter starts out with the encouraging sentiment, “Even five paragraphs won’t do justice to the challenge of wireframes…”

He goes on to explain that the main problem with wireframes is when they try to do too much, serving multiple purposes at the same time. The key, in my opinion, is to decide what the essential purpose is for your wireframe documents. Different purposes might require a different format.

I think there is a place for the standard wireframe format. In a recent project, I created a wireframe for use as a paper-prototype in user testing. The document was a wireframed mockup of a few pages of the site, with pretty detailed illustrations meant to represent actual interface elements and layout. This worked very well. Users were able to imagine what the elements would look like on a page, show us how they might interact with it, and we got some great feedback to move forward into actual site planning.

This also translates to the interactive prototype, in which the sketched elements are taken into Flash, HTML+Javascript, Powerpoint, or some other on-screen device allowing the viewer to interact with it, further mimicking how the finished product might look and behave.

When going into granular detail about the interface elements of a particular component, it makes sense to have detailed sketches approximating those elements and their various states. Using simple illustrations is much easier than a written description, and is quicker for the planning stages than building the elements out in their full graphic detail.

Where the wireframes are

I will confess: Until about two years ago, I had never seen a wireframe. I had heard the term thrown around in the ten years that I’ve been involved in the field of web design, but I had never had reason or opportunity to see or use one.

Wireframes aren’t needed for every project. For a small site and a small team, sometimes a sketch and some verbal agreements are all you need to get the job done.

In the last couple years, I took a job with an agency that was just beginning to take on large Web projects, working with larger teams, sometimes with external resources, often under tight deadlines. Documenting complicated functional decisions quickly and communicating these decisions accurately became a priority.

Though I had no formal training in UX documentation, I had a passion for user-centered design, experience with basic Web development, and a solid understanding of best practices in usability and interface design. This foundation helped me take on my new role as UX designer, and therefore I also took on the job as the agency’s main wireframe resource.

I did a lot of research on UX design, Information Architecture, Interaction Design, and the deliverables I’d be expected to produce. I had a difficult time finding very many examples of different kinds of wireframe documents. Some are out there, but many you have to dig to find, and most of what I could find all looks the same.

Why aren’t more people showing wireframes?

• Much of this work is internal, often confidential.
• Most people might consider the stark black and white renderings unappealing

I can’t think of any other good reasons for keeping these documents under wraps. The confidentiality reason is understandable, but I disagree that these documents are unappealing. I understand the thought that goes into these documents, and I want to see the results of this labor.

In my research, I did find an article that inspired me a great deal. It’s an article titled Where the Wireframes Are published at Boxes and Arrows on July 1, 2002, by the same Dan Brown mentioned earlier.

In the article, Dan Brown talks about his company’s struggle with wireframes causing conflict between his team and the designers, or causing confusion with clients. The creative director asked him to “take design out” of the wireframes, and the rest of the article describes his solution.

I identified with the struggle he described, with wireframes as a mock page layout conflicting with the designers’ role in the project, as well as with client confusion when shown wireframes but being asked to ignore the visual and layout elements. Here it is, years after his struggles with his clients and internal team, after publishing the article and later his excellent web site documentation book, and I can’t believe we are all still using the same format of all-purpose high-fidelity wireframing, and struggling with the problems it can cause.

In Dan Brown’s article, he proposes a solution he calls a Page Description Diagram. This solution works for when you want to document only the contents and the functions that should go into a page. He takes out any semblance to layout, and just lists, in order of priority, the elements that should go on a page, describing the necessary information for each element.

I was really inspired by this example. It impressed me how different this approach is, and how it can so efficiently get the job done, when the job is just to describe the contents and their priority on a page.

Designing the User Experience

When I was granted the title of User Experience Designer, I was actually given the unique opportunity to research roles and decide what I wanted my title to be. I took some time and put a lot of thought into it. Am I an Information Architect? An Interaction Designer? Interface Designer? Usability Research? Some of those things, yes, a little bit of this, a little bit of that. User Experience Design, to me, touches all those fields and more.

I agree with the Jesse James Garrett view of user experience as described in his book, The Elements of User Experience, and how he portrays all the elements overlapping and influencing one another to create the overall experience. In this book, he puts wireframes into the realm of page layout, which is “where information design, interface design, and navigation design come together to form a unified, cohesive skeleton.”

Where I work, we have a development team, a design team, copywriters, and clients, who all need to give input and sign-off on documentation, so wireframes have to be a bit of a multi-purpose resource for them to be worthwhile. They also have to be quick to create and update, while still being thorough.

Keeping in mind the cautions given in the Challenges section of Dan Brown’s book, I’ve set out to create a system of documentation that meets all these requirements. While I need to avoid bringing in too much design to this part of the process, I want to be able to give recommendations that affect usability, so I can’t completely ignore page layout in my wireframes.

I’ve got a lot to show you, so I’m going to pause here while I get the rest ready. I believe I’ve discovered a solution for wireframing that combines elements from those examples that inspire me, takes things that work, and leaves out the things that cause too much trouble. For the time being, though, I hope this will start a conversation and get some other people inspired to show their own solutions. I can’t be the only one looking for answers to these common problems.

Show me your wireframes!