Content principles

Our content principles

We meet user need.
We use data and evidence.
We write in plain English.
We write so it’s easy to understand us.
We follow the style manual.
We check everything before we publish it.
We iterate to improve.

How people do things online

Someone needs something
They ask a question on the internet (search)
They choose the best option from the available results
They scan down a page to see if they’re in the right place
They try to read and understand the information
They establish whether or not they can trust what they read
Their need is met: they know what they need to do next

Everything we do should aim to help people through those steps. The web is information overload. People need help to focus.

Advising on health: our special responsibility

We provide advice to everyone in Ireland on conditions that affect their health.

We understand that people often come to us when they are ill, worried, distressed or frightened.

They might be a commuter on a phone on a packed train or a mother comforting a sick child in the middle of the night.

Research shows that stress affects comprehension: people find it hard to understand information when they are in distress. That’s because stress adds to our cognitive load.

So, we must work even harder to ensure that our content is clear, simple, accurate, trustworthy and works for all people in all circumstances.

User need

Most people visit HSE.ie because they need something. (See step 1 of ‘How people do things online’)

Everything published on HSE.ie 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
data from health professionals and organisations

Note, we’re talking about user needs – not organisational need.

User stories

User stories express user needs. To create content for HSE.ie, 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…person living in Ireland
I want to…get a medical card
So I can…get the medical services I am entitled to

As a…person who has had a minor accident
I want to…find out which medical service to use
So I can…get the correct treatment

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 an…employee of HSE
I want to…find out how much pay I’ll get on maternity leave
So I can…plan my finances after I have a baby

Acceptance criteria might include:

knows if she is eligible for maternity leave
knows if she is eligible for maternity pay
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
registers to use the maternity pay calculator

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, the woman planning a baby needs to know how to register to use a maternity pay calculator – that’s a different user need.

Tips for writing user stories

Don’t suggest solutions, justify existing services or content.

Here’s an example of a user story that justifies existing content:

As a…parent of a young baby
I want to…read the HSE content about caring for new babies
So I can…learn how to look after my baby well

Define the user

Sometimes the audience is specific (a parent of a newborn, a graduate nurse, a family GP.) Sometimes it’s broad (someone entitled to a medical card.) 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:

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…pregnant woman
I need to…know what extra vitamins I need to stay healthy
So I can…buy the correct vitamins

Bad example

As a…pregnant woman
I need to…know what extra vitamins I need to stay healthy
So I can…stay healthy in pregnancy

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

Data in 10 minutes

Google Trends (good for finding the most popular way of phrasing something)
SEMrush (good for finding out what people care about in a particular subject area)
Google Adwords (good for finding out what related things people care about)

How we structure content

Consider user journeys
Put the most important information first
Make it easy to scan
Use content patterns

1. 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 ‘symptoms of chickenpox’, add a subheading that says ‘Chickenpox symptoms’.
If you can see that lots of users go from your page to page x, offer a clear link to page x.

2. 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: Canteen menu
Bad: What’s on the menu at the canteen today?

3. 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

We take extra care with these.

See rules for structure.

4. 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 use plain English
We use the same words as our users
We check our content is easy to read and understand
We don’t use jargon
We do use technical terms (but we explain them)
We use plain English for technical medical and legal content

See rules for language.

1. We write so everyone can understand us

“1 in 6 adults has literacy difficulties in Ireland. The OECD Adult Skills Survey shows that 17.9% or about 1 in 6, Irish adults are at or below level 1 on a 5-level literacy scale...At this level a person may be unable to understand basic written information.”
“42% of Irish adults score at or below Level 1 on a similar 5-level scale that tests for problem-solving in technology-rich environments…The highest problem-solving mean score in Ireland is achieved by those in the 20 – 24 age group, while the lowest is achieved by those aged 60 – 65.”

Source: National Adult Literacy Agency (NALA)

We have an obligation to make our content accessible to everyone who needs it.

2. 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 on the Government Digital Service blog.

3. Use the words your users use

We always use the same language as our users when we write for HSE.ie.

Otherwise, people can’t find our content when they search for it. 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.

4. 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:

As a rule of thumb, aim for a reading age of about 9. For technical medical and professional content, aim for 12.

5. 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

6. 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.

Read the section on technical medical and legal content.

Examples

the incubation period (the time it takes symptoms to develop after being infected)
fontanelle (soft spot on top of a baby’s head)

7. 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).

This is supported by some 2012 research by Ipsos MORI for the Department of Health in the UK.

One theory is that more highly educated people with more specialist knowledge have more to read and less time to do so.

Read the section on technical medical and legal content.

Before we publish

1. Checks for style
2. Checks for factual accuracy

1. Checks for style

We must check every piece of content we publish on HSE.ie.

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 HSE.ie
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

2. 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 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
the evidence on language is still correct (or are people calling this something else now?)