This post details the first step towards designing or re-designing your intranet – the system map. This map will define your intranet domains and give the first overall view of the domains that make up your intranet and the things that go in them.
Before any system map can be compiled it is important that in depth user and stakeholder research is carried out as well as a content inventory (see Content Value Analysis). The analysis of these activities will contribute towards populating the system map.
What goes in the map?
From the research and inventory it should be possible to identify user and stakeholder needs and wants. The map should then be populated with ‘data objects’ that is real data not aggregations of data like genres and categories,that is for later. For instance HR may have many different types of policies but for the purpose of the system map it can be summed up as ‘HR policy’.
I have put together a very simplified system map just to show how it works.
As you can see the map only incudes ‘things’-a policy, a procedure, a form etc. At this stage it is necessary to keep it a simple as possible. You can clearly see that there are different areas or domains of the intranet and there are ‘things’ that go in those domains. Forget about labels, genres, categories. What the map is for is to document what ‘things’ user and stakeholders want and need and to also consider what the content inventory has discovered and to place those in appropriate domains.
When carrying out the initial mapping it might be easiest to get a group of people together who have knowledge of the domain(s) and use a whiteboard and post-it notes to construct the first map. That way the lines that define the domain and the ‘things’ that go in them can be easily changed as the conversation progresses.
OK so is that it?
What the system map is for
Absolutely not. The system map if it is to be successful must go through many iterations with different types of users and stakeholders contributing and approving. The beauty of the system map is that it is simple and can be understood by virtually everyone, especiallly important when talking to users and non-technical stakeholders.
If the initial overall map starts to get a bit complicated then it might be a good idea to put together some level 2 maps which can document domains and sub-domains in more detail.
This map can also be of use to those wonderful people who may have to build your intranet – the software engineers. It is something they should understand and if a domain model, which also details the link between the ‘things’, needs to be created this should supply much of the data that’s needed.
In Part 3 I’ll be explaining how designing your intranet’s URLs can be an important part of the intranet design process
If you want to find out more about domain models I strongly recommend you look at Michael Smethurst’s brilliant blog post ‘How we make web sites’ which also provided the basis for the design approach I’m advocating here.
(Many thanks to Ramberg Media for the Flickr CC photo)