Conference Review: IA Summit 2007: Part I

Day 2: WebPatterns: Design Patterns in Web Site Architecture and User Interaction

Presenter: John Allsopp

John Allsopp (shown in Figure 4) gave an impassioned talk about his WebPatterns project. Starting with current practice, he told us, “Designers are using ID and CLASS to add semantics” to common elements on Web sites, but we have no shared language. For example, common IDs include unique page elements like footer, header, logo, banner, content, main, container, and search; common classes, things like title, help, section, menu, text, copyright, and links.

John advocated for the development of a common vocabulary: “It’s important for a vocabulary to emerge out of practice. … It doesn’t work for someone to dictate vocabulary. … There are all these tremendous advantages to getting a common vocabulary. A common vocabulary will facilitate maintaining or building sites as a team.”

Descriptive terms for page elements are usually either presentational, relating to their position on a page, or role based, relating to their purpose—for example, body text versus content. “Some people name by the nature of the thing and some by the place on a page,” said John. “If you’re putting presentational terms right in your code, it may cause problems when you move something. … Developers are using the semantic elements of HTML. … If you go beyond the lore of developers who are using best practices, the commonality drops off. We’ve got this group of people who work together to get a common outcome, but we don’t have a common language.” He quoted Brad Appleton:

“Fundamental to any science or engineering discipline is a common vocabulary for expressing its concepts and a language for relating them together.”

John posed these rhetorical questions: “Who’s going to do this? Where’s it going to come from? XHTML? HTML5? The W3C? One of the great beauties of the Web is the light touch the W3C has had, by and large. Languages emerge from the bottom up; design patterns, from data, rough consensus, and working code rather than committees. I was skeptical about whether an anarchic process could result in a common vocabulary. There’s a very strong sense in the design community that we need something. There’s no Chapter I: Genesis where God’s going to name things.

“What are people actually doing? Taking this pattern language approach. … But often people are developing libraries, not patterns or languages. A language has a certain dynamic. It’s generative—small patterns build up to create larger patterns. How do we classify types of patterns? A Web page is built up of smaller parts. It’s this generative thing. Web pages are built up of smaller elements. The Web itself is hierarchical. The lower down in the tree, the simpler the constructs are.

“Page layout patterns. Page navigation patterns. Within a particular class of patterns, … a class doesn’t necessarily define what something is well. … You can classify patterns by the role they play—container, navigation, branding, user interaction. … The distinction between what something is and what something does is really important. A class describes what something is; a role, what something does.” For user agents and assistive devices such as screen readers, it’s preferable to communicate what something does. “Browsers are just printers for the screen.”

A classic three-column page layout pattern—with a container, a navigation bar, and a sidebar—separates the content from the navigation. John said, “Let’s start calling things by what they do and are. … A lot of times, people are doing the right thing. The next iteration of sites will start homing in on a common vocabulary. How can we start using the same terminology for the same things? Let’s identify things by what they are. Simply giving things names doesn’t help, because we haven’t agreed on what to call them. If we had names, it would solve so many of our problems. Patterns are about aggregating. We’ve got a small number of patterns working together to create an extremely common construct on sites. It’s time for us to become a discipline by having a common vocabulary. Information architects influence practice more than most designers. It’s not about one person saying, ‘You must do this.’ … Let’s start getting consensus. I love this idea of the wisdom of the crowd. I’ve started a wiki and blog. I would love to see a collaborative process occur. … This is about having richer semantics.”

Day 2: Communicating Design: An Astonishingly Close Look at IA Documentation

Presenter: Dan Brown

Dan Brown (shown in Figure 5) spoke about the role of information architecture documentation on a Web design project. “A document captures an idea.”

IA documents provide

• “consistency of vision—Documents help facilitate communication. This first one is most important. Some people aren’t involved in a project all along the way. By creating documentation artifacts, you can capture decisions.
• “accountability—Documents represent project history. Documents give a historical view of an entire project.
• “traceability—Documents show progress. Do decisions rely on private discussions? By having a set of artifacts, you document decisions.”

