Intranet Information Architecture – Purpose and scope of the intranet
This is the second post explaining how to plan and implement an effective intranet information architecture. In the first part we got the ball rolling with the basics, and now it’s time to start defining the purpose and scope of the intranet.
Read part 1: Understanding the basics – what is information architecture
Purpose and scope of the intranet
It might sound trivial – of course we know what an intranet is. It’s a place where we bury all the information and materials related to our business and support functions. Usually there’s also some kind of a news feed and lunch menu available.
However, from the information architecture point of view, we have two extremely important questions to answer:
- Who are the users and what are their use cases – why on Earth do they visit the intranet? What are they looking for?
- What are the contents of the intranet – how does the intranet differ from a business unit public team? Or Yammer news feed? And what about file shares?
When we are able to present answers to those questions with clearness and clarity, we have actually defined the purpose, role and scope of our intranet – and after that it’s suddenly much easier to plan the information architecture so that intranet stuff is easy to find and stays up-to-date.
It starts with the Playbook
I have to admit – personally, I don’t fancy the word playbook. We’re all adults here and should know how to play this game already. But it’s the word Microsoft uses and I don’t have anything better to offer so let’s be happy and stick with it.
Usually, playbooks are used to support the move from a traditional way of working (file shares & email) to modern, cloud-based applications, and more communicative and open working culture. In a nutshell, playbook is a presentation which describes:
- roles of communication and collaboration tools in our organization
- ways of working together using those tools
If you find yourself thinking “well, I didn’t need any playbook to understand how to work”, you’re most likely right. The need for a playbook is quite a new phenomenon. Previously we only had two tools with very clear roles: email (to communicate) and file shares (to collaborate). And even with the rise of SharePoint portals and workspaces there was still just one simple place where to work together.
But in a modern, Microsoft 365 -powered workplace there are plenty of different apps with quite similar possible use cases. You can store and share your files using OneDrive, Teams or SharePoint. You can post announcements as SharePoint news, Yammer group conversations, Teams channel announcements or private chats – and yes, you can still use email. And if we don’t agree when to use what as an organization, it will be a mess.
Some concrete examples of playbook contents:
Pic 1: Explaining the move from old communication and collaboration tools to the new ones
Pic 2: Explaining the basic roles and use cases of the new tools
Pic 3: Explaining ways of working: content creation process of Teams, publishing & outer loop discussion on SharePoint and Yammer
Well, okay – we could have a dedicated blog post series for the playbook, but let’s get back to the topic! So why do we need the playbook to plan Intranet information architecture? The answer lies in defining the scope of the intranet. With the help of playbook we can pick any single piece of information and answer the question: Should this reside on the Intranet?
Yes, we do want to be a little bit exclusive. There are some qualifications for the intranet content. In my opinion, contents of the intranet should be:
1. Published
– we don’t want to have any drafts or unfinished or not-yet-approved content on the intranet
2. Non-negotiable
– there’s definitely time and place for the discussion about the content, but it should happen either before publishing (when working together) or after publishing in enterprise social network platform (like Yammer), and not directly as a part of intranet content
3. Valid and up-to-date
– it’s okay to have an archive but it should be clearly separated from the operative content in active use
In a nutshell, playbook is a presentation of the design of your digital workplace. Intranet is one element (service, platform) of that workplace, and it should have a very clear specific role and scope. But what about users and their needs?
User scenarios – what are you doing here?
Every intranet is – of course – unique. But after 12 years of planning and implementing them I dare to say this: they do have a lot in common, too. The two most important, core use cases for every intranet I’ve seen are these:
I want to find the information I need (in order to thrive at my job)
I want to be aware of what’s happening (in order to feel connected)
So it’s pretty safe to assume that these two should be kept on top of mind during the planning process. But in order to dig deeper in and find out how your intranet should serve the organization, it’s important to identify business-specific scenarios.
A scenario or high level use case is a written description of how the intranet is used and what business challenge it will solve. Simple way to document scenarios is to write sentences with these four elements:
- As someone in [team, unit, role]…
- I want to [do something]…
- Using [tools]..
- In order to [goal / success measure]
For example: As a Contoso employee, I want to glance through the global news feed every morning while commuting using SharePoint mobile app in order to keep on track of the important updates and announcements.
Microsoft provides a lots of SharePoint-specific material with very similar scenario model and even ready-to-use workshop materials – you can find them here (Envision Workshop Concept).
Wrap up!
So, in the pursuit of proper intranet information architecture we ended up (re)designing the whole digital workplace – and that’s not a bad thing to do! At the moment way too many organizations live in a communication & collaboration chaos.
Ideally, the process for defining the scope, role and purpose of the Intranet goes like this:
- Identifying digital workplace scenarios
- Planning digital workplace tools and ways of working to support the scenarios
- Explaining and visualizing them with the Playbook
- Recognizing intranet-specific scenarios, tools and ways of working –> purpose, role and scope of the intranet
With this information it’s easy to continue to the next step in the intranet information architecture planning process: planning the physical infrastructure (hubs and sites).
This blog posting has originally been published at Katja Jokisalo’s blog