Mind mapping is popular among SharePoint designers as it allows layout of potential site structures with little effort. Modern mind mapping tools allow alternate hierarchies to be modelled in almost no time.
The image above was created using FreeMind, an open source mind mapping tool available on sourceforge. This shows an easy starting point based on departments. Most taxonomy designers will immediately be concerned over the above as departmental designs can quickly become limited. For example, where would you store documents that are accessed by both sales and marketing departments?
The key to good taxonomy design is to carry out meaningful requirements analysis. Holding a workshop with a representative cross section of users can be an excellent way of achieving this. I suggest ensuring an I.T representative is included in this group as often I.T and end users perceptions of what is required are vastly different. In essence, these are brain storming sessions where attendees contribute their ideas.
Requirements workshop facilitators can use mind mapping software to document the requirements and ideas as they occur. A departmental design as shown above would be easily created from such a workshop. There is nothing wrong with this approach; however, such meetings can result in consideration only of structure. This is only one part of taxonomy design.
The facilitator should also encourage attendees to consider information and its usage. Consider the following:
These topic questions can be broken down further as shown below:
Identify basic categories to start with then sub divide and reorganise these as you build the picture of what is needed: Confidential, Public, Internal use only, Available on the web or other common location.
Do you need a home page for the company, departments or projects?
Decide where hyperlinks and other navigation controls should be placed.
Is the information you store static? If not, what processes are needed? Who carries them out? How does this fit with your initially mapped structure (taxonomy design)? Where does input come from? SharePoint Data (lists, libraries), Databases or Remote systems? These are all questions to ask yourself as you determine your processes.
When are we finished?
Working through this process can take several iterations initially and again over time as requirements change. At some point a prototype needs to be created. Users can be invited to try this out and provide feedback. Are we ever finished? Possibly not. It’s an on-going process, but we will at least get to a usable design in time for the next organisational change!