Deft Design Delivers Dividends!
Yeah, about time we had a heading with some groan-worthy alliteration.
Without getting caught up in lengthy definitions, inclusions and exclusions, “design”, to me, is a broad church that includes Information Architecture, user experience, and branding. In my opinion, design is a hugely important factor in a successful SharePoint deployment.
The length of this post is testament to the breadth of this topic. Apologies in advance for the arduous scrolling required – I’ve tried to help by splitting this into Part A and Part B 😉
Part A: Information Architecture and the User Experience
Planning IA and UX is extremely important in enterprise SharePoint deployments (even more so if you’re doing an upgrade, and got this wrong the first time around). Running up SharePoint out of the box will (depending on the template you choose), result in a bland grey starting site and little more. The structure from there is up to you. Yes, you can wing it and start running up sites and sub-sites from there and just see how it goes. Or you could build a site structure that directly mirrors your org chart. But if you take either approach, don’t expect your users will get it, flock to it or thrill to it. And while things do need to adapt over time, including SharePoint, don’t expect a poorly designed foundation will be easy to renovate or add to. It’s quite hard to put a lift-well in after the building is finished. Or as a friend of mine in the construction industry likes to say, “You can’t add a fire escape once the building’s already burning.”
If I’m scrupulously honest, it’s probably not a truth universally acknowledged that “the more time you give to planning structure and usability up front, the more likely you are to achieve successful user adoption post-launch.” But it’s much more likely than not, let’s put it that way.
Information Architecture and User Experience design are well established, well respected domains for a reason, so include them in your SharePoint project plan and budget and improve your chances of success five- or ten- or a hundred-fold. I haven’t done the maths – has anyone? Let me know…
Many good IA/UX resources exist online. Some of my favourites are:
- Boxes and Arrows http://www.boxesandarrows.com/ (E.g. see Donna Spencer’s fantastic articles on Card Sorting that start here: http://www.boxesandarrows.com/view/card_sorting_a_definitive_guide)
- Step Two Designs for IA: http://www.steptwo.com.au/columntwo/category/information-architecture/ and for Usability: http://www.steptwo.com.au/columntwo/category/usability-user-centered-design/
- The Information Architecture Institute: http://iainstitute.org/en/learn/
- UX Matters: http://www.uxmatters.com/index.php
- Web Style Guide online: http://webstyleguide.com/wsg3/index.html
No, sadly, implementing SharePoint doesn’t obviate the need for IA and UX design. In fact, Mr Jakob Nielsen himself claims that SharePoint-based intranets will “surely need even more user experience work” in future rather than less. (Don’t worry, I won’t do a lot of gratuitous cross-referencing of Alertbox articles to ‘prove’ my usability credentials to you, but this article piqued my interest: http://www.useit.com/alertbox/sharepoint.html)
SharePoint IA elements can break out into a long list, as follows, and how you approach each will impact UX. M=mandatory and O=optional, IMHO, on a start-up SharePoint implementation:
- Site Collections: O/M
Decision depends on factors such as physical capacity planning and other specific SharePoint-isms, but also the degree to which conceptual distinctions in the solution design should be reflected in physical separation. You could throw Web Apps in there too. Usually a technical Solution Architect would handle this side of the planning, but it helps if the Information Architect has a working grasp of the subject and the decision is collaborative (did you hear that Solution Architects?), because there are still hard boundaries between Site Collections that bite the user experience on the derriere.
- Sites: O
You have to decide between many template options, including wiki, publishing, collaboration sites, etc. You have to determine the hierarchy and relationship of those sites. If the physical structure largely represents your org chart, you should also think about how you might deliver up a more functional experience of content to end users
- Global Navigation: M
Not too bad out of the box in a single Site Collection, although I remain permanently miffed at the lack of clear, user-friendly navigation between the main Site Collection and the user’s My Site. Hopeless! Global navigation gets trickier when you want a single global navigation menu across multiple Site Collections – see the Part B section on Branding.
- Current Navigation: M
There’s the current navigation / quick launch menu at the left of a publishing or collaboration site, and enterprise wikis add another set of options. You can also choose to display a ‘tree view’. Spoilt for choice.
- Other Navigation: O (but strongly recommended)
The preceding are SharePoint terms, but of course there are other navigation options, including related links, breadcrumbs, metadata-driven, inline links, etc. that a good IA will consider.
- Managed Metadata: O (but recommended in many scenarios)
Enterprise Term Store (taxonomy) or user-driven Keywords (folksonomy) or both?
- Audience Targeting: O (but recommended, judiciously used)
- Content Organizer & Drop-Off Library: O
- Content Types & Properties: O
Yes, I’m going to risk the collective wrath of the SharePoint community by rating Content Types Optional. Might blog on that opinion some time later when feeling strong. I do acknowledge they are Mandatory in certain design scenarios – e.g. if you want to use the Content Organizer and Drop-Off library
- Site/Page Templates: O
I’ll say Optional because they are, strictly speaking. There are plenty of templates to choose from out of the box. In my real world experience though, this is almost always Mandatory for clients, particularly for publishing page templates, as the out of the box options just never seem to suit
- Search: M
A no-brainer, except there are also various options relating to search scopes, Advanced search, etc. that should at least be considered
- Security Model: O
Not strictly the domain of IA, but I include it because decisions on the overall structure of a Site Collection(s) can aid or inhibit effective application and management of content security over time.
Phew, there is a lot to think about building a SharePoint IA, isn’t there?
So How Do You Do It?
While general IA and UX resources abound, those with a focus on SharePoint are comparatively rare. Some gems are:
- Jeff Carr’s series on IA and taxonomy on End User SharePoint at http://www.endusersharepoint.com/EUSP2010/category/author/guest-author/jeff-carr/
- Paul Culmsee’s series on IA and usability that starts at http://www.cleverworkarounds.com/2011/01/11/the-facets-of-collaboration-part-1meet-robot-barbie/ Yes, I know the frequency with which I reference Paul’s blog posts borders on the fanatical and stalker-ish, but y’know, he just makes sense, he’s pragmatic and informative, and he’s pretty funny too. Credit where it’s due, right? Also highly recommend Paul’s SPGov+IA class: http://www.spgovia.com/
Other general SharePoint IA resources (mainly for 2010) are:
- TechNet on Implementing and Governing IA: http://technet.microsoft.com/en-us/library/cc262900.aspx
- And Site and Site Collection Planning: http://technet.microsoft.com/en-us/library/cc263267.aspx
- And Navigation Planning: http://technet.microsoft.com/en-us/library/cc262951.aspx
- Bob Mixon’s blog (tag=IA): http://bobmixon.com/?tag=information-architecture
- This random but good Architects Rule! blog post: http://blogs.msdn.com/b/architectsrule/archive/2009/02/26/forrester-the-critical-role-of-sharepoint-information-architecture.aspx
- Another random but very interesting case study from SharePoint: Intranets, Websites & Solution Design: http://sharepointandintranets.wordpress.com/2009/08/24/the-use-of-concept-models-and-site-maps-in-sharepoint-intranet-information-architecture-design-a-case-study/
I will try to blog more on this topic in future, as it’s a particular interest and strength of mine. For now, I’d just like to wind up this section on the importance of good design to SharePoint success with one of my buts … in all design decisions, carefully consider tangible/intangible benefits versus costs – immediate, and long term. Don’t overdo structure, architecture, classification and organisation at the expense of long term productivity. If benign or malign neglect causes any aspect of your IA to balloon into an unmanaged mess over time, clearly it won’t have been worth the up-front design effort. And ironically your SharePoint platform winds up in the same state as the ‘wing it’ approach usually delivers.
- Tweaking and perfecting the search function (particularly Advanced Search) is unlikely to deliver the huge boost to findability you might hope for
- Managed Metadata is great in many ways, but you do need to think about how it will be maintained over time so that it remains an effective aid to information discovery
- The Content Organizer requires business rules to work, and someone to deal manually with inevitable exceptions
- Case studies suggest that Content Types don’t often naturally take hold in users’ hearts, minds and practices, so deliberate reinforcement over time is often necessary
- Ditto Search Scopes
- Requiring users to perform excessive classification of content will turn even the biggest control freaks off, and your grand plans for Utopian metadata and structure will crumble into so much dust (trust me, I learned this lesson the hard way)
If you have the strength and fortitude, on to Part B…
- Don’t shirk the hard work required to get the design of your SharePoint right at the outset
- Focus on structure and usability, and your users are much more likely to understand, use and enjoy the SharePoint you give them
(Oriiginal Author: Lynn Warneke)