Creating a Web-Site Information Architecture in Six Steps

Finding Our Way

Navigating the practice of Information Architecture

A column by Nathaniel Davis

August 6, 2012

In my previous columns, I’ve framed my discussions around the practice of information architecture. To recap, the DSIA Research Initiative—of which I am the curator—defines the practice of information architecture as “the effort of organizing and relating information in a way that simplifies how people navigate and use content on the Web.” While the practice of information architecture can surely extend beyond the Web and its content, this IA practice definition eschews theoretical language to resonate with businesses looking for concrete Web solutions and practitioners who want to make a living off something tangible.

In the end, business clients don’t pay practitioners to practice information architecture; they pay professionals to produce IA work products that help them to meet their business objectives. So, of the many professional interests that come together to create a digital experience, what work products make the practice of information architecture unique?

Champion Advertisement

The practice of information architecture is most relevant within the context of user experience design for digitally mediated user interfaces. If we refer to the DSIA Research Initiative’s UX Design Practice Verticals, the top three tiers of tactical activities within the information architecture practice vertical show the work products of information architecture. These tactical activities focus on navigation, content organization, and the facilitation of information relationships. Any thoughtful information architecture solution must consider these three tactical IA concerns.

In this column, I’ll demonstrate a basic approach to creating a Web-site information architecture. This six-step method includes an assessment of three core assumptions and the three tactical activities of IA practice. Figure 1 represents this sequence of steps for producing a Web-site information architecture.

Figure 1—Six steps for creating a Web-site information architecture

Contrary to popular belief, a Web site’s information architecture is not a mysterious, esoteric force that manifests itself during the UX design lifecycle. Users actually do interact with aspects of a site’s information architecture. For example, when users move from link node to link node, they are engaging with what the DSIA Research Initiative calls the physical construct of a site’s information architecture.

Next, I’ll demonstrate the role of these assumptions and IA tactics in creating a Web-site information architecture through the case study of a small online book retailer.

Case Study: An Online Book Retailer

Fictitious client—AthleteStories.com

Market niche—Sells only books about famous athletes

Although this project could have started similarly to most engagements with enthusiastic clients who just want to know when they can see a design, it didn’t. Instead, it started off with a seemingly more sophisticated client who asked, “When can we see wireframes?” For many seasoned IA practitioners, hearing an anxious client utter this phrase is like hearing fingernails run across a chalkboard.

Defining Basic Assumptions

Granted, it is possible to envision visual and interaction design solutions before getting into the weeds of reality. However, at some point, once the visioning is complete and it’s time to capture details, the creation of a Web-site information architecture must include the synthesis of basic assumptions to support the desired functionality and user experience.

In larger development organizations, specialists in the areas of business requirements gathering, UX architecture or strategy, user research, or content strategy define these assumptions. However, depending on the size and scope of a project, IA practitioners are sometimes responsible for defining these assumptions. This is commonly the case when there are resource and budgetary constraints—or simply because the level of effort doesn’t warrant hiring an expert in requirements gathering.

So, let’s first run through the assumptions that came into play when an IA practitioner created a Web-site information architecture for AthleteStories.com.

Assumption 1: Assess business intent.

Accountable information architecture requires accountable business strategy.

Because business clients expect sound solutions from anyone selling Web-site information architecture services, your information architecture solution should map to sound business goals. Therefore, an information architect must acquire the following information at a minimum:

client’s business model
immediate business objectives
performance measures of success

First, having access to and understanding your client’s business model is foundational. Since creating a Web-site information architecture is essentially an operational function of a client’s business, it is important to make sure your information architecture is in alignment with their business model.

From a business model come objectives. In the case of AthleteStories.com, the retailer’s core business objective was to sell books. That’s easy! As a measure of success, the retailer wants users, on average, to purchase more than one book. I’m amazed at how often clients neglect to adequately review questions as fundamental as this at the beginning of their projects. When a team fails to answer such questions in the beginning, they usually confront them much later during a project, when a crisis of confusion prompts someone to ask, “Do we know what the goal is for this site?”

If you do not know the business objectives and measures of success before you begin tactical IA tasks, it compromises both your process and your final IA solution.

Assumption 2: Assess user intent.

A Web site that understands nothing about its users will have users who understand nothing about the site.

