On the Govt.nz project, we designed the content before we designed the website. This happened in part because we had a delay in getting development resources on board when we started work on the beta website. This delay proved to be a blessing in disguise because it helped us design a better site.
Design usually comes first
When I’ve worked on websites in the past, the designers and developers have toiled away and presented me a lovely designed site with templates and a framework for my content. Sometimes I’ve been asked my opinion, but that’s been the exception rather than the rule.
Then when we’ve been adding content and defining information architecture (IA) needs we usually have to do lots of rework of the design which takes time and resources, but that’s just how things are usually done.
We did things differently in this project.
Learning from alpha
During our alpha phase we:
- tested different ways of presenting content
- tried out different page types
- drafted a style guide.
During this testing we realised quickly that our users really needed help navigating through government services, especially if they had to interact with more than one department to get what they needed or were entitled to. For example, if you’re having a baby you might need to interact with 5 different government agencies depending on your specific circumstances.
This testing meant we knew:
- what types of content our users required for the site
- what the basic structure of each page template needed to be
- how we could make the IA work.
This was due to testing our alpha version’s IA and content to see what users responded to and what didn’t work.
See We built a site just to throw it away.
Planning content for beta
So instead of just providing a list of links, or trying to create really detailed content, we shifted our approach and decided to focus on:
- signpost pages which bring together a range of government services to help users complete a task
- quick answers, which do exactly what they say — answer a common question quickly.
Examples
Signposts
- Tracks and walks
- Going back to work after having a baby
- Pay the right amount of tax
Quick answers
- School terms 2014
- Do you need a visitor’s visa?
So what else did we do?
We worked out what priority content we should put on the beta site.
See Channelling Sherlock Holmes.
We also did a lot of research into the language people use when looking for government information. We looked at how users search for information and the actual words they used (using tools like Google trends). We then made sure our content used the language that people actually search with.
We also looked at:
- what different types of content we would use on the site
- how we could show content relationships
- what content would actually be useful for users
- what information architecture and types of navigation we could use.
When the developers and designers started to build our beta site, the requirements came from the content work we had done. This saved us time and resources as we didn't have to go back and forth.
How is this different?
How often have you been asked to sign-off designs for templates with lorem ipsum or placeholder content?
Have you ever been given a finalised site that didn’t deliver the needs of the IA or allow for all the types of content that you needed — and then there wasn’t any time or budget to “fix things”? I know I have.
What I’ve learned is that a site that’s nice to look at isn’t always useful. It doesn’t matter if users can get to the right page if they don’t understand the words on it.
We’ve designed beta.govt.nz around the content we were publishing (which matches our user needs).
Advantages of putting content first
We’ve built templates that match our content models, so it’s easier to present consistent content.
The developers didn’t have to rework templates or designs to fit the content, so we saved time and money as well.
Disadvantages
I’m still trying to think of one.
Designing your content first will help you build better websites
If you want a useful site, you should work on your content requirements first.
You should:
- do a content audit or content plan and work out what you need to keep and what needs to go, this will help you build your IA
- work out what types of content you’ll need (e.g. service pages, guides, quick answers)
- review and re-write your content — even if you think it’s fine, another review always makes it better.
You should also test your content with your users to see if it works for them. You don’t need a website to do this. Print out some of your content and show it to a group of your users. We did a lot of our content planning and drafting just using Word documents.
Content’s not important, is it?
“Content is easy,” so I’ve been told. “Anyone can write content”.
They probably can. But is it any good?
You wouldn’t redo your entire corporate website without hiring professional designers and developers. Why don’t you hire professional content people as well?
A website is just a way for users to access information and services. Its visual design or functionality won’t fix your processes or make your words better. I’ve come to the conclusion that the content should define design and functionality.
What’s next for the content on beta.govt.nz?
We’re currently working on:
- refining our style guide and content models
- reviewing, refining and adding to our content
- more testing
- rolling out more content types, to describe services in more detail
- mapping typical user journeys and seeing how we can connect information across departments into complex guides
- figuring out how to deliver an API (application programming interface) for content so agencies can get our content and use it on their own sites. Wouldn’t that make life easier with just 1 source of truth?
The site is live and we’d love your feedback. You can leave a comment here, send us feedback through the beta site itself, or you can email info@digital.govt.nz.
