My team has just implemented a completely new information architecture (IA) for our intranet. It’s taken just under a year from first card sorts to go-live.
I presented on the practicalities of making changes such as these at Intranet Now earlier in 2017. Now that we’ve finally launched the revised site, I’d like to offer some lessons learned from the project.
If you’re embarking on something similar, feel free to get in touch – I’m happy to discuss our experiences.
1. Don’t underestimate the effort involved
Prior to embarking on wholesale changes to the site, we looked at whether we could cherry-pick problem parts of the IA and change them in a light-touch way. After several weeks assessing possible approaches, we concluded that we’d have to redo our entire architecture. For context, we had around 1500 content pages, not including news. It took us 12 months from initial card sort to go live. Understand that this is not something that lends itself to quick fixes, and be prepared for a long haul.
2. Test and test and test again
We conducted five rounds of user testing before we settled on the new IA, and could easily have carried on for more complicated parts of the structure. At some point, though, you have to stop and commit, however, only do that once you are confident that you have the insight you need to confirm what your new structure should be. Try not to cut corners – it will compromise the integrity of the end result.
3. Bring content owners with you
It’s vital that you start speaking to your content owners before you embark on a restructure, and you need to involve them at every step. Your restructure is likely to see their content sections split up and their favoured labels changed. While some colleagues will understand the need for this in order to make content truly employee-focused, others will resist hugely. Be prepared for comments such as “where’s my page?” and “where’s my content?”. Which brings me to lesson four:
4. Evidence is vital
You need evidence from your testing for two main purposes. The first (somewhat obviously) is to allow you to make sensible decisions about how you are going to restructure your content. The second is that you will need to convince the doubters that your approach is correct. There is nothing more powerful than being able to justify a decision based on employee insight, especially when it has been tested multiple times. Even so, you’ll meet resistance from some content owners. Stick to your guns.
5. Trust your methodology but use your judgement.
I like to think this point is complementary, rather than contradictory, to number four. Some of your testing will throw up curious results, or things that don’t feel ‘quite right’. This might be down to the test questions being too open to interpretation (see also the point below). In such cases it’s ok to use your judgement to make decisions. But you need to make the judgement after testing, not before – again, don’t cut corners, or make assumptions that haven’t been tested.
It’s also important to be able to speak authoritatively about your methodology. In conjunction with test evidence, it will help you address colleagues’ concerns about how you are sure the changes you’re making are right.
6. Some content is hard to locate
There will be content that you just can’t find a home for, or that is very difficult to label in a user-friendly way. It’s just the nature of the content on your intranet, so why fight it? In such cases, try to find the user journey that is the closest fit. You might need to cross link to the content from other pages if there isn’t one obvious place.
7. Impact on site design
Will your restructure have an impact on your site layout? Will your megamenus need redeveloped? If your site is built with responsive design, what impact is there on mobile and tablet views? Ask these questions early, and factor them in to the overall site changes. Bear in mind that you will need to user test any functional and design changes too.
8. Impact on links from other applications
There are likely be links into the intranet from other applications, and if you change the structure of the site this will cause those links to break. Plan early for this impact. Be mindful that some applications have set change cycles, or are difficult to amend quickly, or incur a cost if they need changed. The difficulty here is synchronising those changes with when you push the new structure live. In some cases it might not be possible for them to be changed on the same timeframe – in which case, there will be mopping up to do, and you can expect to receive criticism for it.
Employees are also likely to have favourite content and pages bookmarked in their browser. These will cease to work once you make the change to the new structure. One potential way to mitigate this is to offer a ‘link amnesty’ and provide individual assistance to help employees replace their links. But that might not be practical in larger organisations, and managing this impact through prior communications is preferable.
9. Impact on search
If you are changing your structure, there could be an impact on search. Cached results can be problematic at the point of switching over to the new structure – expect to be met with complaints, or faults logged, about inaccessible content. In addition, be aware that you might have to change promoted links, or make amendments to configuration relating to keywords/synonyms to reflect the new structure.
It remains the case that one of the most important aspects of a change like this is how you communicate it to your users and wider stakeholders. Aside from the main employee base, there will be content owners, application owners and a variety of senior stakeholders to keep informed and happy. Regular, early communication with the content owners and senior stakeholders is vital; employee communications can take place closer to the change. At the point of launch, offering a tour of the new site can be helpful.
The key is to ensure there are no surprises come the changeover – so everyone is aware of what is happening, when, and the nature of the change.