How to build an intranet
When I started at the Royal Borough of Greenwich, I joined a team tasked with redesigning our staff intranet.
We’re now 3 years, 1 live product, 2 releases and several iterations into this work. What follows is my attempt to write something about it.
Please take a seat in my intranet time machine, where we’ll start by travelling back to…
Discovery
The Digital team at Greenwich was very new in 2021, and the intranet project was one of the first to get started. The council had 4 (some say 5) different intranets at the time. Our task was to replace them with 1 new product.
Because we were all new to the council and lacked a bit of shared understanding about how our discovery would look, things quickly went a bit haywire. This probably led us to focus too much on the problems with the existing products and not enough on why they were happening or how we could realistically solve them.
That said, some good things did happen.
- We interviewed a lot of stakeholders, setting foundations for relationships that would carry us through this project and beyond.
- We did a huge content audit, which helped us start telling the story of why our staff-facing content was struggling to help people and why everyone was just picking up the phone instead.
- We learnt a lot about how managers used (or tried to use) the intranets to support their teams.
Despite these positive things, we still reached the ‘end’ of our discovery with far too many findings and not enough insights or ideas to help us move forward. This led to an uncomfortable end of discovery review, a serious rethink, and then…
A discovery spike
This was a bit of a ‘one month to save your discovery’ situation, but thankfully it all worked out.
The team split into squads and threw ourselves into answering two important questions: what technology would we build on, and what would staff use the new intranet to do?
By the end of this short spike of work, we had decided to build on SharePoint. It wasn’t the choice we thought we would make, but it came out as the right choice for us, because:
- it fitted our existing technology estate, which is very heavily Microsoft-based
- we had the right team in place to be able to build and maintain it
- it was decent fit with our product proposition (what we wanted to build and why)
We also emerged with a long list of tasks staff might use the intranet to do. Two books really helped with this: ‘Task Based Intranet Content’ by Lizzie Bruce, and ‘Good Services’ by Lou Downe. We’ve not always been able to follow the advice of either book consistently, but it’s always been in my head and helped us one way or another.
Alpha
I loved the alpha phase of this work, and I’m pretty sure the rest of the team would say the same. After a long and tricky discovery, building quick prototypes of bits of intranet felt encouraging and taught us so much.
In this phase we prototyped, tested and iterated 2 journeys, partly on Figma and partly on a test SharePoint site.
One was the long-established intranet classic ‘book annual leave’. This worked well, and we could see how to make journeys like this easier for staff.
Another was a brand new idea, about helping staff understand what help they could get from other teams. This worked less well, and we didn’t take it forward.
At the same time, another content designer joined the team and got stuck into research to learn how to best organise content on the new product.
By the end of alpha, we felt confident we could build enough journeys to make a useful intranet. Our end of alpha review was much better than our discovery one, and we set out into beta.
Beta phase 1 — build everything new
We had some grand ambitions at the start of our beta phase. We were going to rapidly build a new intranet, and publish only the best quality, most up to date content. It took about 2 months before we realised we needed a rethink.
The problem seemed to be that we were trying to make too much change at once. We were already asking our colleagues to let us move all their content to a new place. The idea of leaving some of it behind or completely transforming the rest was a big deal.
We also didn’t know how we would actually move from multiple intranets into 1 without ongoing disruption and confusion for staff. To help us work this out, our tech lead suggested we thought about the products as octopuses swimming in a tank. How could we move content from one ‘octopus’ to another and safely retire the old ones?
We were getting there, but while we figured things out the problems with the existing products continued. A lot of staff couldn’t access them, and their content was getting more and more out of date by the day. But with the new product still a distant possibility, it was hard to get time in people’s diaries to talk about it.
Team members started to joke about whether we could just build a new intranet, retire the old ones, and then deal with making the product better. The jokes soon became less joke-y. Suddenly, we had a new plan.
Beta phase 2 — minimum viable intranet
This was the point in the project where we literally chased our head of product up the road as she headed out of the office to get her to agree to our new approach.
Fortunately she did, so we set about planning how to shift vast amounts of content from the old sites to the new one. Our aim was to update and streamline things as much as we could in the process, but our main aim was to move fast.
Suddenly, it was less about gradually combining several products into one and more about bringing the new one to life as fast as we could. ‘What happened to the octopuses in the tank?’ someone asked. ‘One has eaten the rest,’ was the reply.
Content designers don’t love the words ‘lift and shift’ (I remember the visible shudders I got from my team when I said it) but what kept me going during this time were our very thorough content audit notes. They helped me keep track of everything, make whatever improvements I could, and stopped anything from getting lost. We used Airtable for this and I would recommend it.
Alongside this, our product designer did a lot of work with our Communications team colleagues to make sure the new intranet would meet their needs as well. Eventually we had something that would just about work for everyone, and the next thing to do was…
Launch
Launching this thing is a bit of a blur in my mind now, but one thing really stands out: our delivery manager was on holiday for two weeks over the launch date, and nothing went awry. This feels to me like a sign of success.
Here’s a few things that helped us get over the line.
- Before his holiday, our delivery manager made us write a list of things we thought we needed to do or finish before launch. He then got us to question everything on this list, leaving only what we absolutely had to do. This made things feel a lot easier.
- The team really pulled together in the run up to launch. We tried to clear our diaries as much as possible and were grateful to other colleagues for supporting us to do this.
- We all came into the office on the day itself. This helped us deal with any last-minute bugs and setbacks. It also just felt supportive and collaborative, which is good when you’re feeling the pressure.
What we’ve been up to since launch
So, it’s been a year since we launched our first version of the intranet.
Since then, we’ve had some good results.
- The site has been visited over 100,000 times (excluding people opening just the homepage, as this is now our default browser start page)
- 74% of staff in our last staff survey said they used it to find out what’s happening across the council. This is more than any other channel.
- All of the old intranets have been retired, with no or minimal disruption to business processes.
Launching the new product opened the door to a lot of the improvements and changes we’d wanted to make earlier. Here are some of them.
- We’ve replaced an old, outdated phonebook feature with a new one that runs on our organisational data and is easier to keep up to date.
- We’re rolling our improvements to the lower level information architecture on the site, creating more intuitive menus and categorisation.
- We spent a lot of time adding metadata across the site so that content and documents were easier to find and maintain.
These days our work has shifted more towards the many staff-facing transactions on the intranet. Our focus now is mostly on the content and forms that make up these journeys, finding ways to improve them in the short term and work towards digitising them in future. We’re working with colleagues to make the policies behind them easier to use as well.
If you have any questions about the past or the future of the intranet at Royal Greenwich, please get in touch — we’re always happy to chat.
