Our content principles
- We meet user needs
- We don’t duplicate content
- We don’t publish anything that’s already being done better elsewhere
- We write in plain English, in the active voice, and follow the Barnardo's brand, tone and style guidelines
- We check everything before we publish it
- We update or retire content that’s out of date
- We use data and evidence to support content decisions
User needs
Most people visit Barnardos.org.uk because they need something.
Everything published on Barnardos.org.uk should meet a user need.
Before we can meet their need, we must understand it.
- Who is the audience?
- What do they want to do?
- Why do they want to do it?
How to identify user needs
You can find out what users need from your website through:
- user research interviews
- analytics which show what people are searching for and whether the content they find is useful or not
- on-site feedback
- data from call centres
Note: we’re talking about user needs, not organisational needs
User stories
User stories express user wants or needs. To create content for Barnardo’s, always start with the user story.
Use this format:
- As a...[who is the user?]
- I want to...[what does the user want to do?]
- So I can...[why does the user want to do this?]
Examples:
- As a...member of the public
- I want to...find my local Barnardo’s shop
- So I can...donate unwanted goods to a great cause
- As a...young carer
- I want to...find out whether Barnardo’s runs respite care social events in my area
- So I can...get out of the house a bit and have some fun
Acceptance criteria: ‘done when’
Develop the user need further by listing all the things that the user would need to know or do to achieve their aim. These are sometimes called ‘acceptance criteria’.
The list of acceptance criteria shows you what content you need to develop to meet the user need.
For example, look at this user story:
- As somebody who is thinking of fostering
- I want to...find out how much financial support I can get for fostering
- So I can...work out whether fostering makes financial sense for me
Acceptance criteria might include:
- knows if she is eligible for financial support for fostering
- understands how much she will be paid
- knows when she will be paid
- knows if there are any terms or conditions that will affect her The list doesn’t have to be in any specific order and you can keep adding to it. If the list gets long and unwieldy, check there isn’t a new user need lurking in it. In this example, there are other eligibility issues surrounding such as pre- approval and checks – that’s one or several different user needs.
Tips for writing user stories
Don’t suggest solutions or justify existing services or content.
Here’s an example of a user story that justifies existing content:
- As an...online shopper
- I want to...browse the Barnardo’s online shop
- So I can...buy sweets and Teletubbies bracelets for my children.
Define the user
Sometimes the audience is specific (a young carer, a commissioner in a local authority, a foster parent). Sometimes it’s broad (a donor). Some user needs will have lots of potential audiences – you don’t have to write a different user story for each, but you should define the audience as well as you can.
Make it task-based and active
The ‘I need to...X’ should be something that helps the user fulfil a task.
Active needs include:
- donate
- apply for
- claim
- find
If the need is to ‘know’ or ‘understand’ or ‘find out about’ something, make sure that the ‘so I can...’ is to fulfil a task.
Good example
- As a... member of the public with some time to spare each week
- I need to...find out about volunteering in a shop
- So I can...apply online for a volunteering opportunity
Bad example
- As a... member of the public with some time to spare each week
- I need to...find out about volunteering in a shop
- So I can...know how to volunteer in a shop
Do the research: data and evidence
We do research to define and check user needs, and to find out people’s ‘mental model’ for that need – how they think about it and the language they use to describe it.
What kind of research we do, and how much of it, depends on the scale of the content project.
Direct user research and testing
Tools include:
- qualitative research with users (like interviews or usability lab studies)
- pop-up research (also known as guerrilla research)
Indirect research
Tools include:
- surveys
- online user research software
- A/B testing
Analytics
Sometimes, we have set analytics to help us answer specific questions. But we can always find out:
- search terms – in search engines and in site search and on-page
- where people were and where they went next
- traffic to relevant pages
- how long people spend on pages
- what they do on pages – download a PDF, search, complete a task
Other sources of information
- Onsite feedback
- Competitors
- Online forums on the topics
- Call-centre data
- Frontline service data
- Customer complaints and queries
- Anything ingenious we can think of: it’s all gold
How we structure content
- Consider user journeys
- Put the most important information first
- Make it easy to scan
- Use content patterns
Consider user journeys
Consider the user in the structure of the page: how do people move through your content? Where do they need to go next?
Examples
If the data tells you that lots of people search for ‘barnardos jobs’, add a subheading that says ‘Jobs at Barnardo’s’.
If you can see that lots of users go from your page to page x, offer a clear link to page x.
Put the most important information first
Use the ‘inverted pyramid’ model. Start with the content that is most important to your audience, and then provide additional details. ‘Front-load’ copy (especially headings, links, bullets and captions) – put the most important information first.
Examples
Good: Special educational needs: independent supporters
Bad: Independent Support Services - Special Educational Needs (SEN)
Make it easy to scan
People don’t read content online – they scan it. That means they don’t read top to bottom, or even from word to word. They will scan in an F-shape, looking for something relevant to grab their attention. So, we structure content to help people scan.
Think about the structure of content from the point of view of someone who’s scanning it quickly. They are checking to see if this is the right page for them. What are the signposts they are likely to see?
The most attention-grabbing structural elements are:
- headings and sub-heads
- bulleted lists
- images and captions
- links
Use content design patterns
We use consistent patterns for some elements on our site – the same words and structure. That means that they always look the same, wherever people come across them on our site.
The language we use
We write so everyone can understand us
We have an obligation to make our content accessible to everyone who needs it.
Plain English
Everything we publish must be written in plain English. Plain English is a style of writing and presenting information that helps the reader to understand it the first time they read it.
To do this, we:
- choose short, simple words
- write short, clear sentences – 20 words maximum
- use the active voice (say ‘We’ll send you a letter’, not ‘A letter will be sent to you’)
- explain technical terms
- don’t use jargon
Research shows that everyone prefers plain English, no matter their level of education or reading ability.
Read this post and linked research about plain English on the Government Digital Service blog.
Use the words your users use
We always use the same language as our users when we write for Barnardo’s.
Otherwise, people can’t find our content when they search for. And if they do find it, they might not understand it or trust it.
We do the research to find the right words before we start writing.
Check content is easy to use and understand
We use ‘readability’ tests as one measure of how easy it is to understand our content.
‘Readability’ tests check written content to predict what level of ‘reading age’ (level of educational reading ability) someone will need to understand our content.
We do this in:
- the Hemingway app
- Microsoft Word
- Readable
As a rule of thumb, aim for a reading age of about 9. (Read why we aim for 9.) For technical, medical and professional content, aim for 12.
Jargon
People don’t understand jargon. It’s often vague and risks misinterpretation. People don’t trust it.
It’s easy for jargon to sneak into copy, particularly if you know your subject well.
Look out for:
- words, acronyms and abbreviations the organisation uses internally
- nominalisation (turning verbs into nouns - use the verb instead, for example, ‘We will take into consideration’ versus ‘We will consider’)
- business speak
- legalese
- medicalese
- marketing speak
- specialist terms that aren’t technical terms
Technical terms
Technical terms are not jargon. It’s fine to use them where necessary – just explain what they mean the first time you use them.
Writing for specialists
Plain English is for everyone.
A common argument is that if you’re writing for a specialist audience, you don’t need to use plain English. But plain English is better for everyone.
Writing in plain English and legal or medical writing have the same goal. This is to communicate complex ideas in a way that is easy to understand and act on.
A case study to quote
Research shows 80% of lawyers prefer plain English. For example, 97% preferred ‘among other things’ over the more traditional Latin phrase ‘inter alia’.
The more complex the issue, the greater that preference. More highly educated lawyers have a stronger preference for plain English (and there is a correlation – the higher the education, the greater the preference).
Lawyers with more specialised knowledge have a stronger preference for clear English (and there is the same correlation).
One theory is that more highly educated people with more specialist knowledge have more to read and less time to do so.
Be bold!
One reason people write legalese, or make their writing complicated, is because ‘this is the way it’s always been done’. We feel pressure to conform to a style that it makes us sound authoritative, or ‘normal’, or right. We’re concerned we’re ‘dumbing down’, instead of opening what we write to a wider audience. It takes courage, as well as practice, to bring clarity to what we write.
Before we publish
Checks for style
We must check every piece of content we publish on Barnardos.org.uk.
Basics:
- spellcheck
- check links are working
- scan the content – can you tell what it’s about with a quick scan?
- check the readability score
- check it has a review date
Check that the content:
- should be on Barnardos.org.uk
- doesn’t duplicate existing content
- has a clear user need
- is in the right format
Titles should be:
- concise (65 characters maximum)
- clear, specific and positive
- active, start with a verb if possible
- unique to the site
- optimised for search (use keywords)
- in sentence case
- in plain English – no jargon
Body text should:
- have the most important information first
- be concise and easy to scan (with sub-heads every 3-5 paragraphs)
- be written in plain English (no jargon) and easy to understand
- use short sentences (maximum 20 words)
- define acronyms and abbreviations the first time they’re used
- explain any technical terms
- meet voice and tone guidelines
Checks for factual accuracy
Subject matter experts check for factual accuracy. They don’t need to waste their time and expertise correcting basic errors or rewriting for style – our other checks will catch those.
Do:
- Check facts and figures
- Check links and citations: is external content accurate, reliable, trustworthy?
- Suggest technical language or commonly used expressions if you think that they’re missing
- Send agreed changes, not questions or unresolved comments
- Provide reasons for changes, so writers can understand
- Respond by the deadline
Don’t:
- Check for basic mistakes like punctuation errors – we have other checks for that
- Correct style – capitals, acronyms, bullets
- Revert to text you provided – it’s been changed for a reason
After we publish
We check and iterate content.
All content we publish has a review date. At that date, we check it to see if:
- people are using it, and using it right
- it still meets a user need
- it’s correctly positioned for user journey (we may have published something else that will alter this)
- it’s factually accurate
- any external links need to be updated