|
If
you want to know when new articles go online,
subscribe to the WebWord.com
Usability Newsletter!
The
Intersection of Information Architecture and Usability
An interview with
Alison J. Head, founder of Alison J. Head
& Associates
Conducted via email by John S. Rhodes
(24-Nov-2000)
Introduction
How do you define Information Architecture (IA)?
Why is it special? In a few words, what does it impact?
A good place to start. This is a question that comes up more and more in my work as a usability expert. Fundamentally, IA is about creating navigational and organizational structures that put users in touch with the information they need, when they want it. From a usability point of view, I define five key components that make up the field of IA. They are: 1) organization, 2) content, 3) labeling, 4) navigation, and 5) search. An information architect's typical deliverables (blueprints, wireframes, metadata, thesauri, and vocabularies) are highly valuable and can have great impact at making the Web the kind of useful and workable information retrieval space that most Web users only dream about.
Facets of Information Architecture
How has IA grown over the last few years? How important is it now versus, say, two years ago? Why?
IA has grown a lot in the last few years-in both awareness of the field and the number of people drawn to working as information architects. A lot of credit for increasing the visibility of the field should go to people like
Lou Rosenfeld and Peter Morville. The two wrote the best-selling book on IA
(Information Architecture for the World Wide
Web), have toured the country evangelizing IA, and have untangled some of the biggest messes on the Web through their ongoing work with their crew at Argus Associates. The whole IA message is especially pertinent now, since many sites face the complicated tasks of their next redesign, growth into ecommerce-based applications, porting to wireless information appliances, and localizing sites for global markets. At the same time, many Web managers and designers are increasingly lost, confused, and/or frustrated when faced with these volatile design issues in their daily work. The principles of IA can be a lifeline that gives process and substance to building more well structured Web environments.
How do corporations respond to IA? How do they find out about it? Why do project managers, for example, feel that it is important?
Unfortunately, IA is still a pretty scary topic at corporations. Let me explain why. To many corporate project managers, IA spells three things: more money, more time, and more complexity. Face it, it's a lot easier to talk about colors, type fonts, and new and dazzling features than to talk about how the whole site needs to be totally ripped down and overhauled! It's a vicious circle. Many project managers and designers often find out about IA too late, when they do in fact need to redesign the whole site from the ground up. Ideally of course, they should integrate good IA practices all along like labeling-within a defined nomenclature that can expand as the site grows. On an upbeat note, though, there is some change occurring. In more evolved companies, IA is being defined by some project managers early on. These managers see the importance of IA as an iterative process that is woven into the whole design process and the development of a business strategy for the site. In many cases, information architects have found a permanent place on the Web development team, instead of acting as incidental participants.
How do design, technology, and IA relate? Further, how do developers and designers interpret IA? What does it mean to them?
In an ideal world, all three components-design, technology, and IA-work together in harmony to create a "good" Web design. How are the components interrelated? Here's a simplified description. Design encompasses artistic and technical elements-what the design should look like as well as which tool to use, when, and to what best aesthetic effect. Technology involves knowing how to move a developing site to the most effective and efficient playback environment, as well as figuring out related backend mechanics (cgi, etc.). IA has to do with developing a framework for the site (its structure, labels, navigation, and content) that will enable users to manage and, ideally, exploit the site's content. Of course, a common problem for many Web projects is that these three components are not interrelated. People don't work harmoniously together! Too often, developers and designers see IAs (and usability experts, too) as meddlers, as interlopers, who end up creating production delays by raising nit-picking questions that are tough to answer. Too often, technologists are left out of the whole development process and are brought in at the end, when capabilities are set in stone and must be adapted. The best Web project experiences I've witnessed are when people, whether they are designers, technologists, or IAs, know their field cold, know how to quickly and directly apply fixes and solutions, and have a willingness to work together toward a defined goal.
How is IA different for intranets versus extranets versus the internet?
IA is different for each one of these kinds of sites. Many of the IA differences hinge on who uses each kind of site, in what ways, and for what kinds of tasks. One of the recurring IA topics related to this question is labeling. Intranets and extranets have a more narrow and specified user base. Users tend to familiarize themselves with a site more than users of an internet site do. As a result, the nomenclature for intranets and extranets can (to a degree) be pulled and based on language from a company's culture, focus, products, and work. Quite oppositely, internet sites have to come up with a naming scheme that supports a variable, unknown, and constantly global group of users who may only visit the site once. To make things more difficult, there are other challenges. With intranets, the labels cannot be rooted in jargon or too tied to specific departments that mean little to employees beyond them. With extranets, the labels have to match how enterprise customers prefer to think of products (e.g., product name vs. product number). And with internet sites the labels have to be descriptive enough-without being too broad, general, and subsequently, unmeaningful-to help users take action. Each environment requires a different labeling schema, predicated on the context of users' behaviors and expectations.
I haven't read much about IA for web applications, auction systems, or registration forms. Could you explain how IA works in these cases?
There hasn't been much published, but I've done some work on Web applications and registration forms that are very linear in their nature (i.e., fill out this, then this, then submit). In a way, these kinds of Web applications are "retro aps" because they support some kinds of linear tasks that were (and still are) the bread and butter of a lot of software applications. In fact, we can turn to "old" designs and architectures that have been around for a while, since early software days, for some initial direction. We need to ask what software developers learned then that could be carried over to Web designs requiring steps or procedures. Some years ago, there was some good R & D in software design that led to improved sequencing, awareness of users' cognitive limitations, and error recovery features. Some of these early design principles can be incorporated into architecting linear-type Web applications, especially registration forms. Of course, a big limitation of this approach is that the Web is not software; it is an inherently nonlinear space with a vastly diverse user base. This can really put a crimp in things! The challenge then becomes developing an IA that supports linear tasks for the Web, still at the same time, gives users the navigational (nonlinear) freedom that hypertext provides. Still other problems with the IA arise when Web registration is optional and ubiquitous (users can register at any time, if they want), and privacy statements for different global markets must be worked in. Suffice it to say, this IA nut is far from being cracked.
What are your favorite IA tools? How do you get the job done?
I do very little formal IA work in the sense of delivering clients user scenarios, wireframes, storyboards, and blueprints. When the need arises, I either refer the work out to a reputable firm or I associate an IA expert in. But I will say, as a usability expert, I constantly uncover problems associated with a site's IA through my own tools of heuristics, scenario-based user testing, and, to a lesser extent, questionnaires and focus groups. In fact, we just finished some usability testing on an information-intensive site where three out of five of our major findings were rooted in the site's ineffective IA (i.e., scope, labeling, and consistency)! As a usability expert, I don't employ the same prescriptive tools that information architects tend to use. Usability work is more broadly diagnostic, focusing on a set of tasks, whether the tasks kick off IA issues or not. Still, at the same time, I must be "IA-sensitive," especially since I work on a lot of information resource applications. Both fields (IA and usability) have some important mutual concerns-users, context, and tasks-but each field uses different tools, produces different deliverables, and makes its own contributions toward building more usable sites.
Behind the Scenes
What does your consulting firm (Alison J. Head & Associates) give its customers? What are your key outputs? What is your competitive advantage?
In a nutshell, we're Web design evaluators, concerned with making information-intensive sites, whether they are market research intranets, newspapers, eBooks, or any other information-based sites, more usable. We provide three main services-design audits of sites (unique page-by-unique page analysis); iterative usability test construction, administration, and interpretation; and on-the-fly usability testing, where clients, usually designers, can send over a gif and get some instant feedback on the design's usability. For both audits and testing, we issue detailed reports that prioritize and point out the usability problems with a site, explain how user interaction is affected and why it matters, and provide alternatives and solutions, where they are appropriate. Our real leverage is that we all have backgrounds in information retrieval theory and HCI (Human-Computer Interaction), and we work very closely with clients, educating them about the rigors of user-centered design and its practices, so that they are left with an understanding of the basics which they can continue to apply later on. Another advantage is that we're small and we're selective about the work we take on. In most cases, we focus intensely on one, at most two, big projects at a time where we think we can make a significant difference. We tend to work with information industry companies, such as Hewlett-Packard, Sun Microsystems, and the New York Times Regional Newspaper Group, on their information-based Web and intranet sites.
Please tell us a little bit about your book,
Design Wise: A Guide for Evaluating the Interface Design of Information
Resources. Where can people find out more?
I wrote Design Wise in 1998 on the heels of finishing up a year as a Visiting Scholar at Stanford, where I studied HCI. While I was at Stanford, I became incredibly fascinated with the overlap between the fields of HCI and library and information science (which I already had a Ph.D. in from Berkeley). HCI gave me many of the tools and approaches I had long craved. Design Wise is a book that turns on these disciplinary overlaps, laying out a design evaluation approach for grappling with and understanding what "good design" is or may be. The book has a lot of practical features to it. There are templates for performing design evaluations on CD-Roms, Web sites, and commercial providers, like Lexis-Nexis; interviews with leaders in the field, like
Don Norman and Jakob
Nielsen; and field tests of well-known multimedia products. The book was originally written as an evaluation source for readers who have to select new media resources. Yet Design Wise has proved to be a good read for managers, designers, and developers who want a good overview about HCI, user-centered principles, and design heuristics. Where can people find out more? It's widely available on any of the major Web book sites. I've included the
preface and the introduction on my company site, too, at
www.ajhead.com.
Do you have any final comments or bits of wisdom? What should every person remember about this interview?
I'm not sure whether this is wisdom or just an observation! In my work as a usability expert, I frequently see a common pattern that concerns me a great deal. For some reason, a lot of people working on Web projects-all types of them, from developers and designers to IAs, project leads, and technologists-quickly lose objectivity and perspective about the nature of the Web. They forget that their site competes with zillions and zillions of other sites and that for users, any of these other sites might work just as well at answering their question too. Web users are an impatient lot. If a site doesn't work for them because of flashing banner ads, an ill-conceived IA, or superfluous content, users will make a click and move on, without a moment of thought or guilt! Of course, we all know this, but still, many of us lose sight of this during the design process. The breaking point for a user's patience with a software product is measured in minutes. But the breaking point for a user's patience on the Web in measured in seconds-10 seconds. I would argue it's even less than that these days. If you remember anything from this interview, remember the fragility of the relationship between Web users and a site's design, at all times.
Contact Information:
Alison J. Head
alison@sonic.net
707.939.6941
www.ajhead.com
What next?
|