There are dozens of different kinds of documents, but “the big ten” documents fulfill various roles, as shown in Figure 6.

Dan described a usability report as “a screen shot and a list of all the problems on that screen.”

Taking a closer look at flow charts, Dan showed several examples and involved the audience in a discussion of their uses. Example flow charts included references to wireframes, swimlanes, and annotations that indicated where problems had occurred during usability tests. Flow charts start in the upper-left corner and include anchors at the beginning and end of a flow. They typically include steps, paths, and decision points, but can also include step distinctions—for example, notifications, options, or confirmations—step variations—a single step that varies according to state—step groupings, step details, error paths, triggers—which start events—and scenarios under which a flow would occur. He said, “Triggers and scenarios are nice-to-haves.”

Next, Dan spoke about the anatomy of a document. Documents include the following kinds of elements:

• defining elements—which make a document what it is
• elaborating elements—which provide useful details, according to context
• enhancing elements—which add details to support a broader agenda

The essential elements of wireframes include the following:

• a representation of what a user sees
• the blocks of content on a page and how they’re important relative to one another
• a caveat that this is not design

Figure 7 shows a beautiful example of a wireframe.

From the audience, Andrea Wiggins contributed some other possible elements of wireframes:

• goals and objectives of a page
• the context for a page—For example, to show how a user got to a page, you might include a miniature version of a flow, with the preceding and following pages.
• annotations that define business rules and behaviors

Dan told us, “Think critically about your own documentation. Don’t become married to your documentation. Sometimes you need to throw it away and start again, because sometimes it doesn’t work.” He showed us a case where he’d done just that. When creating deliverables:

• establish the purpose for a document—“What do you want to get out of it?”
• identify your audience—“Who’s this thing for? They may demand different kinds of information.”
• inventory their contents
• prioritize their contents—“layers of information; dimensions of data”
• create a visual language

Finally, Dan discussed how to “employ deliverables in one’s process:

• communicate purpose
• relinquish control
• note opportunities for improvement
• estimate the value of maintenance”

Dan said, “We can extend pattern library work into our documentation systems and describe how to use patterns.” He suggested that we “leave annotations out of wireframes if using them for paper prototypes.”

While Dan thinks “Visio is one of the best diagramming tools out there,” he now uses OmniGraffle. “I switched to Mac® for my mental health.” His partner, Nathan Curtis, creates wireframes using Illustrator® and InDesign® from the Adobe® Creative® Suite.

Dan is a very dynamic speaker, and this was one of my favorite sessions at the IA Summit. Dan’s presentation is available on SlideShare.

Day 2: Where Does IA Fit in the Design Process?

Moderator: Peter Boersma

Panelists: Larisa Warnke, Peter Merholz, Livia Labate, Leisa Reichelt, and Josh Seiden

Peter Boersma (shown in Figure 8) led a lively panel discussion on how IA fits into the design process. The key questions the panel discussed:

• What is a design process?
• Who needs a design process?
• When should IAs be part of the design process?
• Where do you keep your design process?
• How do you communicate a design process?
• Why should others create a design process?

Livia Labate spoke about the importance of defining process to manage demand for IA services, to ensure operations are efficient and quality is sustainable, and to preserve people’s sanity. A defined process also enables “innovation within boundaries.” She emphasized the need for a toolbox rather than a rigid process:

• During discovery, frame the problem.—“Understand user needs and business goals, by exploring their dimension and points of convergence,” through user research, domain research, industry benchmarks, and business goals assessment.
• During modeling, explore the solutions.—“Architect the solution by modeling the user interaction with the product touch-points.” Do task and content analysis; create personas and scenarios; explore organization, classification, and navigation systems; model interactions; and establish naming conventions, patterns, and guidelines.
• During validation, assess the level of success.—“Improve and adjust solutions through continued user feedback and observation,” by doing usability testing, prototype validation, heuristic evaluations, and user behavior analysis.

She said, “Balance user needs and business goals to conceive solutions [that] enable positive experiences.” Livia’s presentation is on SlideShare.

