In our conversation over at Adaptive Path's site, Dan Saffer is grilling me about wireframes. He conceives of wireframes as having three kinds of information: the content, the annotations, and the metadata (like identifying information). The book cuts things up a little differently, and I promised Dan I would go into some detail here.
First, a quick definition of "layers". Every deliverable in the book is described in terms of three layers. These layers are more conceptual groupings than visual distinctions. I call them layers because I think of composing a document as applying layers of paint: putting down the essentials then embellishing as necessary. First-layer elements for any document are the essentials, the information that defines the document, and without which the document would be more-or-less useless. Second-layer elements add further detail, while third-layer elements are nice-to-haves and supporting information that provides additional context.
Here are the elements of wireframes by layer:
Layer 1: Wireframe Essentials
- Content areas
- Content descriptions
- Content priorities
- Identifying information
- Administrative Information
Layer 2: Filling in the Story
- Scenarios
- Links and form elements
- Annotations
- Objective and rationale
- Version history
Layer 3: Optional Details
- Layout and visual design
- Context in the overall design
- Sample content
I won't go into detail about each element here. There are complete descriptions of each in the book. In short, this is how wireframes break out in terms of layers:
The essential pieces of information for any wireframe are: what's on the screen and how important it is, which wireframe this is, and who created it.
Depending on the project, further information may be required. For complex web-based applications your wireframes might benefit from annotations to describe the business rules. Alternatively, if your site responds differently to different situations, you may want to include scenarios. For some clients, it's important to remind them what the purpose of the screen is, to avoid scope creep.
There are other types of information that designers might include in wireframes, but leaving them out won't necessarily hurt the wireframe. In some cases, these elements can be distracting. Design elements (like color and type) may cause clients and team members to to focus on that and not the content and functionality of the screen. At the IA Summit in 2005, I presented a poster describing the various issues associated with different kinds of sample content.
Does this jive with your use of wireframes? What information do you consider essential or optional for wireframes?