Information Architecture Deliverable Examples

In information architecture, there are a few deliverables meant to communicate the information design to all the stakeholders. Here’s a brief overview of what can be delivered on an IA project and why these things are important.

This list of deliverables is by no means exhaustive. These are some of the typical ones we work with on a project, but we also do stakeholder interviews, user interviews, scenarios, etc.

Content Audit

At the highest level, a content audit looks at the content on a website, intranet, extranet, or software to see what is redundant, out of date or trivial and to see what information can be kept. This process identifies the different types of content to be accommodated in the site map, wireframes, and design. It can help identify what is missing based on persona needs and business needs.

A content audit has traditionally been done in a spreadsheet (though this is not without its limitations). Normally we started by adding in the site hierarchy, the associated analytics, and note the content type and make some general notes about the page. This is how our content audit template is set up, with some data:

Content audit showing columns we use: URL, title, level, content type, analytics

Personas

As I tell clients, personas are help us design for a concrete user. Without a specific audience, we lose track of who we’re designing for and why. If we’re designing for Maria and know that she is more interested in celebrity gossip than world politics, we’ll create a space for her that centres on celebrity gossip.

When we start on personas, we use customer interviews and stakeholder interviews, plus the content audit information, to fill in the different aspects. When sites are very information heavy, we tend to focus on user goals and the content to help fulfill that goal. They may not look pretty, but they certainly help us identify content gaps, content needs, and even change management issues. This persona is for an intranet:

An example of a persona for a content-based website.

Site Maps

A site map spells out the page structure of the site. It can be a very useful discussion point for stakeholders and developers. Stakeholders see how and where their content shows up while developers get information about the structure of the site and how the backend needs to be set up.

The content audit feeds into the site map. From the content audit, you know what pages you have and what you want to have, so you can create a site map that reflects these pages.

Site maps are good for discussion, but they’re quite two dimensional. Stakeholders will always ask, “How is my content going to be connected to this other section?” Or “What will be on the page?” Recognizing a site map’s limitations can help shape the discussion and review process.

A site map with levels 1, level 2, and level 3, plus a section description.

Wireframes

Wireframes show the design of the site without any visual design. It shows:

  • How information should be laid out
  • Displays the navigation according to what the site map has specified
  • Uses the taxonomy and metadata to pull information into a site

The personas feed into which content to display and where it should be displayed. At Key Pointe, we always use example content in our wireframes to ensure the design accommodates our content.

A wireframe of a landing page for a banking website

It’s About Communication

While an information architect can deliver these documents, the work products are more about communication. If a wireframe or site map isn’t communicating well, it’s not doing its job. If everyone understands what’s supposed to be happening, then reams of documentation are not required to further communicate ideas.

Any first version of a deliverable needs to be used as a talking point. It should never be considered final, but should be considered as useful to progress the design discussion. These deliverables are meant to help communication, so use them wisely.

2019-01-23T09:43:07-08:00