Goals: 

Initially, the goals were to audit Tableau Technical Support’s Confluence space and improve the experience for current users by simplifying the navigation and putting content governance processes in place. Along the way, the scope expanded to overseeing the migration to a new instance of Confluence.

My role:

I conducted the audit, coordinated the cleanup of outdated or duplicate pages, designed a new page tree, and wrote a content governance plan. I conducted user research at different stages to guide decision-making, and communicated updates to relevant stakeholders whenever needed. Before the migration, I also tested the new instance to gauge changes we’d need to prepare for; after it was complete, I created new templates and pages needed to organize the content.

Deliverables:

• Representative audit of 1000+ pages displaying page views, page age, content type, audience, and broken links.

• Recommendations to keep, update, or archive each page, plus improvements to the navigation, content freshness, and governance based on the audit.

• A backlog of content to further review and update after the initial cleanup.

• New labels and labeling guidelines, based on page type, team responsible, and category of content.

• A new style guide that would make it faster to create pages and to make them easier to read and understand.

• New templates on Confluence with custom components based on the content type (ex: A “Directory” page helps orient the user to a particular section, while a “Process” page describes when and why a user might perform a specific task.)

• A governance plan including the maintenance model, contribution guidelines, and how to review feedback and available analytics.

Results:

• The space went from over 2,000 to 1,500 pages after the audit and cleanup, ensuring that a much leaner, more up-to-date space would be migrated.

• Pages were labeled using a new, consistent system.

• I reorganized the space by grouping pages topically, reducing the number of items in the page tree from 31 to 7. I wrote and implemented labeling guidelines to make pages easier to find and review in the future. 

• The migration went smoothly, with no disruption to teams reliant on the content. Macros that were incompatible were updated or removed. 

• I created a new home page after the migration that helped improve navigation to the new main sections

Before:

My initial review, interviews with stakeholders, and an in-depth inventory and audit revealed multiple issues:

• It was a true wiki in spirit, not governed or maintained. Content was created by anyone who wanted to, and some pages contained passwords without any security measures to protect them.

• Content was out of date. The home page hadn’t been modified in months; for some pages, it had been years. Some pages even had comments noting the content should be disregarded, and some pages had large sections of text struck out.

• Different teams seemed to “own” different sections, with little coordination between them. Pages were organized by the team structure, not based on relevance of the content within them. Maintenance (if any) varied widely between teams. 

• I saw similar content in different places, and there was no labeling system to help with search or organization.

• The disorganized nature of the pages might be familiar to a tenured Technical Support Engineer, but new engineers struggled to find things. 

• Given the above facts, engineers didn’t always trust the content, and often asked a lead to vet the information was still valid. This was really inefficient all around. 

After:

