OpenCities help center

The challenge

Make the client-facing help content for OpenCities more discoverable, comprehensive and easy to understand, so we can empower our clients to serve themselves without needing to contact our support team.

My role

Acted as project lead
Ran discovery phase, including running research sessions, synthesising data, and making recommendations on content, navigation, design and functionality
Worked with developers on technical improvements
Worked with technical writer on content improvements

The process

I started the discovery phase by collecting benchmark stats for everything I could. The data wasn’t perfect, but it was certainly better than nothing. The plan was to come back to this after implementing our solution to see what difference we’d made.

Benchmark stats from a variety of sources

I then interviewed clients, along with some of our staff members, to get a better sense of how the help centre was currently being used. As a new member to the OpenCities team, it was crucial for me to understand this context before going any further.

Getting some uncomfortable truths from our clients

I followed up these sessions by inviting a couple of clients to do a card sort of the existing help centre categories and topics to see where the current structure was succeeding and failing.

A client sorting the categories and topics covered in the help centre

I also asked some clients to complete a tree test to see what path they’d take to find particular pieces of information (and to see how these paths aligned — or didn’t — with the current site structure).

The next step was to audit our content to identify changes that needed to be made and gaps that needed to be filled. Our onboarding and support team members were crucial contributors to this stage, as they’re the ones closest to our users — particularly at the points at which those users experience frustration.

Then, we summarised, ranked and prioritised all the issues we’d uncovered during the discovery phase.

It was time to start tackling some of those high-priority items.

The solution

Access for all content authors

We realised that because we allowed only two primary contacts per client to access our support ticket portal, many of the people using OpenCities day to day didn’t even have access to our help content (which was housed in the same portal).

We needed a way to give everyone access without opening the support ticket floodgates. We decided to offer each client a generic login that each of their staff could use to access the help.

A more intuitive structure

Using the insights from our card sort and tree test sessions, we came up with a new site structure that was more in line with users’ needs and expectations.

The new structure was reflected on the help centre homepage

Titles that mean something

Many of our topic titles were feature-driven rather than benefit-driven. We renamed these so that it was clearer what users might use the feature for, even if they didn’t know what the feature was called.

‘URL Mappings’ became ‘Create custom URLs for pages’

Content users can easily read and scan

Many of our help topics had originally been written by business analysts or marketers, and didn’t always hit the spot. Our new junior technical writer and I worked to update these topics so they were easier to read, faster to scan, and followed best practices for writing for the web.

I also — with help from our developer — updated the design itself, introducing a more legible typeface and larger font size, a more obvious heading hierarchy, increased white space, bigger screenshots, callout boxes for important info and more.

A help topic I wrote that puts the benefits first, and chunks info using subheadings and numbered steps

New high-priority content

We knew from our content audit what topics needed creating, so we wrote as many of the high-priority ones on the list as we could within the timeframe.

One of the high-priority topics users were crying out for

Communicating the changes to clients

It was important to not only inform clients of the changes, but make sure our help center was front of mind the next time they needed help — we wanted to retrain clients who’d usually log a support ticket when they faced an issue, and get them searching the help as their first port of call instead.

We also made sure to provide a way for clients to offer feedback so we could continue iterating on the changes we’d made.

Email introducing clients to the new-look help centre

The results

The help centre experienced an increase in monthly pageviews from 5030 (Feb 10-Mar 9 2017) to 6351 (Sep 25-Oct 24 2019). In the same timeframe, it experienced a decrease in average session duration from 9 min 22 sec to 5 min 25 sec.

These stats are open to interpretation, but we believe they show a promising trend of clients accessing the help more often, and finding what they need faster. We’d need to do a little more digging to understand whether our assumptions are right.

We also improved the readability of a number of topics, in some cases pretty significantly.

Comparison in readability between original and revised help topics (lower score is better)

What’s next

Analytics are great, but they don’t tell the whole story. It’s not until you sit down with real users that you understand the ‘why’. We did a little bit of content testing along the way, but I’d love to have enough time and resources to observe more users navigating the help centre, reading the topics, and using the information learned to try and complete their tasks.