Published on February 17, 2005
Both information architects and Web designers can be too presumptuous about what the other does. They’re continually putting each other into little boxes, trying to define each other’s role.
On one hand, many Web designers don’t understand information architecture’s role within Web design. Designers think that information architects are the people who keep trying to organize everything. On the other hand, many information architects underestimate the Web designer’s role within a project. Information architects think they should write the site specification and that designers should code it.
One consequence of this misunderstanding is that information architecture and Web design are often considered mutually exclusive. Information architecture involves organizing, structuring and labeling; web design involves technical development and visual design. In turn, Web designers have been led to believe that they’re restricted to doing what they’ve always done and should leave the information architecture to the information architects. This does not have to happen.
While it’s true that everything in Information Architecture for the World Wide Web cannot be learned in a day, there are several information architecture techniques that Web designers can easily learn and apply to all of their projects. This involves looking at information architecture as an extension of Web design. This perspective has several advantages:
- It virtually eliminates the “us vs. them” ideology, which usually ends up hurting both disciplines.
- It doesn’t place boundaries around the roles. Instead, it treats the roles as a continuum.
- It allows Web designers to realize that they know more about information architecture than they think.
- It helps Web designers transition from that role to an information architecture role more easily.
To put this idea into practice, we’ll look at three common Web design tasks (navigation, layout and code) and extend them into the realm of information architecture.
Let’s start with navigation, one of the most loved and hated aspects of Web design. As individual pages are added to the site, it’s very difficult for a Web designer to resist immediately grouping those pages into categories that make sense–to the designer. The problem with this, as many of you know, is that the visitor often doesn’t share the same mental model of the site content and may not realize that what they’re looking for is not in the current area that they’re browsing.
As a preliminary exercise, it’s perfectly fine to group the pages into categories in order to develop a navigation scheme. But after this exercise, you should ask some potential users of the site to do a card sort. A card sort is an exercise used to find out how people group things, and what names they give those groups. It’s as easy as 1-2-3:
- Write down the names of all your pages on pieces of paper.
- Ask the participant to group them, creating subgroups if necessary.
- Ask the participant to name the groups.
After moderating several card sorts, patterns will begin to emerge that will help you to find a dominant organization scheme.
Here’s how to make the extension. After you know what content your site will contain, do a card sort with at least several potential users of the site. Afterwards, you’ll have what information architects call a taxonomy, a hierarchical classification scheme. This taxonomy will prove extremely valuable when deciding on your navigation labels and the site maps for your site.
Next, let’s look at layouts, which have long been an important aspect of Web design. The prominence of the layout has led many Web designers to become very proficient at moving page sections around in Photoshop. Circa 1996, this was sufficient for most projects, and still is to some degree. But for multi-national sites with large and diverse user bases, Web designers need to develop more than just a page layout. They need to develop a page schematic or wireframe.
Wireframes describe the contents of the page through the use of a grayscale block-level diagram. They can range in level of detail, but typically show the location of content, images, navigation and other functionality on the page. It sounds a lot like laying out a page in Photoshop at first, but because it’s inherently focused on information rather than visual design, it’s a valuable tool for examining the relationships between information, content and groups of content.
Here’s how to make the extension. Before you start designing a layout in Photoshop, create a wireframe using software such as Visio or OmniGraffle. You’ll find that it will help you to think more analytically about the content before deciding what color it should be.
So now you have your navigation and site map, enhanced after performing several card sorts with users. You also have your layout and visual design, greatly assisted through the use of wireframes. All done, right? Well, it wouldn’t be a Web site unless we built it, now, would it?
Yes, we’ve reached that point where we need to start coding. What could information architecture possibly add at this point? Well, if you’re a standards-savvy Web designer, it can add a whole lot.
As a Web designer with a keen understanding of Web standards, you know how to create a Web site using W3C compliant HTML and CSS. You also understand the importance of HTML that is semantically structured; that is, using
h1 elements for headers,
p elements for paragraphs, etc. Finally, you know that semantics can survive across multiple layers of development–from HTML to CSS to the visual design. What you may not know is that just by applying this knowledge, you’re already thinking much like an information architect.
Last year, a presentation by Christina Wodtke and Nate Koechely (“First Things First: IA and CSS”) identified how using standards-based Web development can help drive the information architecture and design workflow. This is done in three key ways:
Making your site map references CSS compatible
CSS-compatible site map references are meaningful names that don’t begin with a number. An example of such a reference is
Next, you need to identify hierarchies in your markup by defining the order of content in a meaningful way. To do this, first look at your HTML and make sure content makes sense when the HTML is read from top to bottom. Second, define the order of headings (
h6). The authors of the presentation say that they don’t need to be in order, but the Web Content Accessibility Guidelines clearly state that they should be ordered properly without skipping levels (e.g.,
Finally, you’ll need to make an itemized list of all elements on the page in order to define the relationships and similarities between elements. For example, it is likely that several page elements will serve a similar function, such as headers for content areas, but will be located in different parts of the page. After you know the commonalities between elements, you can design your CSS and HTML for reusability across the site.
Here’s how to make the extension. Before you write your first tag, complete the three tasks identified above. Afterwards, you will have communicated the information architecture throughout the design process, facilitating improved communication between design teams and a better workflow.
Make the extension, fill the role
As I’ve demonstrated, the line between Web design and information architecture doesn’t have to be as clear as we may have imagined. There are many opportunities for Web designers to fill the role of information architect in every project. This is not to say that information architects are no longer needed. On the contrary, with Web sites becoming more dynamic and complex every day, information architects are needed more than ever. But as an information architect who transitioned from a Web design role, I can assure you that information architects aren’t the only ones who can organize things.