How I put a bloated intranet on a diet

Registers of Scotland (RoS) keep public registers of land, property, and other legal documents in Scotland.

As a small internal communications team, we kept employees updated with daily notices on the intranet and a monthly employee magazine. We also filmed important updates to support team meetings.

TL;DR

  • I moved the bloated, dated intranet into a healthy state, so we could finally convince senior management to invest in a modern content management system.
  • It helped increase engagement across teams, so they voluntarily approached the internal communications team with important news. Even ideas for stories.

My role

I was the content manager and designer for the intranet, monthly magazine and other bits and bobs to keep everyone informed. I also wrote articles and copyedited employee news and stories.

Intranet background

The intranet was a dated (estimated 11-17 years old) HTML website that ran on Dreamweaver templates. It had a single template controlling the main navigation. This navigation was inflexible and applied to every page of the site.

It wasn’t easy to find what you were looking for.

Search didn’t work well either. The results weren’t always useful, and they cached. I often had to ask the IT team to ‘kick the search’ to get it working.

What’s a Dreamweaver template?

Sites that ran on Dreamweaver templates were helpful in their day. A parent template would push HTML into each child. When you updated the parent, it would overwrite the child with the new DNA. But lightweight content management systems quickly replaced this ‘push’ method of managing HTML.

Untangling the scale

When Adobe bought Dreamweaver from Macromedia, they recommended sites on Dreamweaver have a maximum of 500 files.

When I joined Registers of Scotland, their intranet had over 16,000 files.

One of my first tasks after joining was updating a manual. I noticed my updates did not go live. I was told to wait until the cache cleared.

But I dug deeper.

There was a tiny difference between the URL on live and the local environment.

I remembered enough from my brief stint on Dreamweaver training to use the Get function. It syncs remote and local servers.

Roughly 7,000 files came down to the local server. Duplicates, orphaned files, and hundreds of absolute links to the wrong place.

We had well over 20,000 files on a site built for 500.

Coming up with a plan

It now made sense why the intranet was slow, crashed often, cached weirdly, and took hours to update navigation.

It also explained why there were so many problem files on live. There was no ‘development’ server or version control. If something went wrong, it broke on live.

These breaks were time-intensive (and frustrating) to find and fix. You needed to do much of it manually. Dreamweaver updates are recursive. If you made five changes in the parent template, it would edit all the files linked to that template with the first change. Then edit them all again with the second. Then the third. And so on and so on.

Managers wanted to solve the problem with a new intranet.

But no one would fund a new intranet when we had over 20,000 files and no plan.

I didn’t want to wait for this magic solution. So I worked with what I had.

Content audit

Finding ROT (Redundant Outdated Trivial)

Tools I used

  • Google analytics – for site visits, time on page and downloads.
  • Xenu – an old site crawler that I could use locally.
  • Excel – for the content inventory.

Things I did

  • Used Xenu to list every file on the intranet in a spreadsheet.
  • Compared duplicates using the dates changed to see what was current and pointed all links to the right file.
  • Worked through Xenu’s broken links report to repoint or remove broken links.
  • Added extra analytics code to track relevant downloads.
  • Removed all absolute internal links so that Dreamweaver could manage them.
  • Worked with the senior internal communications manager to agree to move manuals off the intranet (they were already on a team wiki).
  • Added site visits and downloads to the relevant files in the content inventory spreadsheet.
  • Identified the team each file belonged to (or made a guess).

After getting rid of the duplicates and fixing all the broken links, the next step was to engage the teams.

Engaging the teams

We already had a list of representatives from each area for the employee magazine. We tapped into that group to find the right people to help with the audit.

I split my spreadsheet into simplified lists for each area. It included analytics and a way to score the content for relevance.

I worked with two other colleagues to kick off team meetings to explain our goals. I wanted to help teams stop thinking of the intranet as a dumping ground for random files and start thinking about “user need”.

An image of the guidance I wrote for creating and maintaining content.
Guidance I wrote to help teams understand what content was useful and how we’d prevent ROT.

First goal – remove the ROT

Most teams identified their ROT content easily. Only one team really stood out as indecisive or resistant. It came from a place of fear, so I reassured them I was archiving the content somewhere safe.

It helped. I archived hundreds of files.

Second goal – create useful, relevant content

I asked the teams to consider the queries they were fielding each day. Were there themes? What were the pain points? And did the content they have on the intranet actually address any of them?

While some teams were resistant because they thought it meant more work, some were happy to make changes. One representative said to me, “I thought you were the no team”. They’d been asking for changes for a while.

Introducing flexible navigation

While the audit work was ticking along, the organisation was undergoing a digital and business transformation. IT teams were introducing a self-service model. Development teams were moving to Agile.

To keep pace, I created new templates with Bootstrap. I kept the colours the same, but used responsive layouts because development teams were putting their pages on large TVs. ‘Microsites’ are not best practice, but they worked because it was the best way to meet the team’s need to get to the information they needed quickly.

This work also meant I got to know the development and IT teams well. It made it easier to make other improvements to the intranet (like getting it moved onto a faster cloud server with more space for videos).

Once I’d archived hundreds of files and spoken to the teams about their needs, I created over a dozen templates to control the navigation. This might seem counter-intuitive, but more templates meant faster updates. By separating top and side navigation, sitewide updates took minutes, not hours.

Onward and upward

The teams that volunteered to work with me to redesign their content paved the way for other teams to do the same. Teams approached us unprompted.

The intranet was faster, and we improved the navigation often as we identified additional needs.

Even better, this scaled down intranet wasn’t as intimidating to ‘fix’. We finally got the budget and resources to get a CMS.