Search versus Information Architecture

At a recent Triangle SP User Group meeting an interesting debate broke out regarding the use of search to find information inside of a SharePoint system. One person went as far as to say that “search is a last resort” while another said “if a user has to search, you have failed.” Those are some pretty strong positions to say the least. I believe that Information Architecture and Taxonomy are incredibly important, but Search is as well and should not be a last resort. If proper planning is not done in both areas people are going to have trouble finding what they are looking for.

Preferred Method Depends on Context
First I think this debate requires context since the type and the amount of content to look through can range dramatically. Browsing a Wiki with 20 pages is not the same as browsing a Document Library filled with 100,000 invoices. For the former it would seem crazy to need to rely on search, but with the latter it is absolutely essential to most end users.

Users Think Differently
I have had the chance to do usability studies for large SharePoint implementations in a few organizations now. Early on I was amazed at some of the feedback I received with regards to organization and taxonomy. All users do not process thoughts the same way, so while you can work hard to cover all your bases some will still be left out. Put as much time into planning the Taxonomy as possible, and review it on a regular basis as the content and purpose evolves.

Search Needs Tuning
The search service with MOSS can be pretty powerful, but it isn’t something you just turn on and expect targeted search results to be delivered. Time should be spent planning the search system to take advantage of its powerful features including authoritative levels, keywords, best bets, scopes, etc.

As part of this planning effort you should try to identify which sections or sites could most benefit from custom search interaction. If the nature of the data is such that searching is likely to be needed, configure tools to make it as easy as possible to pull that specific set of data. In Mike Gannotti’s presentation, one of the things he suggested was creating a sub-site for each feature or type of list. The advantage of this is that when users search at the “This Site” scope, only data from that level will be returned. With the exception of Wiki configuration, this is not something I have typically done.

Learned Behavior – Browsing versus Searching
After the meeting I reflected on the topic quite a bit, and then a day or two later something occurred to me while working on my Vista machine. When I sent to go open a program I found myself using the desktop search feature to find the programs that were not pinned to the Start Menu. In the past, on previous computers, I had spent an insane amount of time building a system to help organize my program menu. Since I had too many things installed and the menu would wrap, I created a taxonomy with high level categories that led to the program folders (i.e. Dev Tools, Sys Tools, Office). Everyone agrees that browsing to something when you know its exact location is very quick. However, it is quicker still to type in a name and then double click the result returned. Reaching the Event Viewer for example has never been so easy. Without realizing it, my behavior in this OS has changed. While I am not a typical end-user, I believe that I am not unique in being able to adapt to new ways of finding information.

End User Ownership and Evolving Content
Some of the biggest Information Architecture challenges I have seen come from the fact that in most organizations many of the site collections are owned and managed by business units. You can try to educate them on proper planning and maintenance, but in most cases it is far from their top priority even as people complain about usability.

In many cases the purpose of the system changes leaving it out of sync with the taxonomy or navigation design. This is a sure fire thing that pushes users to rely on search.

Best Way Forward
I think the best way to tackle all of these challenges starts with proper planning and site owner education up front followed by periodic reviews of existing sites after the fact. If you can schedule reviews either quarterly or semi-annually as part of the overall service offering it will help you limit some of the issues of End user Ownership and Evolving Content. By keeping the system tuned, users will be more productive, and therefore more interested in using the system which increases end user buy in.

Where Do You Stand?
Where do you stand on the debate? Do you have anything to contribute to the discussion? Is Search a last resort? Is developing a maintainable taxonomy even possible?

2 Replies to “Search versus Information Architecture”

  1. I’m of the belief that you need to have a healthy dose of both in most cases. I agree with your points about it all being based on the individual and the specific data being handled.I do think that it is possible to create and maintain a healthy taxonomy for data, but I also think its possible to “over-taxonomise” (is that even a word?) and get it to a point where it is more of a chore than something simple to add metadata from the taxonomy.Great post Mike

  2. Nice post. It is like you have taken 2 presentations I am planning, browsing v’s searching. It is very much 50-50. That is where consistent and user friendly information architecture comes into play.Anyone in IT or consulting must have a good understanding of how to architect both solutions, if everyone was the same the world would be a boring place.Cheers

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: