Web DevCenter    
 Published on Web DevCenter (http://www.oreillynet.com/javascript/)
 See this if you're having trouble printing code examples


Information Architecture for the World Wide Web, 2nd Edition

Information Architecture Meets Usability

by Bruce Stewart
05/13/2003

Lou Rosenfeld is an information architecture consultant and coauthor of O'Reilly's Information Architecture for the World Wide Web, 2nd Edition. Steve Krug is a web usability expert and the author of Don't Make Me Think. They both lead seminars in their respective fields, and recently decided to pair-up to offer back-to-back sessions of their symposiums.

We spoke with both Lou and Steve about the advantages of their joint seminars, the common pitfalls of web usability and information architecture, and the state of the web industry today.

Stewart: Why are you guys going on the road together?

Krug: It just seemed like a good idea, I guess. I'd been making plans to do workshops in a number of cities, based on requests people made through my web site; when Lou asked me what it was like doing my own road show, we just ended up deciding to make it a joint tour. I've always admired Lou's work and his attitude, and it seemed like we'd get along well together.

Rosenfeld: And it does seem to work well, as our styles are pretty similar. Neither of us are big fans of dogma, and we're both pretty funny. Well, Steve is pretty funny and I just try to keep up.

Stewart: Do you think you'll draw the same audiences to your respective seminars?

Rosenfeld: So far, about half of all attendees are registering for both seminars. It's not clear if they find our topics perfectly complementary, or if they just want to take advantage of the discount for registering for both.

Stewart: Usability and information architecture: aren't they the same thing?

Related Reading

Information Architecture for the World Wide Web
Designing Large-Scale Web Sites
By Louis Rosenfeld, Peter Morville

Krug: Yes, oddly enough--although very few people know it--they're really the same thing. Sorry. Just kidding. There's certainly some overlap, but for me the main difference is that information architects actually design something (the structures and mechanisms that organize information), whereas we usability types are more in the constructive criticism business: we try to improve things that other people have designed.

I sometimes think the best analog for my job is a "show doctor"--the person who comes in while a Broadway show is still in out-of-town tryouts, watches the whole thing, and says, "I think it would work much better if you moved the cowgirl dance number to the start of the second act, and killed the love ballad altogether." I'm a fresh pair of eyes (which is vital, because if you've worked on a web project for any length of time, you know it too well to see it clearly) and an outsider who can advocate for the interests of the end user because I'm not involved in the internal political struggles.

