Wireframes: A Comparison of Purposes, Process, and Products
Panelists: Laurie Gray, David Heller, Jeff Lash, Anders Ramsay, and Todd Warfel
The goal of the panel “Wireframes: A Comparison of Purposes, Process, and Products,” shown in Figure 1, was to give people an opportunity to learn about different methods and determine what might work best for them.
Each panelist quickly made the case for a particular method:
- Todd Warfel—“Traditional Wireframing Methods”—Wireframes are useful for exploring and communicating design ideas to a broad audience—from designers to developers to executives. They are most appropriate when you are working with multiple clients, need a physical design artifact, don’t know HTML, but know wireframing tools, and need to balance behavior notes with illustrations. To make the most of wireframes, create templates, use multiple master pages, place behavior notes on a separate layer, include a document index and version history, and use storyboards for RIA transitions.
- David Heller—“Flash: Designing and Communicating for Time”—Flash prototypes are also appropriate for a broad audience. They are most useful for expressing interaction design for Web applications. Flash prototypes are dynamic, interactive, and narrative, because they allow you to show change over time. Flash provides drawing tools, supports object-oriented design, allows code reuse, and lets you create timelines. Flash doesn’t provide printed documentation. Best practices for creating Flash prototypes include prototyping screens; starting with basic wireframes, then adding visual and interactive detail; and using XML to create data sets.
- Anders Ramsay—“XHTML Wireframes”—Using XHTML and CSS to create wireframes of Web pages lets you represent structure, content, and presentation separately; leverage Web standards, use semantic markup, and focus on structure and hierarchy. XHTML is self-describing. Pros: rapid production, reusability, single-sourcing, fewer annotations, prototyping, knowledge transfer, and portability. Cons: requires knowledge of XHTML and CSS, requires early involvement of the entire design team, not well suited for rich media, and the separation of content, presentation, and code is fuzzy.
- Jeff Lash—“User Interface Specifications”—Specifications provide complete, detailed design documentation that can evolve over time and incorporate feedback from reviewers. For each screen, they typically include visual prototypes created using Photoshop® or XHTML/CSS and descriptions of its purpose, widgets, user interactions, and error handling. Specifications provide a “formal record of rules, patterns, and decisions;” communicate effectively to a broad audience; are universally appropriate, regardless of platform; separate design decisions from documentation decisions; and are easily printable.
- Laurie Gray—“Prototyping Tools”—Prototyping lets you quickly put together a working model of a design idea. Prototypes help you see holes in your design, show interactivity, and decrease documentation time, while increasing accuracy, but are time-consuming and complicated to create and may still fail to provide adequate information to developers. When deciding what prototyping tool to use, consider fidelity, speed of development, reusability, level of interactivity, level of editability, and portability.
A frank discussion of the pros and cons of each method followed. So, what method should you use? Jeff Lash summed it up: “I hate to say, ‘It depends,’ but let’s say it’s contextual.”
Wireframing Challenges in Modern Web Development
Panelists: Nathan Curtis, Livia Labate, Bill Scott, Thomas Vander Wal, and Todd Warfel
This panel discussion further explored the topic of wireframing. Livia described the successful use of low-fidelity wireframes as paper prototypes for usability testing. Todd described how they created the illusion of interactivity by using dental floss to pull elements through slits in the paper. Nathan suggested that we should think about our design artifacts in a systematic way. Bill advocated the use of visual design specifications and interaction design patterns, which together create a design vocabulary, and described an “interesting moments grid” that shows states and actors. The panel also discussed functional specifications, wireframes, storyboards, Flash prototypes, and much more. The discussion was much too lively and fast paced to do it justice here.
Lakoff’s Women, Fire, & Dangerous Things: What Every IA Should Know
Presenter: Donna Maurer
In her talk on “Lakoff’s Women, Fire, & Dangerous Things: What Every IA Should Know,”PDF Donna Maurer, shown in Figure 2, distilled the essence of Lakoff’s book and repackaged the information for designers. Thank you, Donna! She said, “We think in categories. Most symbols—words and representations—do not designate particular things or individuals in the world. Most of our words and concepts designate categories.” According to Donna, Lakoff’s book
- “is about categorization and cognition
- challenges the classical theory of categorization
- contains a number of core insights into the way categories work in our brains
- is fundamental for the type of work IAs do
- can be paradigm shifting”
Donna discussed classical categorization, cognitive models, prototype theory, challenges to classical categorization theory, and basic-level categories, then provided summaries of their implications for IAs.
Donna made the following remarks about prototype effects:
- “Recognize that they occur, and you’ll be less stressed about why categorization is not neat.
- ‘Miscellaneous,’ ‘everything else’ categories are cognitively real—just not easy to use as navigation.
- Use prototypical items when communicating. They are strong communicators, as they represent a category well.
- Use less prototypical items to describe edge cases.”
“Lakoff not only gives us new techniques for doing IA, he gives us a mechanism for reflection on the craft itself.”—Dan Brown”
The concept of basic-level categories is very applicable to the work information architects do. Donna had this to say about using basic-level categories:
- “Basic-level names are short and frequently used. Analyze user research data to identify them.
- Basic-level items are easily recognized and likely to have good scent. Use them as trigger words.
- Card sort with basic-level items rather than more granular content elements.
- Get people to the basic level of the hierarchy as soon as possible in navigation.
- Test navigation items for basic-level characteristics.
- I wonder whether folksonomy-based tags are basic level, accounting for their popularity.”
Donna’s talk was engaging and gave us some new perspectives on solving information architecture problems.