Name: Information Architecture
ISBN: 9780321600806

Austin Govella

Christina Wodtke

Provides information on the concepts of information architecture to design effective and easy-to-undertand interfaces.

Blueprints for the Web

Information Architecture

Jaydee (she/her)

So why are so many of these sites so difficult to use? When you build a building, you make a blueprint. When you build a toaster, you create a diagram of its workings. Yet Web sites, whose complexity far exceeds a toaster's, are often thrown up hastily with barely a thought about how they will be used. A company wanting a Web site hires an engineer, a marketing guy, and a graphic designer, and says, "Go to it." It's the equivalent of hiring an electrician, a plumber, and an interior decorator, and then saying, "Build me a shopping mall." That shopping mall desperately needs an architect, and today's Web site needs an information architect.

Wayfinding lets people know four things: 1. Where they are. 2. Where the things are that they're looking for. 3. How they can get to those things they seek. 4. Where they have already looked.

People visit a Web site for three main reasons: 

• They're looking for something. • They're trying to accomplish a task. • They have five minutes before their next meeting and want to kill some time.

 Too many site creators think their audience is made up of visitors who want to kill time. They also tend to think those visitors have two hours instead of five minutes. Too many site creators think the visitor is dying to be entertained (even if they are coming to a tax- preparation site), so they festoon the place with animated GIFS and zooming navigation.

When someone visits a Web page, they ask themselves these four questions : 

Do they have anything better (if this isn't what I want)? 

If you're in charge of the information architecture, it's your job to answer these four questions on every page of your site. Design-wise, this means you have to do four things: 

Assure visitors they're in the right place. 

Make it easy for visitors to find what they're looking for. 

Make sure that visitors know what their options are. 

Let them save it, buy it, find something neW... 

It doesn't matter what visitors are trying to do on your site. You have to answer these questions, all the time, no matter what.

If you are building an online grocery store, don't divide it into sandwich making and salad making (even though it might be kind of nifty'). People shopping for groceries are used to bakery, dairy, and produce in an organization scheme.

Nathan Shedroff² collected a list of common organization systems most people are familiar with. He says you can organize things by alphabet (an employee directory), location (a map), time (a calendar), continuum (top-rated), numbers (zip codes), categories (newspapers organize articles by local, world, business, and so on), or randomness (iTunes shuffle).

Repeat after me, "A label is not a place to promote your brand. It's a signpost to help people find stuff." If you have a greeting card site, Naughty Humor may not be as in tune with your brand image as Snickers and Snorts, but as a label it will keep the grandmas out and draw the college kids in.

Do the labels match? Is there more than one piece of content in each category? Is one category too big, needing to be divided into subcategories? When you are done refining, you have what you need-a taxonomy. 

A taxonomy is a hierarchal organization scheme, and on the Web it's very useful for browsing (Figure 3.16). If you do your work right, no one will ever notice your taxonomy. They'll just glide along effortlessly to their dream scarf or to a recipe for chicken à la king.

"But some of my stuff could go into more than one category!" "But half my users wanted organization by course, and the other half wanted organization by ingredients!" 

In the real world, you can't be in more than one place at one time. There is a crazy concept called "shelf space," and it appears to be limited. The grocery store can't have a bakery aisle and a sandwich aisle, and have bread in both. There isn't enough space-or bread. However, on the Web, it's another story.

  FIGURE 3.17 Epicurious has more than 80,000 recipes. Good organization is not optional if the site is to be useful.

This is called a faceted classification. Each item has multiple characteristics: the cake is cake, is baked, is French, and is chocolatey. A person can find this item by looking in Cakes, Chocolate, Baked Goods, or in French Cooking (Figure 3.18). This greatly increases a seeker's chance of finding what she is looking for. Faceted classification is pretty nifty, but it can also be very tricky to execute well. First, it's much easier to do if your content is fairly homogenous. 

Instead of bludgeoning the visitor over the head with your site's wealth, take a hint from icebergs. lcebergs are 90 percent underwater. Only the tip shows, but a sailor can spot that tip and know there's a lot more than meets the eye. As the information architect, your job is to design a tip that will suggest the size of the iceberg beneath. How much of the taxonomy should be above the water? How much do you have to show to let people know they've found the right place?

I'd like to say labels are decided like this (in order of importance): 

 How much space there is on the navigation widget 

How bored the writer/designer is with current labels

A good label is so obvious, it's dull as dirt. A good label doesn't make you pause (and it never makes you think). A good label is merely the thing you click to get to the good stuff. It may take you hours to come up with something that looks effortless. When it looks like you came up with the label in two seconds, you probably have the right one.

Three major types of metadata are used nowadays: 

Intrinsic. Metadata about the thing's composition. Is it an MS Word document a JPEG, a 20Kb file, or a zip file? 

Administrative. Metadata about the way the thing will be handled. Is it a temporary thing, or does it need to be archived? Who is the editor? Has it been approved for publication?

Descriptive. Metadata about the nature of the thing. This is the most important for our purposes and the most commonly used on the Web. Is it fiction or fact? Is it an article? What's the subject? What are related subjects?

Did you extrapolate any specific goals? Find any interesting facts about your users? Any information you've gleaned that's specific, relevant, and universal goes into this document.

Specific: Each piece of information should be as precise as possible. Throu out information like, "Users like it to be easy," and keep information like. Jsers need to be able to complete a process in half an hour." 

Relevant: Relevant to your product, not to every site on the Web. Don't renot "Users like free stuff," but include, "Many users request free evaluation periods for software to know if paying will be worth it." 

Universal: Find things that are true for the entire site, not for a single item on a single page. Weed out things like, "Users couldn't find the Submit button on the checkout page," but leave in, "We have a type of user who knows what he wants already and needs a way to speed through finding and buying."

There are three types of pages on the Web:

 1. Navigation pages help users determine where to find what they want, and give them access to it.

 2. Consumption pages allow users to consume content. 

3. Interaction pages let users enter and manipulate data.

 Each type of page is optimized for a different kind of user task. Understanding the type of page you need helps you tailor the interface design. It's also important to understand when users need to move to a new page, versus staying on an existing page.

It's much like the wireframe a sculptor will make before adding clay, as it gives shape and provides support.

A wireframe gets you to concrete discussions quickly, and since it's simple enough to do on a whiteboard, it's a conversation piece. Later wireframes work as documentation devices.

For each element in your wireframe, it's important to consider several questions: 

• Where does the content come from? If you have a list of related articles specify how they're related. Are they the most viewed? Most viewed from that section?

 What is the nature of the content? Does it vary greatly in length, size, lan- guage, and type?

 Is the element required or optional? What happens if the element doesn't appear on that page? Does the layout change?

 Is the element conditional? Does it vary based on other factors? For example, do administrators see additional links? What happens if an article doesn't have an associated image? What if it does? 

What's the default or expected state? ldeally, what's supposed to happen on the page. 

What are the alternate or error states? How does the design change when things don't go right?

Information Architecture Blueprints for the Web

Reviews

Highlights