Section 12.4. Wireframes


12.4. Wireframes

Blueprints can help an information architect determine where content should go and how it should be navigated within the context of a site, subsite, or collection of content. Wireframes serve a different role: they depict how an individual page or template should look from an architectural perspective. Wireframes stand at the intersection of the site's information architecture and its visual and information design.

For example, the wireframe forces the architect to consider such issues as where the navigation systems might be located on a page. And now that we see it on an early version of a page, does it seem that there are actually too many ways to navigate? Trying out ideas in the context of a wireframe might force you back to the blueprint's drawing board, but it's better to make such changes on paper rather than reengineering the entire site at some point in the future.

Wireframes describe the content and information architecture to be included on the relatively confined two-dimensional spaces known as pages; therefore, wireframes themselves must be constrained in size. These constraints force the information architect to make choices about what components of the architecture should be visible and accessible to users; after all, if the architectural components absorb too much screen real estate, no room will be left for actual content!

Developing wireframes also helps the information architect decide how to group content components, how to order them, and which groups of components have priority. In Figure 12-11, the information architect has determined that "Reasons to Send" is of a higher priority than the "Search Assistant." This priority is made clear by the content's prominent positioning and the use of a larger typeface for its heading.

Figure 12-11. A wireframe of the main page of a greeting card site


Wireframes are typically created for the site's most important pagessuch as main pages, major category pages, and the interfaces to searchand other important applications. They are also used to describe templates that are consistently applied to many pages, such as a site's content pages. And they can be used for any page that is sufficiently vexing or confusing to merit further visualization during the design process. The goal is not to create wireframes for every page in your site, but only for the ones that are complicated, unique, or set a pattern for other pages (i.e., templates).

Note that wireframes are not limited to describing pages. Figure 12-12 shows two stages of a user's interaction with a pop-up window.

Figure 12-12. Wireframes can represent any type of content


Wireframes represent a degree of look and feel, and straddle the realms of visual design and interaction design. Wireframes (and page design in general) represent a frontier area where many web design-related disciplines come together and frequently clash. The fact that wireframes are produced by an information architect (i.e., a non-designer) and that they make statements about visual design (despite being quite ugly) often makes graphic designers and other visually oriented people very uncomfortable. For this reason, we suggest that wireframes come with a prominent disclaimer that they are not replacements for "real visual design." The fonts, colors (or lack thereof), use of whitespace, and other visual characteristics of your wireframes are there only to illustrate how the site's information architecture will impact and interact with a particular page. Make it clear that you expect to collaborate with a graphic designer to improve the aesthetic nature of the overall site, or with an interaction designer to improve the functionality of the page's widgets.

We also suggest making this point verbally, while also conveying how your wireframe will eliminate some work that visual designers and interaction designers might consider unpleasant or not within their expertise. For example, just as you'd prefer that a designer select colors or placement for a navigation bar, you've relieved the designer of the task of determining the labels that will populate that navigation bar.

Finally, because wireframes do involve visual design, their development presents a perfect opportunity for collaboration with visual designers, who will have much to add at this point. Avoid treating wireframes as something to be handed off to designers and developers, and instead use them as triggers for generating a healthy bout of interdisciplinary collaboration. Although collaboration slows down the project's schedule, the end product will be better for it (and besides, it may save you time during the project's development).

12.4.1. Types of Wireframes

Just like blueprints, wireframes come in many shapes and sizes, and the level of fidelity can be varied to suit your purposes. At the low end, you may sketch quick-and-dirty wireframes on paper or a whiteboard. At the high end, wireframes may be created in HTML or with a publishing tool like Adobe Illustrator. Most wireframes fall somewhere in the middle. Let's review a few samples.

Figure 12-13 is a relatively low-fidelity wireframe; there are no graphic elements and no real content. This enables the visual designer to focus attention on the global, local, and contextual navigation elements of the page.

Figure 12-13. A low-fidelity wireframe developed by MessageFirst's Todd Warfel; note that all content is "greeked up" to ensure a focus on layout of content and visual elements


Figure 12-14, from a redesign project for Egreetings.com, is a medium-fidelity wireframe with a high degree of detail. This wireframe was intended to introduce several aspects of content, layout, and navigation into the discussion, and was one of many wireframes used to communicate the information architecture to managers, graphic designers, and programmers.

Figure 12-14. A medium-fidelity wireframe for Egreetings.com; more detail, more explanation, and more unique content


Finally, Figure 12-15 is a relatively high-fidelity wireframe that presents a close approximation of what the page will actually look like. This is about as far as most information architects can go without bringing a graphic designer into the picture.

Figure 12-15. A high-fidelity wireframe for Weather.com


Such a high-fidelity wireframe has the following advantages:

  • The content and color bring the page to life, helping to capture the attention of your clients or colleagues.

  • By simulating actual page width and font size, the wireframe forces you to recognize the constraints of an HTML page.

  • The fidelity is sufficient to support paper prototype-testing with users.

On the other hand, some disadvantages are:

  • Higher fidelity requires greater effort. It takes a lot of time to design such a detailed wireframe. This can slow down the process and increase costs.

  • As you integrate visual elements and content into a structured layout, the focus may shift prematurely from information architecture to interface and visual design.

Provided that you recognize the strengths and weaknesses of these varying levels of fidelity, wireframes can be an extremely powerful tools for communication and collaboration during the information architecture design process.

12.4.2. Wireframe Guidelines

Chris Farnum, a former colleague at Argus Associates and a wireframe expert, suggests the following best practices to consider when creating wireframes:

  • Consistency is key, especially when presenting multiple wireframes. It ensures that clients will be impressed by the professionalism of your wireframes. More importantly, colleagues take wireframes quite literally, so consistency makes their design and production work go more smoothly.

  • Visio and other standard charting tools support background layers, allowing you to reuse navigation bars and page layouts for multiple pages throughout the site. Similarly, Visio's stencil feature allows you to maintain a standard library of drawing objects that can be used to describe page elements.

  • Callouts are an effective way to provide notes about the functionality of page elements. Be sure to leave room for them at the sides and top of your wireframes.

  • Like any other deliverable, wireframes should be usable and professionally developed. So tie your collection of wireframes together with page numbers, page titles, project titles, and last revision date.

  • When more than one information architect is creating a project's wireframes, be sure to establish procedures for developing, sharing, and maintaining common templates and stencils (and consider establishing a wireframe "steward"). Schedule time in your project plan for synchronizing the team's wireframes to ensure consistent appearance, and for confirming that these discrete documents do indeed fit together functionally.

For an excellent discussion of information architecture deliverables and wireframes and additional information, see the IAwiki (http://iawiki.net/WireFrames).




Information Architecture for the World Wide Web
Information Architecture for the World Wide Web: Designing Large-Scale Web Sites
ISBN: 0596527349
EAN: 2147483647
Year: 2006
Pages: 194

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net