There’s no question that SharePoint Online, as part of Microsoft 365, has cemented itself as the primary platform for modern intranets. A huge leap forward from previous on-premise versions of SharePoint, organisations can now quite easily create intranets that are clean, modern and simple. Native capabilities of SharePoint Online largely eliminate the need for the customisation previously required to deliver even core intranet capabilities.

While this is great news for teams responsible for delivering SharePoint intranets, the fundamental measure of success remains: is the intranet easy for employees to use, and can they quickly find what they’re looking for?

These two measures of usability and findability are every bit as critical now as they’ve been for the last two decades. It’s also important to recognise that they don’t happen by chance, and they aren’t addressed by Microsoft as part of the native platform. Intranet teams must therefore be prepared to user-test the structure and navigation of their intranets to ensure that what’s delivered works.

This article revisits fundamental methodologies, within the context of SharePoint Online.

Information architecture: what’s in a name?

The term “information architecture” (IA) is used in many different ways depending on the skillset and focus of the person doing the talking. The concept also comes from websites, and the ‘traditional’ intranets that acted as employee-facing publishing sites.

In the context of SharePoint Modern, things work a little differently, so before we start, it’s important to get the terminology clear.

In the context of this article, we split apart three different (but closely related) concepts:

• Navigation experience: the navigation of the intranet (and related capabilities such as search), used by an employee to find information.
• SharePoint site architecture (or just ‘site architecture’): how the various components of SharePoint are used to meet business needs, including the use of communication sites, team sites and hub sites.
• M365 architecture or technical architecture: how the many technical details are configured “under the hood” of Microsoft 365. This is very much the domain of IT teams and specialist contractors.

While this article focuses on the the navigation experience of SharePoint intranets, it’s important to understand that this rests on the decisions made in the lower levels. All three levels need to be coordinated to ensure the best and most sustainable outcome for employees, IT teams and the business as a whole.

How intranets are built using SharePoint Modern

In previous versions of on-premise SharePoint, intranets were constructed out of “sites” and “sub-sites”. Essentially these formed a nested set of intranet sections, and the visible information architecture was derived from that. While this was similar in concept to the way that web content management systems worked, the big problem was that once the structure was put in place, it couldn’t be moved. This “baked in” the decisions made during the initial intranet project, and prevented the evolution of the intranet over time.

With the introduction of “SharePoint Modern” in SharePoint Online, this all changed. In Modern, there are still “sites” (primarily built using the “communication/comms site” feature) but now they sit in a largely flat structure, with every site sitting at the same level. By default, this means there isn’t an information architecture, just a list of sites such as this:

Structure is then added to this flat set of sites. The primary way to do this is via hub sites, which allow business areas and intranet teams to group related sites together. For example, IT may have a main site providing support information for employees, but also a number of other sites relating to specific projects or services. By grouping them underneath a hub site, this provides a common appearance and shared navigation, as follows:

It’s expected that users will soon be able to put hubs within other hubs, essentially forming a tree structure. All of this provides some underlying structure to the way information is managed, and it all sits within the domain of the site architecture (as defined above).

Navigation (the navigation experience) is then placed on top of this collection of sites and sub-sites. There are currently multiple ways of doing this.

As a starting point, traditional intranet menus can be created, either as simple drop-down lists or as menu menus (as shown in the next image). At present there are all sorts of fiddly details about exactly which menu appears where, and the degree to which the menus are truly ‘global’, but the basics are straightforward.

A new app bar is also being rolled out, which provides a truly global menu for the first time, as a ‘fly out’ from the left:

These forms of navigation are all managed by the intranet team, and configured as desired. Microsoft is frantically releasing new features, so by the time you read this article there will have been many changes and additions, some small and some large.

The key point of all this is that the navigation experience sits on top of the individual intranet sites, and this must help employees easily find what they are looking for, as was the case for all previous intranets. And the only way to ensure that information is findable is to test the IA with employees.

Best practice methodology

In 2010, we published the book Designing intranets: creating sites that work, which described how to apply best-practice user-centred design (UX) techniques to intranets. This book now sits on the desk (or in the bookshelf) of thousands of intranet teams around the globe.

The approach described in this book was built on the fundamental principal that intranets need to be tested with users to ensure they are usable and findable. This can be done using a variety of simple but powerful task-based user testing techniques.

The methodology is as follows:

1. Understand staff needs and business requirements by conducting needs analysis with employees across the organisation.
2. Build an understanding of how staff think about information, using a technique called card sorting.
3. Develop a draft structure (both navigation experience and site architecture) for the intranet based on the results of the card sorting, needs analysis, best practices, and other sources.
4. Test and refine the draft structure, using a technique called tree testing to conduct hands-on testing of the draft structure with staff, and then revise accordingly. This is an iterative process.
5. Develop draft designs including page layouts for key pages such as the homepage of the intranet.
6. Test and refine the design of the intranet, conducting task-based usability testing with staff to ensure the designs are easy and intuitive, and revising where required.
7. Finalise the designs, and document to the required level.
8. Implement the designs in the platform, then launch and celebrate!

Putting it into practice

It is beyond the scope of this article to dive into every step (that’s covered in a 280 page book!). These, however, are a few key points relevant to SharePoint Modern-based intranets.

• The starting point for all meaningful user testing is to determine a realistic set of user tasks (as outlined in the article Identifying staff tasks) that employees are conducting on the intranet.
• Card sorting is a simple way of starting to understand employee behaviours, and there are multiple ways of doing this (as outlined in the article Card sorting: online versus offline).
• In terms of bangs-for-bucks, tree testing (as outlined in the article Tree testing for effective navigation) is perhaps the most powerful. Using an online tool such as TreeJack, teams can quickly test potential SharePoint navigation approaches, and then rapidly evolve and re-test.
• At a minimum, the final information architecture should be tested, refined and completed before building sites in SharePoint.
• The site architecture (how to use comms sites, hub sites, etc) can then be established to match the desired IA (with supporting intranet governance to ensure it doesn’t become a mess!).

None of this needs to be time-consuming or difficult, and it can be conducted while other more technical activities are going ahead. As long as you do some user testing (and avoid common myths such as the so-called three-clicks rule), you’ll deliver an intranet that’s pretty good for employees.

Get expert assistance

While the process outlined is not complex to follow, it does require the right skills and sufficient effort to get a good outcome.

In our intranet consulting activities, Step Two has helped a huge number of organisations to determine the IA and UX of new intranets. In addition to using the techniques listed above, we are also able to draw upon a depth of knowledge that few others have, including our experience with SharePoint Modern in all its forms. All of this speeds up the process, and delivers a better result. Get in touch, and we’ll find the best way to help.

Delivering an intranet that works for employees

While some projects may be driven by the necessity to move off an old platform and into the cloud, the overall goal for all projects must be to deliver an intranet that works well for employees. That means creating an intranet that works better than the old one to a degree that’s immediately noticeable by users.

To that end, all SharePoint Online intranet projects should incorporate the decades-old practices of user experience to inform design and structure decisions. Using lightweight and highly effective techniques, teams can be confident that the navigation options provided in SharePoint Online are used to their best effect. The result will be an intranet that’s usable, findable and valuable.