The term ‘user needs’ has become a key concept for anyone interested in digital transformation over the last few years.
It’s the first of the Government Digital Service’s (GDS’s) design principles for one thing:
Start with needs. User needs, not government needs.
The theory is simple. Perhaps unsurprisingly, it’s based on the fact that our users need things. If they think they can get it from some content on our website, or from our digital product, they’ll come. If they don’t, they won’t.
The practice of designing content around user needs is not so simple, however. It strikes right at the heart of how an organisation communicates with its customers. In fact, it often goes way further than content, to challenge the way many people in an organisation think about that organisation’s role in the world. Over time, this can lead to massive organisational and cultural change.
Not everyone in your organisation will be 100% keen on the kind of change a user-needs-based content strategy brings with it. Even if they sign up to the user-needs-based approach, sticking to it can be a challenge and there’s always the temptation to slip back into the traditional, unchallenging approach to web publishing. To prevent this, you need a way to make sure every content request is valid from a user-needs perspective before adding, removing or changing anything on your website.
Traditional web publishing
An enthusiastic, highly motivated person in your organisation contacts you with the following request:
We need a new page on Dolly Parton.
They’re an expert on country music and they know what people need to know on the subject. You aren’t and you don’t, so you write something about Dolly based on their brief.
As a conscientious content professional, you no doubt write it in plain English, with plenty of subheadings so it’s easy to scan. You try to make it as engaging as possible based on what you think people will find interesting about Dolly Parton. You maybe even conduct an interview with the expert, gather all the information you can, get some nice photos of Dolly through the decades, and so on.
You put the work in, do the best job you can and publish your piece. Your country music expert is happy and you have a nice, harmonious working environment. No one complains about you. Your boss gives you a pat on the back for being a good team player.
What if no one cares?
Despite all of the time, effort and money spent on this web page (that you now have to spend more time and money to maintain) no one visits. Why? Because there’s no user need for the content you’ve written, or if there is one, your users don’t think your content will meet it.
By the way, did I mention you work for a website specialising in heavy metal? And I don’t mean pickup trucks.
Needs-based content
A better way to do it is to have a rule that you won’t publish anything that doesn’t have a user need.
Since you’re not an expert on Dolly Parton and the requester is, you ask for the request to be written in the form of a user story that succinctly expresses the user need. You require content requests in the following format:
As a...I want to…So I can…
For example:
As a music fanI want to know about the life of Dolly PartonSo that I can impress my friends
As a content designer, you now have something to go on.So you write a piece for music fans about Dolly Parton. You publish it. But still no one comes!There are 4 reasons why this could be the case:
- There is a user need, but no one wants you to meet it (eg because your site is mostly about heavy metal, so Dolly Parton fans don’t trust you to tell the story of her life)
- There is a user need, but you didn’t meet it (eg 80% of heavy metal fans are in fact mad about Dolly Parton, but you wrote your page about notable country singers from Sevier County, Tennessee and no one was searching for that)
- There is a user need, but that need is being met elsewhere already (eg on a Dolly Parton fan site or Wikipedia)
- Even though it looks like a user need, no users actually need it (eg the proposed page is actually about Dolly Parton’s favourite pair of trousers from 1963 and no one actually cares)
The first of these is why you need a proposition document - a clear, written statement of the kind of thing that does and doesn’t go on your site. For an example, read the GOV.UK proposition (which I helped write). For the other possibilities, you need to do some detective work. That means data.
Using data to validate user needs
When you work in an organisation where the entire content strategy is based on user needs, people who want to get something on the website learn ‘the old user story trick’ pretty quickly.After all, it’s not hard to write a user story. “As a blah, I want to blah blah, so I can blah blah blah.” Easy.
But, just because something looks like a user need, it doesn’t mean any users actually need it. It doesn’t mean your site needs it. It doesn’t mean what you write will meet the need in a way users can relate to.This is why you need to ‘validate’ user needs before acting on requests to meet them.
You do this by looking at the data and doing a bit of research. Before agreeing to do anything, you should:
- Have a look at tools like Google Trends, Google Adwords and SEMRush to see what kind of demand there is and what kind of language your audience is using to articulate their need
- Have a look at relevant online forums to see what users’ interests are around this need (if any)
- Find out what people are asking your call centre or helpdesk about that relates to this need (if your organisation has call centres or customer support of any kind)
- Search on your own website to see if there’s anything there that meets the need (or could with a bit of a tweak)
- Search on Google or similar to see if other sites are already meeting the need, and if so are there any gaps so you can think about whether you should address them
- Find out if your organisation has done any user research in this area, and if not, consider whether that would be appropriate
- Look at your own website’s analytics to see if people are searching for this kind of content - and if they are, what pages they’re currently visiting and what happens next
You’ll soon see if there’s any interest and what that interest looks like. You’ll start to realise the boundaries of the user need and which other needs relate to it. You’ll work out what language your user uses (maybe ‘the best gosh darn country singer from Sevier County, Tennessee’ is actually the phrase Dolly Parton is best known by after all).
Though you may think of yourself as a writer not a data analyst, doing a bit of research into the user need is much quicker and infinitely more heartening than writing a bunch of words that no one cares about.
What’s more, if the data says no one is interested, you can go back to the person who requested the content and explain to them that the evidence suggests this shouldn’t go on the website right now. That doesn’t mean it won’t change down the line, and there’s nothing to stop you reviewing your heavy metal site’s feedback for Dolly Parton requests in 6 months’ time. But for now, you can confidently direct your effort to something your users do care about. Say, the latest Metallica dubstep remix (assuming dubstep remixes fall within your proposition).
The term ‘user needs’ has become a key concept for anyone interested in digital transformation over the last few years.
It’s the first of the Government Digital Service’s (GDS’s) design principles for one thing:
Start with needs. User needs, not government needs.
The theory is simple. Perhaps unsurprisingly, it’s based on the fact that our users need things. If they think they can get it from some content on our website, or from our digital product, they’ll come. If they don’t, they won’t.
The practice of designing content around user needs is not so simple, however. It strikes right at the heart of how an organisation communicates with its customers. In fact, it often goes way further than content, to challenge the way many people in an organisation think about that organisation’s role in the world. Over time, this can lead to massive organisational and cultural change.
Not everyone in your organisation will be 100% keen on the kind of change a user-needs-based content strategy brings with it. Even if they sign up to the user-needs-based approach, sticking to it can be a challenge and there’s always the temptation to slip back into the traditional, unchallenging approach to web publishing. To prevent this, you need a way to make sure every content request is valid from a user-needs perspective before adding, removing or changing anything on your website.
Traditional web publishing
An enthusiastic, highly motivated person in your organisation contacts you with the following request:
We need a new page on Dolly Parton.
They’re an expert on country music and they know what people need to know on the subject. You aren’t and you don’t, so you write something about Dolly based on their brief.
As a conscientious content professional, you no doubt write it in plain English, with plenty of subheadings so it’s easy to scan. You try to make it as engaging as possible based on what you think people will find interesting about Dolly Parton. You maybe even conduct an interview with the expert, gather all the information you can, get some nice photos of Dolly through the decades, and so on.
You put the work in, do the best job you can and publish your piece. Your country music expert is happy and you have a nice, harmonious working environment. No one complains about you. Your boss gives you a pat on the back for being a good team player.
What if no one cares?
Despite all of the time, effort and money spent on this web page (that you now have to spend more time and money to maintain) no one visits. Why? Because there’s no user need for the content you’ve written, or if there is one, your users don’t think your content will meet it.
By the way, did I mention you work for a website specialising in heavy metal? And I don’t mean pickup trucks.
Needs-based content
A better way to do it is to have a rule that you won’t publish anything that doesn’t have a user need.
Since you’re not an expert on Dolly Parton and the requester is, you ask for the request to be written in the form of a user story that succinctly expresses the user need. You require content requests in the following format:
As a...I want to…So I can…
For example:
As a music fanI want to know about the life of Dolly PartonSo that I can impress my friends
As a content designer, you now have something to go on.So you write a piece for music fans about Dolly Parton. You publish it. But still no one comes!There are 4 reasons why this could be the case:
- There is a user need, but no one wants you to meet it (eg because your site is mostly about heavy metal, so Dolly Parton fans don’t trust you to tell the story of her life)
- There is a user need, but you didn’t meet it (eg 80% of heavy metal fans are in fact mad about Dolly Parton, but you wrote your page about notable country singers from Sevier County, Tennessee and no one was searching for that)
- There is a user need, but that need is being met elsewhere already (eg on a Dolly Parton fan site or Wikipedia)
- Even though it looks like a user need, no users actually need it (eg the proposed page is actually about Dolly Parton’s favourite pair of trousers from 1963 and no one actually cares)
The first of these is why you need a proposition document - a clear, written statement of the kind of thing that does and doesn’t go on your site. For an example, read the GOV.UK proposition (which I helped write). For the other possibilities, you need to do some detective work. That means data.
Using data to validate user needs
When you work in an organisation where the entire content strategy is based on user needs, people who want to get something on the website learn ‘the old user story trick’ pretty quickly.After all, it’s not hard to write a user story. “As a blah, I want to blah blah, so I can blah blah blah.” Easy.
But, just because something looks like a user need, it doesn’t mean any users actually need it. It doesn’t mean your site needs it. It doesn’t mean what you write will meet the need in a way users can relate to.This is why you need to ‘validate’ user needs before acting on requests to meet them.
You do this by looking at the data and doing a bit of research. Before agreeing to do anything, you should:
- Have a look at tools like Google Trends, Google Adwords and SEMRush to see what kind of demand there is and what kind of language your audience is using to articulate their need
- Have a look at relevant online forums to see what users’ interests are around this need (if any)
- Find out what people are asking your call centre or helpdesk about that relates to this need (if your organisation has call centres or customer support of any kind)
- Search on your own website to see if there’s anything there that meets the need (or could with a bit of a tweak)
- Search on Google or similar to see if other sites are already meeting the need, and if so are there any gaps so you can think about whether you should address them
- Find out if your organisation has done any user research in this area, and if not, consider whether that would be appropriate
- Look at your own website’s analytics to see if people are searching for this kind of content - and if they are, what pages they’re currently visiting and what happens next
You’ll soon see if there’s any interest and what that interest looks like. You’ll start to realise the boundaries of the user need and which other needs relate to it. You’ll work out what language your user uses (maybe ‘the best gosh darn country singer from Sevier County, Tennessee’ is actually the phrase Dolly Parton is best known by after all).
Though you may think of yourself as a writer not a data analyst, doing a bit of research into the user need is much quicker and infinitely more heartening than writing a bunch of words that no one cares about.
What’s more, if the data says no one is interested, you can go back to the person who requested the content and explain to them that the evidence suggests this shouldn’t go on the website right now. That doesn’t mean it won’t change down the line, and there’s nothing to stop you reviewing your heavy metal site’s feedback for Dolly Parton requests in 6 months’ time. But for now, you can confidently direct your effort to something your users do care about. Say, the latest Metallica dubstep remix (assuming dubstep remixes fall within your proposition).
Share on Facebook
Share on Twitter
Share on LinkedIn
Share with email