While you can do usability testing and user research quite inexpensively, time or cost constraints may prevent your gaining user insights through such direct means. In such a case, ensure that you define at least some provisional assumptions using alternative methods to help you anticipate the behavior and needs of users. For example, secondary research and the knowledge of your client’s subject-matter experts on the targeted demographic can inform the creation of provisional personas. Whether you’ve gained insights from first-hand observation or synthesized them from various sources, make sure that you can at least make the following assumptions about Web-site users:

their context of need
their information-retrieval behavior
their digital literacy

When you’re exploring contexts of need, the user scenarios that surface may provide guidance on how users would want to navigate through a user interface. For example, research on the user intent of the target audience for AthleteStories.com showed that one of the following usually triggers their desire to purchase a book

discussing sports with other enthusiasts in a social setting
watching a sporting event on TV

Research findings also suggested that mobile engagement would be convenient in more social settings, while a desktop or tablet user interface would be ideal when watching sports at home or engaging in a fantasy-league game.

Note—Knowing that customers may use both desktop and mobile devices to engage with AthleteStories.com informed the strategies for navigation and information relationships that would dynamically deliver the appropriate content for each device.

To retrieve a book about an athlete, a user would most likely start by searching for the athlete’s name or the sport or position they played. As regards digital literacy, the audience is fairly comfortable with any device, but prefers simple account features and interactions.

Note—Understanding the retrieval behavior and digital literacy of users helps inform how to group content, how much information to display at any given point, and gives users the ability to manage the information to which you provide access.

Assumption 3: Assess content.

If there is no meaning to your content, it will mean nothing to your users.

When exploring a Web site’s communications and content strategy, ensure that you gain at least a minimal understanding of these three aspects of site content:

content types
language
volume

It is critical that you know a Web site’s content just as well as the people who created it. While content owners and authors are most interested in the meaning and effective communication of the content, an IA practitioner’s foremost interest is in the patterns and unique entities that make up a given content domain—for example, how to expose categories of documents and file types or unique sets of topics and concepts and their potential semantic relationships.

Language plays a crucial role in the creation of a Web-site information architecture. You use language to label and describe the unique content types that appear on a Web site. While an IA practitioner can recommend formal vocabulary and phrasing, it is helpful to understand that authority for and insight into language should come from two places: content owners (SMEs) and users. Both perspectives are equally important in developing a sound Web-site information architecture.

For AthleteStories.com, a content audit revealed that the retailer offered more than 2,500 book titles. Knowing the size of a content domain helps you to plan an information architecture that scales. For example, it’s important to know whether a company expects to add more book titles in the future and how many. It’s also important to establish the current and future sizes of any content types that you define. In essence, every tactical artifact of a Web-site information architecture should be scalable.

Note—Anticipate the future scope of content types and their thresholds to promote the longevity of a Web-site information architecture.

Creating the Tactical IA Artifacts for AthleteStories.com

Once you have your basic assumptions in place, you can focus on how to support the desired business and user intentions with your client’s existing content. You should recognize that an information architecture solution does not focus solely on users. The business and a site’s users are codependent and are thus equally important in devising any solution. I like to refer to this as a centered design perspective.

The DSIA Research Initiative definition of the practice of information architecture provides the following set of steps, which were employed when building an information architecture for AthleteStories.com:

addressing content organization
building meaningful information relationships
providing efficient navigational constructs

Tactical IA Task 1: Organize content.

Failure to organize is to organize to fail.

Up to this point, we’ve been gathering insights on which to ground the Web-site information architecture for AthleteStories.com. But, content organization, or classification, is typically where the information-architecture-rubber meets the road. The effort to organize a Web site’s content requires that you develop a thorough understanding of that content and how the users of a particular domain of information might view it on many levels. During this content organization task, formally classifying content typically leads to foundational content models.

Even if you’re designing a Web site to give users control of organizing content—essentially allowing them to create their own organizational scheme—there should still be a formal organizational schema, or taxonomy, in place, working behind the scenes.

Figure 2 shows a simple organizational schema for the content on AthleteStories.com, capturing the top entities of the site’s root content model and documenting the number of child items in each group. This is the first tactical artifact of the site’s information architecture. The organization of the content maps to a strong user mental model that the AthleteStories.com team synthesized from user research with prospective customers.

Figure 2—Top-level classifications of content on AthleteStories.com

