Content design is not just about words on the page. It’s the links, the images, the format it’s in. And it’s not just about designing a specific page – it’s about creating a whole user journey.
Future Learn run a free Introduction to Content Design online course, linked to the UK Government GDS team, and these are my course notes.
What is Content Design?
Content is what drives the success of everything online. But content is just the words, the copy, right?
Wrong.
Content is not that simple. In fact, you probably won’t notice much of the content while you read this – it’s basically everything you see or hear online. Let’s look at some examples.
Things that are copy (and also content):
- a headline
- an image caption
- what a link button says (the ‘call to action’)
- the text of a drop-down menu
- an email subject line
- a meta-description (some hidden words that tell Google what a webpage is about)
Things that are content (but not copy):
- an animated gif
- the size, style and colour of the typeface
- how things are spelled
- where links go to
- deciding what subjects to include on a webpage and how they relate to the rest of a website
Content design is not just about words on the page. It’s the links, the images, the format it’s in. And it’s not just about designing a specific page – it’s about creating a whole user journey.
Content designers work on end-to-end journeys to help users complete their goal. In this role, your work may involve the creation of, or change to, a transaction, product or single piece of content that stretches across digital and offline channels.
Content designers make sure appropriate content is shown to users in the right place and in the best format. They start working on content at the discovery stage and work closely with user researchers, service designers and interaction designers.
Who does what on a multidisciplinary team?
Teams can look very different depending on the size of your organisation, the service or content you’re working on and other priorities.
In central government, a service team includes people doing a variety of different roles (this type of team is called a multidisciplinary team). We set them out below. You may need to include additional roles depending on the size of your service and your context.
Roles your team must have
A government service needs to have people with the following roles or skills, either in the team or available to it:
- product manager
- service owner
- delivery manager
- user researcher
- content designer
- designer
- developer
The skills you need will change throughout the lifecycle of your service. Your whole team, and in particular your designers, user researchers, content designers and developers, must work together to design, build and iterate a service based on the user needs of the people your service is aimed at.
Product manager
Your product manager works with the delivery team to:
- make sure your service fits in with your organisation’s priorities
- define what the future goal of the service is (often called the ‘product vision’ in agile project management)
- make sure your service will meet user needs
- make sure your service is accessible to everyone, including people who have a disability
- prioritise user stories for each work sprint
- comment on technical, content and design solutions
- accept user stories when complete
Service owner
Your service owner must have the decision-making authority to deliver on all aspects of a project. They also:
- have overall responsibility for developing, operating and continually improving your service
- represent the service during service assessments
- make sure the necessary project and approval processes are followed
- identify and mitigate risks to your project
- encourage the maximum possible take-up of your digital service
- have responsibility for your service’s assisted digital support
Delivery manager
Your delivery manager is responsible for:
- setting up the agile environment your team needs to build and iterate a user-centred service
- removing obstacles or ‘blockers’ to progress
- helping your service team become better at autonomously organising their own work
- making sure accessibility is factored into each feature or activity the team’s working on
User researcher
Your user researcher helps your team learn about the people who will use your service. This will help you design and build a service that works well for all your users, including people with a disability and those who need support.
On your team, they will:
- plan and carry out research using a range of methods
- involve the team in user research to help everyone develop a deep understanding of your users
- create clear findings that help your team continuously improve your service, based on data and evidence
Content designer
A content designer is responsible for the content in your service. They contribute to service design by:
- developing content plans and strategies based on user needs
- writing clear, usable and accessible content in plain English
- reviewing content to make sure it’s accurate, relevant, accessible and written in line with GOV.UK style
- communicating the principles of content design to your service team and others across your organisation
- advocating for users of your service by challenging requests that don’t support their needs
Designer
Designers help your team create user-focused, accessible services and a consistent user experience.
Depending on the type of service you are building, you may need a team of designers with a range of different skills, for example interaction, content, service or graphic designers. However, in discovery, it’s often best to hire an interaction designer as the first member of your team.
Developer
You need developers on your team to:
- build accessible software with a focus on what users need from your service and how they’ll use it
- advise on the technical feasibility of designs
- write, adapt, maintain and support code
- continually improve the service with new tools and techniques
- solve technical problems
Find out more (including job descriptions and related roles) in the GOV.UK Service Manual – roles in teams.
What skills do Content Designers need?
But when you design content, you need more than an ability to write in plain English. You need to understand how people use the web, you need to be able to work with stakeholders, and much more.
In the video above, content designers talk about the specific skills and knowledge you need in the role.
And in the video below, Padma – a content designer – talks about 3 important things you need when designing content:
- Understanding of the topic.
- Ability to build and maintain good relationships with colleagues.
- Ability to work quickly and with unknowns.
Designing for the user
Your job as a content designer is to make sure that information is clear and easy to understand. It’s also about giving people the information they need, at the point they need it, in the right format. That’s why, you will need to consider your users and their needs whenever you’re designing content.
An example of user-centred content design
Below, you will find an example of a user journey and the kind of questions a content designer working on it will need to consider.
Designing multiple steps in a journey
Often, a user journey involves more than one step. For example, claiming a State Pension is more than just making the claim. It’s also finding out if and when you’re eligible, and being told how much you’ll get and when.
So, the team working on this service will need to look at the whole end-to-end journey for their users, rather than just a single page.
More than an online service
Content work does not only focus on the online service, though. Like in the example above, claiming a State Pension is something that involves offline steps as well.
It involves getting 2 letters, which are a big part of the user journey. Making sure that these letters are clear and easy to understand is just as important as the content in the online service.
User research to support content design
User research found that people expect a letter when they can get their State Pension. This letter is the main way that people find and enter the GOV.UK service Get your State Pension.
So, it’s important that this initial letter creates trust and explains what to do.
The old letter that used to be sent users included a 12-page booklet. User research found that this wasn’t easy to navigate.
The letter has since been redesigned and the content reduced to 2 pages. It now also includes clear headings, which means people can find the information relevant to them easily.
Designing for the whole journey
The experience of getting a State Pension does not begin and end with the online service. We should design for the whole journey – both online and offline. If we meet the needs of our users at all stages, then they will receive a good and consistent service that they trust.
A user need is…
A user need is something that a person has to get done. The person might be a citizen, they might be at work, or be working in government. Their need is there regardless of what existing system they might have to use. That’s just the current tool and it might not be helping.
They might not even really want to do the thing they need to get done. Like paying a bill, getting a licence, or finding out government is stopping them from doing something. But because of their situation, and possibly a deliberate policy (not just the existing system) that’s in place, they need to do it.
A user need is not…
User needs are not:
- giving users what they ask for (like easier ways to fill in the current form)
- what ‘we’ – people who work on a piece of information or a service – want to get them to do (like read and understand a piece of guidance)
- in conflict with stopping people doing bad or prohibited things – hopefully those aren’t things that they need to do
- optional extras, bells, whistles or gold-plating – quite the opposite
They are essential activities and information.
Doing the hard work to make things simple
Designing for user needs is boiling down services to the minimum necessary to give people what they need to get something done. No more.
But the minimum may differ from what the current service or system makes them do. It’s probably less. It may involve doing the hard work to make things simple. It should make a service quicker, simpler and cheaper (to use and probably to build too).
Another way to put it is that user needs are about getting done only what’s needed.
The goal of meeting user needs can sometimes get sidelined when the pressure is on to get something (even anything) working and out of the door and ‘delivering value to the business’. But we can avoid building another costly, wasteful, difficult-to-use service if we keep calling out anything that isn’t focused on getting done only what users need.
User needs aren’t optional extras. When we get them right, they’re the irreducible core of what any service is there for.
How to write a user need
To design content that helps the user get things done, it’s useful to write down the specific user needs you’re working with.
User needs typically follow the structure:
As a… job seeker looking for a job as a content designer,
I need to… improve my knowledge and skills,
so that I… can get a job as a content designer.
Asking the right questions
If you want to build content your users need, first you need to understand your users. Asking the right kind of questions will help you do that.
You’ll need to find out:
- who your likely users are
- what they’re trying to do
- how they’re trying to do it now
- how their life or work influences what they do and how
- how they use and experience existing services
What makes good Content Design?
Here are some of the most important elements of designing good content:
Meet the user need
Do not publish everything you can online. Only publish what someone needs to know to complete their task. Nothing more.
When you write for the web, start with the same question every time: what does the user need to know?
Meeting that need means being:
- specific
- informative
- clear and to the point
Help the user find what they need
An individual’s process of finding and absorbing information on the web should follow these steps:
- I have a question.
- I can find the page with the answer easily – I can see it’s the right page from the search results listing.
- I have understood the information.
- I have my answer.
- I trust the information.
- I know what to do next/my fears are allayed/I do not need anything else.
A website only works if people can find what they need quickly, complete their task and leave without having to think about it too much.
Create content that is easy to read
Good online content is easy to read and understand.
It uses:
- short sentences
- subheadings and sections
- simple vocabulary
This helps people find what they need quickly and absorb it effortlessly.
The main purpose of GOV.UK is to provide information – there’s no excuse for putting unnecessarily complicated writing in the way of people’s understanding.
Why prototype?
Making prototypes is a great way to explore, share and test different designs before you commit to building anything.
Making prototypes is important because it:
- improves the usability of your service
- helps you to make sure you’re building the right service for your users
- helps your whole team to get a shared understanding about the future of your service
- allows your team to explore design ideas much faster and at lower risk than using your production code
Why Plain English works – some evidence
The main purpose of GOV.UK is to provide information – there’s no excuse for putting unnecessarily complicated writing in the way of people’s understanding. Writing clear English helps people find what they need quickly and absorb it effortlessly.
But how do you persuade a whole team or organisation that plain English is the right approach? That you’re not dumbing down? Read the arguments below and decide which ones would be useful for your context.
Myth | Fact |
We shouldn’t be dumbing down. People want to read proper English! | Those with low literacy levels prefer plain English, and so do those with high levels of education. |
Nearly everyone understands it as it is, it’s only a small number who cannot. | 7.1 million people in England have very poor literacy skills. |
There’s no reason to change it. It’s always been like this. | Using clear English can save time, money and resource. |
The Content Lifecycle
Why the content lifecycle is important
Following a consistent content lifecycle helps your organisation create content that:
- is user-focused
- is factually accurate
- is maintained and iterated
- meets the Service Standard
Your content lifecycle will depend on the project and organisation, but most content lifecycles should include the following stages:
1. Content discovery and research
Content discovery is when you work with other people (for example, subject matter experts, designers and user researchers) to understand:
- who your users are
- what your users need
Content discovery helps you make sure you understand the information your users need or the problem you’re trying to solve, before you begin designing and prototyping your solution.
A typical content discovery might include:
- a discovery workshop – this is where you work with your stakeholders to find out their priorities and challenges, understand what the current journey looks like, and share data and evidence
- gathering and auditing as much evidence as you can to understand what users need from your content – for example, keyword research to find out what people are searching for online
- testing existing content to find out what the current user experience is and what you can improve on
Once you have gathered and analysed all your evidence, you can write user needs and user stories. These will make sure any content items you produce are user-centred.
User needs and user stories will help you put together a content plan to share with stakeholders and validate with your users.
2. Design and writing
Once you have completed all your preparatory work, you can start to design the content. This is when you turn your user stories into content items.
Designing a content item should involve:
- choosing a content format that best answers the user need – for example, plain text, or a tool like a postcode search or calculator
- writing content that follows your organisation’s style guide and best practice for writing for the web
- making sure your content is easy to find – for example, building good information architecture, using headings and including metadata
- working with designers to make sure your content is accessible and easy to use
3. Peer review
Once you draft your content, ask a second person (preferably another content designer in your team) to review it against your organisation’s style guide and check for errors.
This is known as a ‘peer review’.
Sometimes you may need your content peer reviewed more than once. For example, you may want to get another peer review if you make a large number of edits in the fact check stage and want to check the content still meets your team’s standards.
A peer review checklist (based on your organisation’s style guide) can help your team do peer reviews consistently.
You could organise a content crit with your peers if you need extra support – for example, if a user need is complex or you have trouble explaining terminology. You will learn more about content crits later this week.
4. Fact check
As well as checking the content meets your style guide, you’ll need to make sure it is factually correct.
You can do this by asking a subject matter expert to fact check your content. This could be an expert in a particular area, like law or policy.
While a subject matter expert is responsible for the facts, it’s still the content designer’s job to decide how the content is written. The subject matter expert should only comment on factual inaccuracies, not on style, tone or structure.
A useful method for ensuring content is factually accurate and easy to understand is to pair write – creating or editing content side-by-side with your subject matter expert. You will learn more about pair writing later this week.
5. Publish, maintain and iterate
Before you publish any content, you should agree with your stakeholders:
- how and when the content should be updated and maintained, and who is responsible for this
- how you know the content is successful – for example, if there is a 20% decrease in phone calls about a specific query
- when you’re going to review it – this could involve looking at analytics and on-page feedback to see how the content is performing, or conducting user testing
- when you are going to remove/archive (delete) it
You should give any content that’s ready to be published one last check to make sure links are working and metadata is correctly tagged.
If appropriate, you should also think about how content is going to be promoted to users and what other relevant websites or offline material should link to it.
6. Remove and archive
You should remove (also known as ‘unpublish’) content when it comes to the end of its life. For example, if it’s out of date or is stopping users finding what they need.
Before you remove any content, get approval from content owners or any other stakeholders first. This might mean presenting evidence and data to show why the content needs to be removed.
Plan how you’re going to remove the content. For example, how you’ll manage redirects, and if you need to communicate the removal to stakeholders and users.
Often content is simply replaced or joined on to other existing content on the site – to do this, you should unpublish a page and add an alias to redirect traffic from the old page to the new one.
Where content is going to be deleted entirely, it is often best to send all traffic for that old page to a web archive. Make sure you follow your organisation’s archiving policy.
It’s important to let users know how they can access content that’s been archived. This could be a dedicated page on your site explaining your archiving policy and linking to archives of your site. Or it could be a link from the content on a page pointing to previous versions of this content in a web archive.
What’s the aim of your content?
Not all content has the same purpose, which means different pieces of content will be aiming for different results.
Look at the bank holidays page below and decide which question(s) are useful for this page:
- Are users engaged and interested in this content?
- Are users completing a service from beginning to end?
- Do users find the website useful?
- Are users able to find the answer to their question quickly and easily?
- Are they staying on the site, looking at multiple pages?