I found Leisa Reichelt’s presentation on agile user-centered design (UCD) particularly interesting. Her presentation is on SlideShare. Here are a few highlights:

• “Design should last throughout a project.”
• “Waterfall is bad. Washing machine is good.”—Washing machine referred to iterative cycles of design that occur throughout a project.
• “There are a lot of variants of waterfall—all of which have a lot to do with fiction, I think. Waterfall assumes you know what you’re going to do.” In reality, “design decisions will continue to happen throughout implementation.”
• “Agile and UCD have a lot of things in common with one another. It’s a myth that agile and UCD don’t play well together. … Agile and UCD are both about progressive improvement.”
• She advocated for “pair design.”
• “Take things to customers early and often. Design only as much as you have to. You want to get to lo-fi prototyping as quickly as possible. … Paper and pencil.”
• “First, test the proposition/concept/overall idea/strategy.” …
• “One thing that’s great about multidisciplinary teams: They have a sense of ownership.”

Peter Merholz, Director of Practice Development at Adaptive Path, spoke about their approach. “Adaptive Path doesn’t have a process—a set way of doing things. We adapt to the client. We have a methodology, a toolbox. We begin with discovery, talking with stakeholders, user research, strategy—how we’re going to solve a problem. Design is the planning of the solution. Finally, we build an implementation of the solution. There aren’t always all of these steps. Practices that take place during a project might include experience strategy, user research, interaction design, information architecture. Every practice is involved in discovery. It’s best to have as many practices involved as possible throughout the process.

“As we’re doing more strategy, we don’t know what the outcome is going to be. Can you tolerate ambiguity? You have to engage in communication with a lot of people to figure out where you are. Rigid process requirements are less common. …

“As part of our sales process, we show our deliverables and educate clients about our process.”

Livia Labate said, “Process helps innovation. If you have flexibility and modularity in your process toolbox, it doesn’t constrain your ability to innovate within design or development. … The IAs help to frame what we’re trying to accomplish. We go through the entire process again if there are changes.”

According to Josh Seiden, “Process is never the goal. It makes our work visible and is driven by project parameters and goals.” About Cooper’s goal-directed design, he said, “So much of a design methodology can be cultural.”

Peter Merholz stated emphatically, “An agency that has one designer working on more than one interactive design project at a time is going to do a disservice to their clients. We’re not always able to practice the ideal, because you don’t know what will come up in the flow.”

Day 2: Maximum Value Information Architecture: Big IA Is the Way You Do, Not What You Do

Presenter: Austin Govella

Austin Govella (shown in figure 9) gave an enjoyable talk about strategic IA. The creative imagery on his slides was evocative and introduced a touch of whimsy. “Big IA is about strategy and contributions to your organization’s overall goals,” said Austin. “Everybody should be headed in the same direction. During discovery, you often find there’s a gap between what they say they’re doing and what they’re actually doing.”

When discussing the role of IAs in setting business goals, business models, and strategy, Austin said, “This is one of my pet peeves: Somebody says, ‘That’s not what IAs are supposed to be doing.’ I just think of things a little further down the road. Always know where you’re going.” That lets you “contribute to the organization in a greater way.”

“Seven strategies for creating a larger impact on the business:

1. Rich interaction widgets—Tools, not rules. Give people something useful they can use in other situations. Separate behavior from content.
2. Controlled vocabulary—Make mountains from molehills. Change perspective to make things bigger.
3. A/B testing—No is only part of Now. No only starts the conversation. See where the conversation takes you.
4. Input matches output—Plant seeds. Ideas blossom over time. (See Figure 10.)
5. Find great minds—Think like them. Talk like them. Or, figure out why you don’t.
6. GIS application—Play new games. Change the rules. Change the outcomes. When you have some insurmountable barrier, if you change the way you play the game, you can go around it.
7. Campaign sitemap—Ice the cake. Always add one more layer.”

Austin’s presentation is available on SlideShare. 

Photographs by Pabini Gabriel-Petit.

Read Part II