Editor’s note: We are excited to share this excerpt from GatherContent’s book Lead with Content.
Organizations generally survive in the early days of their existence for one of two reasons:
- They genuinely meet one or more needs of a certain kind of user.
- The funding hasn’t run out yet.
Let’s talk about a fictional organization. Let’s call it Padma’s Outstanding Widgets (POW) and assume it’s still around because of point one.
POW is a success at doing what it does, more people want to buy from it, so it grows.
What happens next?
At a certain point, it has enough market share and gets to a large enough size that it starts to have its own momentum. There are now departments, processes, a language and culture, career paths through the organization, reports, reviews, several layers of management, etc. It has its own thing going on that, while related to user needs, is also self-perpetuating.
At this point in its life cycle, lots of people in POW are no longer ‘front line’. Their job doesn’t directly relate to or involve end users. It doesn’t even directly involve widgets. Some of them even feel like end users and widgets just get in the way.
These people joined the organization when it was no longer a startup. They don’t enjoy startup culture. They want to get hired by a proper organization, through a formal process. They’re more comfortable with a clear job description and systems that are already firmly in place. They don’t like risk. They want to know that if they join this organization, they’ll be able to have a career within it if they choose to. They can see themselves still working for POW in 10 years time. Perhaps in that corner office with the nice views.
Since POW is now made up mostly of people like that, at an organizational level POW is averse to change. It will take a year of discussions and a shed-load of reports before you can get a new coffee machine in the canteen. Even though everyone knows the current machine makes rubbish coffee and it takes so long that there’s always a queue.
Somewhere in the evolution of the organization, user needs end up buried under a whole bunch of processes, meetings, and reports. The ‘system’ now works against the very user the organization relies on for its existence.
POW’s Publishing Model
POW finds itself in a situation that is all too common:
- POW has a website. It’s not very good.
- There are all kinds of reasons why things end up on the website, and ‘because users are looking for it’ is rarely one of them.
- POW has a devolved publishing model because it seemed like a good idea to make the people who know about a thing responsible for writing about it on the website. Doing it that way also seemed to save money, since POW no longer needed much of a web team.
- Different parts of the organization publish things on the website that they think should be there. Or that they want to be there.
- There’s a small central web team. It tries its best to keep the quality of the content on the website high, but it’s a losing battle. They don’t have the power or the resources.
- Other people in POW see the web team’s job as being about serving them.
I’ve seen everything from ‘Company memos, 1970 to 2001’ to ‘Pictures of my favorite tea towels’ on the public-facing website of large organizations like this. And I say ‘website,’ but actually, POW currently has several hundred microsites as well as the main site. Someone in the organization has an idea, and a new microsite is born to promote it.
POW faces other challenges too:
- No one really knows what its web estate really looks like to users.
- No one knows everything that’s on it, how big it is, or even who’s in charge. In reality, no one is in charge. Just like POW itself, the website has its own momentum.
- The content is all over the place and impossible to manage.
- The website is growing at a rate of several thousand pages per year.
- After a few years, it becomes clear that the only way to fix it is to start again.
- To the senior management, the website still feels like new. But it’s almost 20 years old and they’ve redone it several times already. The web team knows they need to start again, but they don’t want to just replicate what happened last time and the time before that. That road leads to where they are right now.
No. This time, in an effort to really get on top of things, they want to do things differently.
Write a Business Case
If you want a different result, you need a different approach. But if you work somewhere like POW, you can’t make it too different or it will never get off the ground.
The reality is you need to engage with the decision makers using a language that makes sense to them, while at the same time fundamentally shifting the direction of travel. You’ll need hard evidence that the current approach isn’t working before they’ll even see there’s a problem. After all, the current website looks OK to them.
Formula for change
David Gleicher developed a ‘formula for change’ in the 1960s. This was refined by Kathie Dannemiller in the 1980s. Dannemiller’s version goes like this:
C = D x V x F > R
Pretty impressive huh? Maths in an article about content! But what does it mean???
Here’s the long version:
For change to happen, dissatisfaction with the current state (D) x vision for the future (V) x first concrete steps to get there (F) must be greater than the amount of resistance to that change (R).
What’s interesting about this is that if any of the factors D, V or F are zero or very low, the change won’t happen. I know I could’ve just said that straight off without the formula, but I was trying to impress you.
What the formula for change means is you need to write a business case that convinces the decision makers in your organization to the extent that they have a strong experience of D and V and they are confident that you know how to do F if they say yes.
You also need to keep the cost and pain down as much as possible so that R is kept as low as possible.
In short, you need to write a business case that explains what you want to do, why you want to do it, and what it will cost.
So what kind of evidence should you gather? And how should you gather it?
A good place to start is a content audit.
Step 1: Do a content audit
There are lots of ways to do a content audit but generally, it starts with a spreadsheet.
- In column one of each line of the spreadsheet, add the website address of a page on your website. You can scrape these automatically. Search for “web scraper” and see what comes up. Scrape the page title too for ease of identification and include that in column two.
- Gather information on how each page is performing. If you have an analytics product you can log the number of unique visits, how long people spend on the page, whether they bounce from that page or stay on the site, and things like that.
- Add columns in the spreadsheet to note how many words are on the page, and what the reading age of the page is (search for “reading age checker”).
- If you capture user feedback, log what kind of feedback you’ve received about the page in another column.
- Have a look at the page and give an opinion on the overall quality in another column. I’d suggest you only do this on the popular pages otherwise it will take forever.
- Most importantly, use the insights from your content audit to get a sense of what user need your page is trying to meet and add the user need(s) in another column on the spreadsheet. That way when you’re doing the new site, you can use the content audit as a starting point. If a page has high traffic, there’s probably a genuine user need there.
You can waste a LOT of time and resources on a content audit. Your site is way too big to do a thorough job, and you already know the popular parts of it. My guess is you also know which parts are a waste of time, and which parts are terrible and need to go.
The main aim of an audit isn’t to show you what you should keep and migrate over to the new site. It’s to give you the data to tell the story of the current situation, so you can show the decision makers a level of due diligence and build a case for change.
You don’t need to spend months on it. Just pull together some useful data that proves what you already know: the website needs an overhaul. It’s far too big, it’s poor quality, and loads of it gets little or no traffic.
Step 2: Estimate what you’re currently spending on the website(s)
The bottom line is this: the decision makers in your organization don’t care as much about users as they do about money. So if you want to build a case for change, you need to show how you’re currently spending a ridiculous amount per year on keeping a very poor website hobbling along. If you move to a user-needs-based strategy it will only cost half of that to do the project and then half again to maintain the site each year. So within two years the project will have more than paid for itself.
I don’t know the exact figures for your website, but I’ll guarantee I’m not too far off.
What you’re saying here is, doing it better costs less than nothing. Who wouldn’t say yes to that?
In a distributed model, where lots of people are spending 5% of their time creating poor web content, you need to find a way to put a monetary value on that. If the average salary in your organization is $50,000 and you have 2,000 publishers, your organization is spending a staggering $5 million every year on extremely shoddy web content. And that’s not including hosting that terrible content and all the money spent on getting your developers to write code to keep the site chugging along despite the extremely poor structure and lack of metadata.
Instead, spend a fraction of that money hiring a proper content design team, and let the people who are amateurs at web content focus on being professionals in whatever their actual role is.
Step 3: Compile a list of user needs
This is where the fun begins (unless you’re into spreadsheets, meetings, and algebra in which case you’re already having a blast).
You need to log all the things your users want to get from your website. How do you do this?
Look at your content audit
You’ll be able to see some of it by looking at your content audit. If you look at your website traffic and convert it into a graph, the graph will almost definitely look like this:
The vertical axis is page views, the horizontal axis is made up of every page on your site. What this means is the vast majority of your users (probably around 80%) are looking at very few of your pages. There is a genuine user need for what’s on (or at least what users *think* will be on) the pages with the highest traffic.
The rest of the pages might serve some niche user need, and therefore might need to stay. But then again they might serve no real user need at all and the only people who visit them are the people who wrote them. So those pages need to prove their worth, and if they can’t, that kind of content doesn’t make it onto the new site.
Talk to your stakeholders
Stakeholders across your organization will also be able to give you insight into the needs of users because:
- They spend all day thinking about some aspect of what your organization does.
- They may well have been at this game for a long time and can explain some of the nuances in their subject area.
- They may well have regular contact with users – and they may even be a user themselves (eg if you run a model train store there’s a high chance the person behind the counter collects model trains and can tell you quite a bit about why people go to the store’s website)
Do some user research
Stakeholders are only part of the story, and if you only listen to them you’ll inevitably get a pretty skewed idea of what your user needs really are.
The main thing you need to do is design and implement a user research project.
User research is its own field and I would strongly recommend engaging at least one user researcher to work with you. If you don’t know what you’re doing and try to do the research yourself, there’s a good chance your own biases will creep into the findings and the data you gather won’t be very useful.
Having said that, if you don’t have the budget for a user researcher, do your own. Even 10 minutes of talking to a user that you politely interrupt while they’re in the middle of using your service will give you a sense of what your site means to them. So, one way or another, do some user research!
Look at what you’ve gathered
If you do all this, you’ll have:
- Quantitative (big picture) data
- Qualitative (deep dive) data
- Insights from subject matter expert
Pretty cool, eh!
Together these should give you a good sense of what your users are looking for. But how do you turn that into content that actually meets those needs?
User stories
You want to capture each user need as a user story. A user story looks like this:
As a …
I want to …
So I can …
For example:
As a farmer
I want to know how UK withdrawal from the European Union will affect my subsidies
So I can plan for the future
A user story should be in plain English. It needs a user (As a…), a task (I want to…), and a motivation (So I can…).
User stories can be related to each other, so you can start to work out user journeys (eg a user journey might start with ‘find out about the service’, then ‘find out how to subscribe’, then ‘subscribe’, then ‘get help amending my subscription’ or ‘tell you about a change of address’ or ‘cancel my subscription’).
They can be sub-needs of other user needs, so you can start to see how they might fit in the same piece of content (e.g. ‘find out how much I’ll get’ and ‘find out if I’m eligible to apply’ might sit in the same piece of content).
And they might be particular types of need, so you can start to see what different formats you’ll need to design (eg blog post, news item, how to guide, publication overview, departmental page).
From the publisher:
Lead with Content is about the vital role of content strategy in digital transformation and vice versa. This book is an antidote to ‘content last’ experiences and ways of working.
From user needs, getting the right people in place, workflow, and governance, this book will help you get ready to transform your content operations.