• The outdated blog (209 pages) and another 531 pages were archived (these represented 65% of the pages audited. The remainder (more than 300 pages) were added to a content backlog for closer review and link updates.

• At the start of the audit, about 40% of the pages hadn’t been modified in the previous 5 years. By the end of the archiving stage, this was down to 17%. 

• New page groupings were validated in a survey of 50 respondents. This resulted in 568 pages being reordered into 7 main sections organized by the main type of information they contained. New parent pages were added when needed. 

Process:

The first steps I knew I had to take were to understand the scope and existing experience of the Confluence space. 

It quickly became clear that Tableau’s Technical Support team frequently used the space as they resolved cases (Google Analytics indicated there were close to 100,000 page views a year). How they used it varied by role - this is where a JTBD framework came in handy

However, the experience of the space was far from ideal. In initial interviews with stakeholders, they used words like “mess”, “mosaic”, and “rabbit holes” to describe it.

An audit was a natural place to start. I developed a detailed spreadsheet to capture the page title, last modified date, type of content, audience, and if there were any broken links. I used this information, plus page view traffic from Google Analytics to make a recommendation: keep the page, update it, or archive it. Eventually, I also added a suggested new location based on the new navigation I built out.

While I was able to conduct the audit independently, I needed team managers from each region and, in some cases, subject matter experts, to vet my recommendations for each page. I coordinated short reviews with all of them via a shared spreadsheet. Their task was to confirm whether to archive, keep, or update pages based on my recommendations. Pages that would take a while to update were added to a backlog they could pull from as time allowed.

It was important to clearly communicate to the broader team what the audit entailed, who was involved, and how we planned to keep disruption to a minimum. I posted announcements in Slack, wrote a detailed document anyone could follow along for updates, and kept a survey open for feedback throughout the process. Feedback was largely positive, like:

When it came to organizing the pages that wouldn’t be archived, I decided to survey Technical Support about the navigation and page tree. Based on the survey responses, I decided to relabel some of the sections.

Once the sections were in place, individual pages could be moved to the right one. Then they were reviewed to see if the titles needed updating, if they duplicated content, etc. 

I also came up with a labeling strategy to help keep the pages organized in the future. I added different labels to each page to represent:

• Content type. These ranged from “Announcements” and “Reference” to “Technical Training”, among others, and matched distinct templates I created for each type. 

• Team responsible. Filtering by team would make it clear which pages each one had to update.

• Category. To helps with finding content gaps. 

A couple of months into the project, it was decided that Tableau’s instance of Confluence would be migrated into Salesforce’s. There were several benefits to this, and cleaning up the current space made even more sense in light of the upcoming migration. 

I was the main point of contact for UAT testing ahead of the migration. In the absence of test cases from the migration team, I created my own list of features and macros to check. I compared these and took detailed notes. In the course of testing, I identified several macros that would not be consistent across Confluence versions. I reported several bugs and feature inconsistencies, only to discover that the test space was not configured properly (it wasn’t at parity with the actual production space). I also noticed that images weren’t rendering. This fact actually ended up delaying the migration, because the Atlassian team needed to be engaged.

When the migration process finally happened, I monitored Slack channels. I went through the test cases again just to be sure images and macros rendered as needed. Then I implemented planned design changes using the new features and macros we had access to. This included adding new pages, adding new templates, and redesigning the home page to feature the most popular pages and a search bar to make it easier to browse the remaining content.

I also created a new maintenance and permissions model for the team to review. However, this phase of the work stalled as an uptick in Support cases took priority.

[add screenshot of governance plan]

Unfortunately, a reorg also meant I couldn’t see the content maintenance through. I transitioned some admin duties (like granting permissions) to another team and expected the Confluence space to run pretty much on its own. Unsurprisingly, given the absence of direct governance, some pages disregarded the new navigation structure. But all things considered, the space was still serving its audience when I last reviewed the metrics. From the date of the cutover to the new instance to the end of the year, there 50,597 views from 1,767 unique viewers. 17 new pages were created, while 245 edits were made.

What I’d do differently:

• In my user interviews, I spent more time talking to team members in the USCA region than the others. I gathered feedback from the other regions too, but if I were repeating this project, I’d aim for a more representative group of interviewees.

• Unfortunately, there was a significant disconnect between leadership’s appetite for documentation cleanup and what certain managers felt was needed. I had heard repeatedly from lower levels that it was hard and frustrating to find information, but leadership prioritized other work. In future phases, I looked more carefully at leaders’ priorities to guide the projects I proposed and worked on, to better secure resources to complete the work. 

• Clearly explaining concepts and their value to the organization might have helped. Telling the story of what content governance looks like and why it matters might have garnered more buy-in. 

• Some of the project phases didn’t get completed within the expected timeline, which created extra work. For example, while I waited for the archival recommendations to be vetted, I sketched out the new page tree and label pages based on all existing pages, not in the cleaned-up state. That meant going back to trim down the page tree and labels (touching pages two to three times instead of once).

• I think it was easy to view the wiki as a mess that needed cleaning up, which sometimes also meant forgetting that a lot of people worked hard to build it up to where it was. Just because it was in a less-than-desirable state at the time didn’t preclude that they originally had good intentions.