Sep 11, 2002: 80/20 Again—Critical Architectural Junctures

Information architecture design practices lean on the 80/20 Rule (aka the Pareto Principle) time and time again. Here are just a few examples:

• 80% of your site's users belong to 20% of the site's audiences.
• 80% of users' information needs are served by 20% of the site's content.
• 80% of users' navigational needs are served by 20% of all possible architectural components.
• 80% of users' searches are represented by the 20% of unique searches that appear most frequently.

By identifying "sweet spots," these rules have obvious design implications. They allow us to focus our efforts on the few options that provide the greatest benefit. Besides maximizing bang for the design buck, the 80/20 Rule can counter and neutralize bad design decisions, politically-motivated or otherwise.

Helpful as it is, let's not take the 80/20 Rule too literally. Is it 80% or 79%? Is it 20% or 11%? Who knows? Who cares? It doesn't matter all that much, as long as it helps us identify those sweet spots. Let's also remember that we shouldn't interpret the Rule as black-and-white; we may express the relationship between quantity and quality through progressive tiers or a continuous range.

I'm fascinated by the 80/20 Rule because it creates so many new ways to look at information architecture (and design in general). Lately I've been finding it helpful in countering clients' fixation on main page design. You've seen this before: the client's various factions wage war over this chunk of prime real estate at the expense of other aspects of the site's architecture. Such distraction results in a dangerously imbalanced architecture, top-heavy and teetering.

At Argus, we encouraged our clients to consider "bottom-up" information architecture--centered on the document, its metadata, and contextual linking. But top-down and bottom-up, while useful, are also incomplete. They don't address all the good stuff in between, such as searching and browsing mechanisms.

That's where our old friend 80/20 comes in. if we look at the few parts of an architecture that merit the most attention, we might come up with these five:

1. Main page
2. Search interface
3. Search results
4. Browsing interface
5. The "found document"

I believe these five critical junctures may be the 20% of a site's architecture that account for 80% of users' interactions with that architecture. Using these as the basis for a design discussion can provide a number of potential benefits:

• We consider how users will get from A (main page) to B (document "destination") by way of searching and browsing. In effect, we're forced to think hard about the nature of that important journey between A and B.
• We discuss four important topics other than the main page. Balance is a Good Thing.
• We eliminate or minimize discussion of architectural minutiae that shouldn't be addressed until much later in the design process.
• We spend time discussing search, an area that many don't seem interested in or willing to take on these days. We especially focus on search results design, an area that typically requires more attention during the design process.
• We chop up a complex, overwhelming problem space into five more easily digested pieces, making for a more efficient design process.
• We can ask important questions about users' tasks, information needs, seeking behaviors, and navigation for each of these five points.

This last point is perhaps the most important, as it raises the tough questions the information architects are trying to resolve. The five sets of answers can help us make specific decisions on how search and browse should work at each critical architectural juncture. The result may be a clearer idea of which architectural components to develop: a thesaurus, a system for contextual navigation, a site index, and so forth.

I'm interested in knowing if anyone's tried this approach, or something like it. Did it help focus and organize the design discussion with clients and/or colleagues? Did it eliminate focus on less critical architectural issues? Did it result in a more balanced design?

email this entry

Comment: James Robertson (Sep 11, 2002)

I definitely agree with the 80/20 rule when solving information architecture problems. As a consultant, it is easy to propose huge reworks, but the only sensible thing to do is to tackle the "six big problems" that are really crippling users.

In terms of identifying key areas, a process analysis is also useful. This will identify the key business activities that should be supported by the intranet/website etc. These are then added to the list of issues to be tackled.

I agree absolutely with your search engine comments. I've often found it bizzare how little effort is spent getting the search interface right. Most often, IT managers install the search engine "out of the box" and leave it at that.

(As a side note: it doesn't help that the default configuration of most search engines is absolutely unusable, designed to show off *all* features of the software, not present an interface that works.)

When I worked on a search engine for a client, I wrote up the results in a case study:

http://www.steptwo.com.au/papers/search/index.html

Thanks for another good article,
James

Comment: Eric Scheid (Sep 11, 2002)

Excellent commentary Lou!

feeding google ...
http://www.IAwiki.net/ParetoPrinciple

Comment: Avi Solomon (Jul 26, 2003)

This site:
http://www.the8020principle.com/
is very helpful on the applications of the Pareto Principle.
Be Intelligently Lazy!
Yours,
Avi

Comment spam has forced me to close comment functionality for older entries. However, if you have something vital to add concerning this entry (or its associated comments), please email your sage insights to me (lou [at] louisrosenfeld dot com). I'll make sure your comments are added to the conversation. Sorry for the inconvenience.