Govt.nz - how we create our content

Making content short, concise and easy to read is hard.

The content process we’re developing for Govt.nz includes examples of good practice from across government — which is to say that we stole and have reused some of the best processes we could find.

We’ve previously written about how we designed content before we designed the website. This blog post is about how we actually write and review our content.

Everyone in our content team has years of experience writing and creating web content. We all edit, review and comment on each other’s work. The entire team is encouraged to give their opinion and ask hard questions. It can make for some spirited discussions, but there are never hard feelings and it usually results in a lot of laughter. Mind you, some people on the team take great pleasure in asking these hard questions or using their red pens.

Our process

1. Identify what we need, and when

The content on beta.govt.nz is "thin" content, which means we give an overview of a task or life event and then link to detailed agency content.

We’ve already written about how we chose the content we’ve included so far: Channelling Sherlock Holmes.

And about our fact-checking schedule, which tells us when we need to have content ready: Let the fact checking begin.

2. Allocating the work

We work in an agile project environment, which means we allocate work in fortnightly sprints. Once we’ve chosen and prioritised our content, we create a user story for it in our backlog.

We write our stories using personas (we’re using the personas developed to support Better Public Services Result 10). These personas help us frame problems and define the content we’ll create.

Each user story is based on a specific user need. We use the personas to give us a human touchpoint for questions — what would this person need if they were in this situation? Would they understand this language?

3. Research

Like everyone else, when starting to research a topic I start with a Google Search.

I take notes and copy links to get an overview of the facts the user will need. I then start to draft the page. Depending on how complicated the topic is or how spread out the information is across different websites, this can take a few days’ research.

I have to ask: if it takes me a few days to find everything when I’m familiar with government, how long is it taking users who don’t know as much about government departments and services?

4. Write

Once I’ve got the raw information, I start to refine it into something that will be useful.

Using the right words

I use Google Trends to see what words Kiwis actually use when they’re searching for information. This can be quite eye-opening — and can sometimes prove just how wrong I am about wording I want to use. It can also help when we’re arguing about words to use.

Example

When we wrote our content about speeding tickets and infringement notices, we checked what wording New Zealanders were using to search, to ensure that our content will be picked up on a Google search.

We compared the phrases ‘fines’, ‘speeding ticket’, and ‘infringement notice’.

Trends for ‘fines’ (blue), ‘speeding ticket’ (red), and ‘infringement notice’ (yellow). See description below.

Trends for ‘fines’ (blue), ‘speeding ticket’ (red), and ‘infringement notice’ (yellow). See description below.

The graph above, taken from searches in Google between January 2010 to January 2014, shows clearly that:

• the phrase searched for the most was ‘fines’ — more than 10 times the other two search terms
• searches for ‘speeding ticket’ were on average double that for ‘infringement notice’.

Ensuring readability

All the time I’m writing, I’m checking the reading ease score of the document to ensure the page has a score of at least 65, which helps confirm the content is easy to read.

I usually go over a page 3 or 4 times until I’m sure it’s ready for review.

5. Review

This part I’ll admit we stole.

The review process we use was developed as part of the Welfare Reform Work that was undertaken by the Ministry of Social Development in 2012/13 — they just won a Plain English Award for this work.

I’ll ask a couple of my colleagues to have a look at what I’ve written. Fresh eyes can see if I’ve missed anything and ask questions that I’ve not even thought of.

If it’s something really nasty or I’m having real problems, a group of us will get in a room to hash it out.

We check that:

• content matches our style guide
• the content drafted meets the user need defined at the start
• the content hasn’t grown into something much more complicated.

Once we think the draft is solid, we load it into the content management system. We do this to check that everything works as it should, and that it looks correct on the screen, before we move on to the next step.

6. Read aloud

Thank you to colleagues at Internal Revenue for teaching me the value of reading all content out loud.

For each page, at least 2 members of the content team get into a room to read the page out loud. We’ve found some wonderful word salads doing this — and hearing the words gives you back perspective you’ve lost being so close to the content. It’s also a great opportunity to have someone else check the formatting of the page, and it’s 1 more opportunity to spot and fix typos.

The person who wrote the page doesn’t do the reading; she takes notes as changes are flagged. The changes can range from suggestions for different words to make something easier to say, or moving sections of the page around to make it more logical. On more than 1 occasion, we’ve gone right back to the start of the process at this point because the content was just not working properly.

7. Publish

Any final changes are made and the page is published.

We then add the page to the fact checking list to ensure that it will be correct when we move beta.govt.nz into production later this year. Once the govt.nz site is live, the fact checking will already have been done.

It’s hard to make things easy — and it takes time

Making content easy to read and easy to understand takes effort and commitment from an entire team of people.

We criticise and critique each other’s work and this can be a little daunting, or even frustrating at times. No one likes to be told they need to rework something, so we make sure we celebrate and acknowledge great work too, even if it doesn’t happen on the first attempt.

We were recently finalists for 3 Plain English Awards, which we see as outside validation that our approach to content is working.

The collaborative approach helps the entire team build skills. It also allows our site to have a consistent voice which is so important on sites with multiple writers.

What process does your organisation use to create content? We’d love to hear your experience.