Friday, April 29, 2011

Information Architecture Deliverables

Kathy's note: This is the fourth installment in a 12-part series by Theresa Putkey that discusses the intersection of content strategy and user-centred design. Read all posts by Theresa.
___________________________________________________________________

In information architecture, there are a few deliverables meant to communicate the information design to all the stakeholders. We’ll discuss some of these in more detail in later posts, but 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 I work with on a project, but I also do stakeholder interviews, user interviews, scenarios, etc. With the links I’ve provided, you can browse through the websites to learn more. 

Content Audit or Content Inventory
A content audit or inventory looks at the content on a website, intranet, extranet or software program to see what is redundant, out of date or trivial and also to see what information can be kept. The audit/inventory can identify the different types of content needing to be accommodated in the site map, wireframes and design. This content audit/inventory is used with any new content needed for the site.

Learn more:  http://usability.gov/methods/design_site/inventory.html 

Taxonomy and Metadata
A taxonomy is essentially a way to categorize content in a content management system or digital asset management system (or records management system, etc.). To create taxonomies, the information architect looks at the existing content and finds the important words, looks at the new content needing to be accommodated on the site and finds the important words, and then creates a structure that spells out these words and their relationships. A taxonomy is a controlled list of terms with one or more terms being applied to each piece of content. 

Metadata helps identify each topic or content part. Metadata can include fields for the file type, author/creator, editor, date created. Metadata is a controlled list of fields whose values are added by the person (or machine) to the content.

A taxonomy is a way to categorize information while metadata is a way to mark up content with more information. Both of these information structures can be used to pull in content onto a site, to dynamically create pages and topics.

Learn more:  http://www.earley.com/webinars/jumpstarts/taxonomy-and-metadata/what-is-taxonomy-and-why-do-you-need-one 

Personas
As I tell clients, personas are “fake people” that 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. 

Learn more: http://usability.gov/methods/analyze_current/personas.html 

Site Maps
A site map spells out the 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/inventory feeds into the site map. From the audit/inventory, you know what pages you have and what you want to have, so you can create a site map that reflects these pages.

Learn more:

WireframesWireframes 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.

Learn more:  http://usability.gov/methods/design_site/define.html#CreatingaWireFrame 

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.
___________________________________________________________________

About the Author
 

Theresa Putkey is an information architect consultant living in Vancouver, BC. With a Bachelor of Arts degree from the University of California, Davis, she focuses on integrating user needs into website and software design projects. She's currently doing her online Masters of Library and Information Science at San Jose State University. You can find out more about Theresa at www.keypointe.ca, or follow her on twitter @tputkey.
 
Read all posts by Theresa.