This document is born out of a digital agency scenerio in developing Intranet applications. This is a sample document of the kind of Information Architecture that we produce for our customers. It's a dynamic document that that will need to be revised in future iterations. I would say that this is one of the challenges, ensuring that this document remains relevant and up-to-date. Therefore, the level of detail in this example, probably is better suited to a Prince2 style project methodology. In simple terms, where more time is taken upfront to define the system (as apposed to a more Agile methodology).
The SharePoint Information Architecture should provide a structural design of the shared information (pages, documents, lists, and data) - in terms of how this information is structured and the layout of the pages to enable users to find the information they require (although the layout may be amended during design arguably).
With SharePoint Information Architecture, it makes sense that the Information Architect has a background with SharePoint. This means that the output of the document gives a clear and useful document to the SharePoint developer (who is often required to setup the basic site structure, libraries, content types and page layouts). It is for this reason, although I have a technical background, I quite often I also get involved in the Information Architecture of a SharePoint site (or even do it completely). There are many benefits to this, in that the Information Architecture document can actually be a very useful document to give to the developers, and as they say, a picture tells a thousand words, which can save a lot of time in the specifications. The downside is that the design and layout may fall towards "standard" SharePoint methods of doing things rather than thinking outside of the box (plus side is the technical person can ensure that costs are kept under control of course if they are involved in this stage to some degree).
The contents of the Information Architecture documentation should contain roughly the following as a basis:
Cover Page
This is just an introductory page to the document, which includes the clients name, the project, the title of the document and the author.
Site Structure
The site structure outlines the site collections and sub-sites. I often also include a number of lists that may be included in specific sites (mainly custom lists that need to be created, rather than the default lists that are created as part of a site out-of-the-box). Sometimes want to use multiple site collections containing a variety of sites - in this example, I have just kept it simple to one site collection and just outlined the logical architecture (i.e. the information), rather that dictate what content databases are required.
Master Page (not in example)
This page outlines the components that will reside on all pages (unless overwritten on specific page layouts). You can also explain how items
Navigation (not in example)
This page should explain how the navigation elements of your site work and the user can navigate around the site.
Page Layouts
Here I list out the page layouts that need to be created, and where they inherit from. Subsequenlty in the document, I ensure that each of these page layouts has been defined.
Content Types
As for the page layouts, I also define the content types are will need to be created. this should also outline the inheritance of the content types.
Workflows (not in example)
In this example there are no custom workflows, but if there are you should define these.
Page Layout Examples
I then define the structure of each page layout, what goes where etc. Where there are web part zones, make these clear so that it shows that web parts can be added and removed to these regions (you don't want to have to redo the IA if someone moves a web part if you're using web part zones!). It's often a good idea to get the designer involved in the Information Architecture stage prior to design (which usuablly comes after the IA). This means they can get some of their ideas into the IA to get an agreed layout which they will likely want some input on. If web part zones are used, the IA should not dictate which web parts go where, although an initial proposal of web parts to use can be included. But if it is too prescriptive, this document would of course soon become out of date and not useful (since as we all know, web parts can be moved around the page easily with SharePoint).
Custom Controls
This section outlines the custom controls that are required in the site. These will be further defined in the technical specifications.
Search (not in this example)
You should outline what content sources will be included in the search results and any logic of the search functionality.
I hope you find this download useful, and something you can use as a basis of your own Information Architecture for SharePoint implementations.
References:
White paper: Information architecture in Office SharePoint Server
http://technet.microsoft.com/
Determine the Information Architecture of Your Site
http://technet.microsoft.com/
Information Architecture and the Information Architect
http://blogs.msdn.com/b/joelo/
Attachments: