We use cookies on this website. By using this site, you agree that we may store and access cookies on your device.

Content principles

Our content principles

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

 How people do things online

  1. Someone needs something
  2. They ask a question on the internet (search)
  3. They choose the best option from the available results
  4. They scan down a page to see if they’re in the right place
  5. They try to read and understand the information
  6. They establish whether or not they can trust what they read
  7. 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?]


  • As a…person living in Ireland
  • I want to…get a medical card
  • So I can…get the free 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:

Indirect research

Tools include:

  • surveys
  • online user research software
  • A/B testing


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

  1. Consider user journeys
  2. Put the most important information first
  3. Make it easy to scan
  4. 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?


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.


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

  1. We write so everyone can understand us
  2. We use plain English
  3. We use the same words as our users
  4. We check our content is easy to read and understand
  5. We don’t use jargon
  6. We do use technical terms (but we explain them)
  7. 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. 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. (Read why we aim for 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.


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

Be bold!

One reason people write legalese, or make medical 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

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.


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


  • 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


  • 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?)