What Should Wireframes Contain?
We all struggle with this question at one time or another
Should wireframes contain:
Exact copy?
Images?
Color?
CONTRIBUTE!
Have something to say about experience design, art, architecture, the weather, etc.? Write for MNteractive!
9 Comments
It depends. ;o)
Only slightly more helpful than Darrel, I’d say: As little as possible.
As little as possible.
no color, no real copy (although I have found that lorem ispum text blocks help the client visualize better), and I often use blank boxes to indicate image placement but only if necessary.
otherwise, absolutely no style, color, or formatting whatsoever.
Also, all wireframes should contain duplicate comments.
As I’m not a full time IA, my opportunities to use wireframes haven’t been as frequent as I’d like.
However, the one time we really got to embrace the wireframe, we basically did what the Cody said. We kept things greyscale with lots of borders turned on (to block off areas).
What we found, though, is that over time, we began adding a bit of color here and a bit style over here and before long, we actually built the final HTML templates directly from the wireframes.
The benefit was that we ended up with a visual design that was ‘just enough’ and the client spent a majority of the process focusing on functionality and business needs.
I wish that process wasn’t as rare as it is…I still fine projects that become burdensome due to 80% of the effort being put into photoshop mock-ups rather than strategic thinking and tweaking.
I think that if the copy has been well-developed before the wireframe stage, use it. Images & colors tend to distract (people get hung up on the aesthetics instead of function), so I’d be more cautious about including them.
Wish I could do more wireframes myself. I’m in the middle of a Photoshop noodle-thon web design project as we speak. It’s sad, because 50 to 100-layer .psd files are what customers expect right out of the gate, through no fault of their own.
Ah Wireframes. Generally,
1) they should be structured around content types, actual content. In some situations, we develop two sets: one set has what I call “demonstrative” content to show an actual visualization of a real scenario, so the client can catch a vision. The other is all meta descriptive and annotation heavy, for the development team;
2) They should contain as little visual information as possible and still communicate requirements. Black is for display methods, page frames, text, outlines, asset boxes, general forms. Blue is for hyperlinked content items. Grey is for content or functionality that is OUT OF SCOPE but essential to display context. Red is for annotations. Again, one set of annotations for the client and one for the dev team (the latter is much more specific and detailed); and
3; They should display special page states or display methods with slight color field (we’ve used light yellow) to distinguish them from default page states.
Working on a vast array of project types has helped us develop this simple straightforward approach. It seems to work very well, regardless of the knowledge or experience of the client in IA/UX process.
My first sentence should say “…structured around content types, NOT actual content…” Apologies for the typo.