Even though customers may quickly identify with an athlete, that athlete’s sport establishes a useful context that comes in handy for browsing scenarios. This classification also suggests a potentially valid semantic relationship that implies sports (subject) have (predicate) athletes (object), and authors write books about athletes. This thinking can subsequently transition into more sophisticated domain-modeling strategies.

Tactical IA Task 2: Enable information relationships.

Information is meant to be used. Make it usable.

The business wants an AthleteStories.com site that encourages the purchase of more than one book per transaction, but customers tend to think of more than just a name when identifying their favorite athlete. For instance, some prospective users of AthleteStories.com consider the positions athletes played and even the years they played.

In this case, the business and user intentions are actually complementary. Supporting the search behavior of customers makes it possible to explore the relationships across the entire collection of books, which feed the site’s recommendation engine and leverage the metadata—that is, the data that describes the content—for each book object, as shown in Figure 3.

Figure 3—Metadata attributes for a book on AthleteStories.com

Using a simple metadata schema, the recommendation engine can suggest books about athletes who, for example, played the same position or played in the same era. Plus, by tracking the number of sales per book, it becomes possible to identify and indicate the most popular book by sport or for a specific era.

Tactical IA Task 3: Provide navigation.

Information architecture must offer a constant beacon in an ocean of information.

A navigation system is the most concrete artifact of information architecture. Expressing navigation visually is similar to the mapping of content organization and relationships. However, it’s usually necessary to express navigation in two forms: in a site map and within a wireframes document. While the site map communicates page relationships and paths, the wireframes help to communicate primary link nodes and page-level content organization and relationships.

The site map is an indispensable tool for expressing primary navigation paths by showing the relationships between pages and sections of pages. The content model the information architect created earlier provided guidance when organizing the AthleteStories.com retail site into persistent sections and producing the simple site map shown in Figure 4.

Figure 4—Site map of content sections for AthleteStories.com

For AthleteStories.com, the nodes of the site map also function as link nodes in the user interface, as the wireframe in Figure 5 shows. The search object is a primary navigational construct for discovering books, and the final information-architecture effort determines the display of content objects on pages.

Figure 5—Link nodes and page-level content objects

The wireframe shown in Figure 5 demonstrates how the user interface leverages a sound information architecture comprising content organization, information relationships, and a navigation system. Documented business objectives and user intents and a domain of useful content support this information architecture. While the page that the wireframe depicts may appear to have a sense of design, the contribution that information architecture makes to a wireframes document is setting a foundation of link nodes, information, and groups of content that are essential to satisfying its targeted use cases. Copywriting, visual design, and interaction design heavily influence the rest of the user experience, as well as the usability of pages.

Closing

In this column, I’ve described six steps in the creation of a Web-site information architecture and provided sample artifacts for them. The actual methods and artifacts that you use to achieve the desired results may vary according to the nature and complexity of the domain of information in question.

You can consider the three categories of assumptions that I’ve covered in almost any order. However, I recommend your using them in the order in which I’ve presented them in this column whenever possible. It’s best to execute the tactical information architecture tasks in the order in which I’ve presented them as well, because this sequence of tasks provides the most natural evolution of discovery, strategy, and application.

Finally, the assumptions about business and user intents and Web-site content that I’ve documented are just as important as the tactical information architecture tasks themselves. Therefore, a complete set of information architecture documentation should include at least business and user intents, the results of a full content assessment, and methods and solutions for “organizing and relating information in a way that simplifies how people navigate and use content,” as the DSIA Research Initiative definition of information architecture practice states. The six steps that I’ve reviewed and their respective documentation represent a complete record of a Web site’s information architecture.

In Design Process | Information Architecture

Elliot Greene

June 14, 2014 11:25 AM

I am trying to build a Web-site architecture for a travel portal to communicate the structure of our site to the developers.

We already have a site map, and the site architecture differs from the sitemap. We have built site architectures before—but in our cool drawings—and it worked for us. Also, most of the time, our coder just starts coding, and we build and modify as we go. Please shed some light on this.

Regards, Elliot

Web Design

Saman Vahdat

May 28, 2015 1:23 AM

Thank you so much. I used your content for my presentation at uxshiraz community.

Abhishek Jain

August 18, 2015 11:35 PM

More reading: What Is Information Architecture?

Join the Discussion

Full name

Email address

Remember me (Optional)

Comment