For those of you just starting a new SharePoint deployment, or those of you redesigning a website, this is a familiar question: How do I organize the information in the site? (Technically from a SharePoint perspective, it’s a Web Application, but a web site from the user’s perspective. I keep making this distinction so you will know if I mean an SPSite or not.)
In the context of an intranet, one common approach that I’ve seen and used is to mimic the formal organizational hierarchy. For example, the corporate intranet’s home page is a Publishing Portal and is the point of entry for all web based employer to employee communication (e2e, for those of you fond of acronyms featuring the number 2). Then the top (horizontal, global) navigation features items for each division, and those items link to sites (SPWebs [could be root webs in an SPSite too]). Each site can then have sub-sites for subdivisions or departments, and pages for content that is from that division or department and of relevance to the entire organization.
There’s another approach though that will tend to produce site hierarchies that are more intuitive to the end users. Very simply, it involves getting the end users involved in the hierarchy design and letting them determine the information architecture. (What is an information architecture? It’s “how things are organized”. In theory, your AD OU structure represents one, but that may not be the same one that you’d want to use for your intranet website).
How do I involve end users in designing my site? Won’t that become chaos?
No, it doesn’t have to. Try a Card Sorting Exercise. At my employer, we have User Experience Specialists, and the one I worked with on my current project specializes in usability and is a Certified Usability Analyst. For those who study usability, performing a card sorting exercise was something learned in school. For those of us from other disciplines, who have no idea what a Card Sorting Exercise is, it is done as follows:
- Get a package of index cards. Yes. Physical 3×5 index cards. This is a hardware exercise!
- Come up with a list of terms representing different concepts (e.g. employee services, 401k enrollment form, quarterly report, area for sharing documents, company policy, mission statement ) that describe stuff that will be in the website.
- Write the terms on the cards, one to a card.
- Get a pool of volunteers representing a cross section of the organization. Break them into groups of no more than 6. Each group should be diverse – e.g. different departments, not all from the same department or team.
- Ask the group to organize the cards, minimizing the number of categories (e.g. at most 10. E.g. 27 top level categories make for a horrible navigation experience). Make sure they have plenty of table space to work with.
- Document the information architecture that each group produces (e.g. take a picture of the cards as they have laid them out).
- Integrate the outputs of the different groups into one unified IA.
- Send it out to all participants and get their feedback, then make changes if needed.
There you go. To those of us who tend to define real work as “time I spend sitting at a screen trying to get my code to compile”, you may be asking “You mean, people can actually bill customers for this?” Yes. Think about it: You’ve just captured what the end users agree is a way to organize things that makes sense to them. If you build a site (Web Application) based on this, they will tend to like it more because navigation will make sense to them and they will feel like they contributed and that IT listened to their needs.
Now of course, just having a Word document that describes how to organize the site doesn’t get the site built. Your next steps are as follows:
- Walk through the document with a person (probably from IT) who can tell you what each term really means. Your job is to figure out if this should be a Site Collection, a site, a page, a web part, a list, a file in a document library, or whatever. At this point, depending on how formal your process is, you can start documenting (e.g. in Word) or creating (create a site, create a page, create a list) your site design.
- For every publishing page that you identify, you need to determine if one of the existing Page Layouts will work, or if you need to create a custom one. If you are doing formal documentation, it’s time to update your list of publishing pages with notes about which layouts you will use and notes about which layouts you need to create and what they will look like.
- Think about how you will integrate collaboration capabilities. One pattern that has worked for me is to provide a (possibly targeted ) link on departmental publishing pages (e.g. a department’s publishing home page) that links to the collaboration site (or root site in a site collection, depending on organization size) for that department. The collaboration sites server the internal collaboration needs of the department while the publishing sites serve the department-to-all-employees communication needs.
<Commercial>If you need help with developing an information infrastructure, we can help you. Add a comment to this post, and I can have one of our Account Executives contact you…</Commercial>
References: http://blogs.msdn.com/joelo/archive/2007/03/16/information-architecture-and-the-information-architect.aspx
–Michael