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 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
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.
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.
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.
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â€™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.