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.
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.
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.
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:
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.
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:
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.
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.
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.
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:
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.
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:
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).
Padma Gillen is the author of ‘Lead with Content’, and CEO of Llibertat, a content-led digital agency that puts users first. He uses his expertise in content strategy and agile to help organisations get clear on what they’re trying to achieve, build a roadmap to get there and then deliver the change their users are looking for.
Previously, Padma was Head of Content Design at the Government Digital Service (GDS). He had overall responsibility for the quality of content on GOV.UK, the award-winning website of the UK Government.