Michelle recently pointed me to a blog entry where Paul Fresty of Optiem explains why he hates wireframes. And I can’t say I blame him. Apparently, at his company, the Account and Project Management teams create wireframes on their own and hand them off to designers. The wireframes may even be shown to clients before the designers have had any input. So I really have to agree with Paul — that sounds awful.
But I also have to speak up in defense of wireframes when they’re done correctly. We’ve been wrangling with this at Bridge, and I think we’re reaching a point where everyone’s starting to feel comfortable. Let me hit on a few of the things we’re doing differently:
- Wireframes are created by Experience Planners, not Account or Project Management.
When we create wireframes, we don’t just capture the priorities of communication, and we don’t just put things on a page to suit our whims. Creating wireframes is a process that involves careful weighting of the priorities of communication, consideration of user needs and goals, usability best practices, and our instincts as web professionals. I would also argue that Experience Planners are well qualified to make wireframes because of our knowledge of the site’s content. In our company’s process, wireframes come after the site map, so we can tie the general callouts on the home page to specific pages within the site. - Wireframes are created in collaboration with Creative.
Experience Planners lead wireframe creation, but we work with Creative throughout, even before the first line goes down in Visio. In an ideal project, I’ll sit down with the Design and Copy Directors before I make wireframes to review the brief and get their thoughts on the project.
Do we need to explore a non-traditional site layout?
Is there a Big Idea that ties the site together?
Are there any key points that we need to hit in the copy?
Then I’ll put together a wireframe that makes sense based on our discussion, and review it internally.Only after everyone feels comfortable, we’ll take the wireframe to the client and explain how they should understand what they’re seeing. Yes, it suggests layout, but it’s not the final layout. We’ve tried to set up the page so it reflects the priorities of communication and the user’s needs. When the designer’s get to it, we may decide to make some changes, but only if we have good reasons.
- We believe usability is important enough to get its own step in the process.
Most really good designers I know create several thumbnail sketches or mockups before presenting a final design. They do this because it’s easier to explore options and make changes to a sketch than a pixel-perfect design concept. At Bridge, we feel the same way about usability. It’s so important that the user experience is right, we take the time to make wireframes before design concepts. We review the wireframes with the client to make sure it meets those objectives and, if there’s time and budget, we take the wireframes to consumers to make sure they’re able use the site the way they expect.We could jump straight into design and figure out where everything goes and how it works while we selecting colors, fonts, images, and tone. But chances are we wouldn’t give user needs enough consideration in that process.
All that said, I do agree with what Paul said about wireframes at his company. For his situation, Page Description Documents make a ton of sense. (Good explanation and examples of PDDs in Dan Brown’s Communicating Design.) I just think proper wireframes would be even better.
I’m curious about other agencies’ experiences with wireframes. Have you had similar difficulties? Did you end up ditching wireframes entirely, or did you work out some kind of compromise?