There's enough overlap between the two fields that most usability folks can give a client good advice on IA problems, as long as they're not too complex or specialized (I couldn't build a controlled vocabulary if my life depended on it), and most IAs can give a lot of good usability advice. The trick is knowing when you've reached the limit of your expertise.

Rosenfeld: Absolutely. And good IAs obviously need to have some usability tricks up their sleeves. But depending on the size and complexity of a project, I often recommend (and hope) that a usability specialist be brought in.

Stewart: Steve, what are the most common usability mistakes you see?

Krug: Amazingly, I still run into a lot of home pages that don't give you a clue what the site is for or who publishes it. And I see a lot of page layouts--and even page templates that are used throughout a site--where the visual hierarchy is misleading, so the layout suggests something about the content (which parts are most important, for instance, or which bits of content are related somehow) that's misleading. And the classic problem is having too much "stuff" on a page, so that none of it gets the attention it deserves.

Stewart: Lou, how about the most common IA mistakes?

Rosenfeld: For smaller sites, a decent architecture is within reach, if not already in place. In other words, the mistakes are common but well understood and fixable.

It's those larger, more complex sites that I'm concerned about--these are the ones that reflect corporate org charts and departmental politics. My assumption is that, in most cases, users don't have the org chart stored in their memories to guide them through a large site's content. This isn't so much a mistake per se, but an unfortunate accident of corporate reality.

It's also an incredibly difficult problem to address--content grows naturally in "silos" that reflect the boundaries between business units. How do we reorganize this enterprise content in more user-friendly ways? And how do we change the enterprise itself to support a new user-centered information architecture? These are the issues that I address in my seminar.

Stewart: Is simpler always better?

Krug: No, certainly not "always." There are circumstances in which complex, dense, even overloaded and noisy, is better. But clearer is always better. People often confuse simplicity and clarity, forgetting that things can be complex and still be clear. The way you often hear it put is, "If we make it simpler, the power users will be offended." But my experience has been that power users are never offended by clarity; in fact, they appreciate it as much as anyone. What they don't like is wasting their time figuring things out just because the people who built the site didn't go to the trouble of making it clear.

Stewart: What are some tricks of the trade that designers should be thinking about when dealing with very complex or information-heavy sites?

Rosenfeld: There are a number of "lightweight" architectural approaches--from guide pages to best-bet search results--that benefit many users, but won't cost a lot for you to develop and implement. You can get these going quickly, buying you time and increasing your visibility while you decide how to take on the more daunting, long-term challenges.

Another trick is the ethical use of deception. With some careful thought and planning, we can deceive those who are normally focused on their own department's content, users, and politics (and their own turf) into focusing on the good of the whole organization. For example, I think it's often possible to hijack the audience-segmenting process into focusing on coming up with subject samples that have nothing to do with the org chart; decision-makers will be none the wiser.

Stewart: Are there any cardinal rules of usability or IA?

Krug: Well, I'm kind of partial to "Don't make me think." I really do find it to be a good overriding principle: pound on the thing--and keep showing it to people--until it's as clear and self-evident as you can make it. Get rid of the question marks floating over their heads.

For the most part, though, I try to teach an attitude and strategies rather than rules, because designing a site that works well is always a juggling act: prioritizing the use of space so it helps both the audience and the publisher accomplish their goals; juggling the layout and formatting so things have a useful/appropriate amount of emphasis; and so on. You're always trying to optimize for a lot of variables--usually too many--at the same time, showing enough of this without introducing too much of that. And there aren't very many universal rules, because the solution that works in one design context won't work in another.

Rosenfeld: Rules don't work so well in IA either; in fact, the "right" answer to any tricky IA question is "It depends." The only IA "rule" that comes to mind is the Pareto Principle, a.k.a. the 80/20 rule, which really isn't a rule at all.

The way Pareto works in IA is basically that some large number of users will benefit from a small selection of all the possible architectural approaches. So pick the few best ways that give you and your users the most bang for your buck. There are many other variations on Pareto; for example, the few most common searches constitute the vast majority of all searches (and can be addressed by manually developed "best bet" results). If you don't believe me, just check your search logs.

Stewart: How far back in the history of browsers should web designers concern themselves with today? What are the earliest browser versions you recommend testing to?

Krug: Ah, a trick question. I'll get in trouble no matter what I say. Personally, I still use the antiquated Netscape 4.77 browser most of the time because I happen to like its email client, and some sites won't even open in it. (I may get a logo at the top of the page, but the rest is blank.) But I know that it's my problem because I choose to use an old browser, and I don't blame the site developers when it happens.

But there are people who are stuck using an older browser (because of company policy, really old hardware, or such a slow connection that they can't download a new one), or who really like one of the off-brand browsers. The whole notion of graceful degradation--making sure you provide a useful, if less-than-perfect, experience, even in old browsers--is probably right. But again, it often comes down to tradeoffs: how much effort can you afford to put into supporting every browser?

Stewart: Everyone knows user testing is important. What are the keys to doing this successfully?

Krug: I think the most important thing is just to keep it simple enough that you actually do it. Testing is most valuable if you start doing it early in the design process, and then do it at regular intervals, fixing the problems you find in between tests. But a lot of people still think that you need to test five or eight or twelve people to get a "valid" sample. It's entirely the wrong attitude, and the result is that people end up testing only once, and they do it when they're nearly finished designing. Instead, people need to learn to drag in a few people at a time (even two or three), keep it very informal, and do it every three or four weeks.

Stewart: Lou, why focus on the enterprise setting? Some sort of "Star Trek" fixation?

Rosenfeld: TV's "The Enterprise" is misnamed, because it's a large, complex entity that's efficiently run by a small cadre of highly qualified decision makers who leave their egos at the door. (Well, with the exception of Kirk, of course.) All the information they can ever desire is instantly retrieved, synthesized, analyzed, and spit polished by a mammoth artificial intelligence presence that apparently runs on something more stable than Windows. Real enterprises are similar only in that they're large and complex. They're not efficient, frequently recreating content and making duplicate software purchases. They're frustratingly political, and design decisions often get made by the senior VP who wields the most power. They're uncoordinated, with forces of centralization (e.g., headquarters) in a tug of war with autonomous business units.

In all this to and fro, users get left out. So, rather than being designed to meet users' needs, enterprise information architectures organically grow to reflect the political boundaries of the org chart. Why am I fixated on this issue? Well, personally, I'd rather design architectures for small, simple sites, pick up my check, and sleep well at night. But just about every prospect and client I've spoken with in the last three years has complained about their inability to address the challenge of improving their organization's enterprise-wide information architecture. So the fixation is theirs; the seminar is simply my attempt to help (and, in the process, keep off the streets).

Stewart: Steve, why aren't you as fixated on this "enterprise" context as Lou? Isn't "enterprise usability" a big problem too?

Krug: Usability problems turn out to be somewhat less politically charged than IA issues. The information architecture has a more direct impact on how the different parts of the organization are going to be represented by the web site (the allocation of "air time"). And the IA process has a tendency to surface existing problems and inconsistencies in how the enterprise itself is organized--particularly in the areas where the internal organization won't make any sense to an external audience.

Stewart: What do you see as the biggest challenges for designers in usability and IA?

Krug: Getting enough sleep. The biggest problem with usability is often not knowing what needs fixing, but having the time to fix it, and most web designers (and developers) are already short on time as it is. The other big challenge is getting some distance from your own work. Once you've been working on a project for even a few weeks--let alone months--it's almost impossible to step back and see it from a user's point of view. That's why watching people use what you build (a.k.a. "usability testing") is so important.

Rosenfeld: I think the biggest challenge for anyone who designs anything is in cost-justifying their work. Under every bridge lurks a big, hairy, ugly troll, and his name is ROI.

While I don't see there ever being an especially clear ROI case for IA, more and more people seem to understand its intrinsic value in the same way they understand the value of other nebulous areas that are hard to cost-justify. For instance, a marketing budget. So I'm optimistic.

Stewart: What do you hope people will leave with at 5 p.m. that they didn't have when they came in?

Krug: I bill my workshop as "learn to think like a usability expert in eight hours or less," and I'm just arrogant enough to believe my own hype. My aim is for people to have a much better usability sensitivity, and to know the kinds of questions to ask themselves while they're building the site, how to do their own usability testing, and how to approach solving the problems they find.

Rosenfeld: Hope.

Seriously, the people I talk with feel hopeless, much more so than they should. Their hopelessness is often a reaction to the loopy optimism or blind ignorance of senior managers who think that the challenge of redesigning an enterprise-wide information architecture is a non-issue, a piece of cake.

I want my seminar's attendees to leave with some practical design concepts they can implement right away or very soon, balanced with some realistic plans and goals to work toward over the long haul. I hope they'll have a better sense of which "textbook" research methods do and don't work in an enterprise context. And I hope they'll walk away with a framework to guide them in building a team to tackle enterprise IA issues inside their organizations.

Stewart: What's it like out there? Who can afford to spend money on usability and IA these days?

Rosenfeld: These are terrible times, but at least the U.S. federal government is spending; don't ask me why. Even corporations seem to be scraping up at least some of the dough they need to address their IA problems. And they're not just spending it on software tools; more and more they're trying to improve on those investments by bringing in expertise. In fact, I'm amazed at how many enterprises now have full-time information architects on staff. So I see reasons to be optimistic.

Krug: What I hear from pretty much everyone is that it's still very rough out there. I think more companies know now that they should be putting some effort into usability, but it's still nowhere near being a standard line item in project budgets. The story I hear most is that a lot of companies are expressing interest and making inquiries about usability, but they can never seem to get around to making the decision to actually spend money on it.

The companies that are spending money on usability are the large ones with huge web investments, and the smaller ones where the managers have had previous experience with usability and know that it can actually make the design process easier and faster, instead of just costing money.


If you're interested in learning more about information architecture and usability, consider attending one of Steve and Lou's seminars.

Locations and schedule:

Enterprise Information Architecture (with Lou Rosenfeld)

Don't Make Me Think: The Workshop (with Steve Krug)


Bruce Stewart is a freelance technology writer and editor.

Return to the Web Development DevCenter.

Copyright © 2009 O'Reilly Media, Inc.