Organisations generally survive in the early days of their existence for one of one reasons:

1. They genuinely meet one or more needs of a certain kind of user.
2. The funding hasn’t run out yet.

Let’s talk about a fictional organisation. Let’s call it Padma’s Outstanding Widgets (POW) and assume it’s still around because of point 1.

POW is a success at doing what it does, more people want to buy from it, so it grows.

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 organisation, 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 organisation when it was no longer a startup. They don’t enjoy startup culture. They want to get hired by a proper organisation, 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 organisation, 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 organisational 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 organisation, user needs end up buried under a whole bunch of processes, meetings and reports. The ‘system’ now works against the very user the organisation relies on for its existence.

POW's PublishingModel

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 organisation 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 favourite tea towels’ on the public-facing website of large organisations like this. And I say ‘website’, but actually POW currently has several hundred microsites as well as the main site. Someone in the organisation has an idea, and a new microsite is born to promote it.

It's not enough to think through the "who, what, when, where, why, and how of publishing content - success requires having the people, processes, and power to carry out the strategy.

— Hilary Marsh

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 know 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 aBusiness 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.

Doing service delivery well requires an organisation to develop a good understanding of its users’ needs. It constantly amazes me how many organisations have failed to do that; how many of them have little or no contact with actual users.

— Mike Bracken

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 a content book! 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 organisation 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 willcost.

So what kind of evidence should you gather? And how should you gather it?

A good place to start is a content audit.

1. Do a content audit

   There are lots of ways to do a content audit but generally, it starts with a spreadsheet.

   1. In column 1 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 2.
   2. Gather information on how each page is performing. If you have an analytics product you can log 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.
   3. 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”).
   4. If you capture user feedback, log what kind of feedback you’ve received about the page in another column.
   5. 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.
   6. 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.
   Use the insights from your content audit to get a sense of what user need your page is trying to meet

   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 need to go, and which parts are terrible and need to be improved.

   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.

   Further Reading and Resources

   Why you should audit your content How to automate your content audits How to perform a content audit

2. Estimate what you’re currently spending on the website(s)

   The bottom line is this: the decision makers in your organisation 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 2 years the project will have more than paid for itself.

   The decision makers in your organisation don't care as much about users as they do about money

   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 organisation is £40,000 and you have 2000 publishers, your organisation is spending a staggering £2 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 side 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.

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.

   Focusing on addressing the needs of audiences first sets the foundation for meeting business goals and achieving greater success. Despite this, content creation is often driven by what internal stakeholders want, subjective requests, or guesses at what people need.

   — Jennifer Leigh Brown

   Talk to your stakeholders

   Stakeholders across your organisation 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 organisation 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

   You’re almost always wrong about your users.

   — Manik Rathee
   Former UX engineer for BarackObama.com

   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.

   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!

   A powerful way to think about content is as a series of answers to questions. Work with users (or their SME or stakeholder proxies) to find out what questions your users have, and in what order and priority, as they move through their journeys. Everything you make should answer the questions that get them where they want to go.

   — Noz Urbina

   Further Reading and Resources

   Optimal Workshop UserZoom GOV.UK user research blog

   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 experts

   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 (eg ‘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).

   Further Reading and Resources

   Getting to grips with user stories Turning user stories into content Content strategy for UX Designers

All beings have needs. My dog, for example, needs to run lots every day otherwise he becomes a complete nightmare to live with.

Should/could my dog’s need be met by your website? Probably not. For my dog’s needs to be met digitally, you’d need some kind of fast-paced robot with doggy treats taped to it.

What I’m trying to say is there are some legitimate user needs that you can’t meet. There are others that you could meet, but choose not to.

When you’re sketching out your new website or service, this is one of the first things you need to decide.

It’s called your proposition. It’s what lets you decide whether a user need, and the piece of content that meets it, is something you’ll work on.

This is important when you’re first designing your website or service, but it’s also important once it’s launched. You’ll get requests for additions to the site/service from elsewhere in your organisation. You need a way to decide whether you will say yes.

A proposition document allows you to do this.

One of the most common problems with publishing is that the organisation feels compelled to include content for completely internal reasons. If you can't trace a piece of content to an identified user and need they have, then kill it. See if anyone misses it.

— Noz Urbina

Write a propositiondocument

Why does your organisation exist? Does it have a mission statement? How is the website intended to help it with its mission?

When you know the goals of the organisation, and how it makes sense of itself, you can build that into a statement for the website. Here’s how the GOV.UK proposition begins:

GOV.UK is designed to meet the needs that UK citizens and residents have of government. It also caters for the needs of foreign nationals looking to visit, live or do business in the UK and anyone looking for information about the work of the UK government.

I helped with the first draft of the GOV.UK proposition document in 2012. It’s now 2019 and the proposition is apparently still in alpha! I think this demonstrates how difficult it can be to definitively and confidently state what a website is about and what should and shouldn’t be on it.

Don’t get it right, get it written

To quote Hemingway: “The first draft of anything is shit”. So don’t worry too much if your first stab at a proposition is tentative. Let’s quote James Thurber instead: “Don’t get it right, get it written.”

Once you’ve got a basic, tentative, rough-around-the-edges idea of what your website is for, you can start to nail down what should and shouldn’t be on it.

You don’t just need to think about external user needs here, you need to make decisions about internal user needs and organisation needs.

For example:

• Should members of staff be able to find information about your organisation’s annual leave rules on the website? This is a legitimate need, but it’s an internal need. I’d suggest this would be better met on an intranet.
• Should you publish press releases on your website if no one actually reads them? What about a corporate report that is produced by the organisation but only a handful of external users would ever want to read it (and most of them already have the email address of someone who could send it to them). Should that report be on the website?

If you want your next website to be better than your last one, you must develop criteria for determining whether or not a piece of content (that someone in the organisation might desperately want to be on the website) should actually ever be published in the first place. It takes time, but I promise you, it’s time well spent.

Run a propositionworkshop

A proposition workshop can be a quick way to get to a first draft of your proposition document.

Get the team together, book half a day (if possible), and have a goal that you’ll have a basic idea of what your proposition is by the end of the workshop. You can always tweak it (endlessly) afterwards.

1. Ask questions

   When I’m running a proposition workshop, I start by asking:

   • What is the organisation about?
   • What does it do?
   • Does it have a mission statement?
   • Does it have a vision statement?
   • Does it have a strategy?

2. Decide what’s definitely out and what’s definitely in

   Create two columns on a whiteboard or flipchart. At the top of the first column write “It’s out if…” and at the top of the second write “It’s in if…”.

   I usually start with ‘out’ as people seem to find that column easier to populate! Usually there are lots of pet hates in people’s minds. For years you’ve been saying “That shouldn’t be on the website!” about things that are on the website. Well, now’s your chance to get it all out.

   It’s therapy time. The proposition workshop is your chance to release all of that bile that’s been elevating your blood pressure and make sure all those hideous publishing crimes never happen again.

   Some of it will be obvious. For example, it’s out if... it’s in Swahili and your audience is English speaking. It’s out if... it is vanity publishing about someone’s holiday and it doesn’t relate to what the organisation is about.

3. Think about the grey area

   But there are bound to be grey areas where you’re not too sure. For example, do you allow promotional content? After all, your organisation wants to promote certain messages and has a large, well-resourced department designed to do just that.

   On the other hand, evidence shows that this kind of content doesn’t do well on your site because users aren’t actually searching for your marketing department’s latest strapline, no matter how clever it might be. It doesn’t serve a user need, it serves an organisational need. And on your website, it serves that need very badly, judging by the analytics. Does that mean it’s out?

   I vote OUT! That’s not a good use of the website. Stick that in a radio ad or on a poster at a bus stop. But don’t allow it on your website. It just clutters up the place.

   The grey area in the middle is where you really start to get your communal head around your proposition. You also start getting into what things mean. For example, when we were trying to work out the GOV.UK proposition, there was a big thing about advice. GOV.UK isn’t about advice. For example, the previous website had content advising users to wear a jumper if it was cold.

   Seriously, it did. The government was advising its citizens that it’s a good idea to wear a jumper if you’re cold.

   Someone had to write that. My guess is someone had to request it, someone else had to check whether it was official government policy, someone else had to confirm that it was factually accurate that jumpers keep you warm, someone had to publish it, and someone else had to check the analytics data.

   Your proposition is important, and the grey area in the middle is where you get to start with a vague sense that something shouldn’t go on your website, and end with a clear set of criteria that can form your proposition document. You can then show this to anyone in your organisation when they say “People need to know how to stay warm in winter. We have people literally dying of cold. This is a government priority. Publish it now!”

Regardless of business or industry, audiences expect engaging, useful content tailored to their needs. They will quickly dismiss content (and an organization or source that produces it) that is irrelevant, poorly executed, or disingenuous.

— Jennifer Leigh Brown

Is this your current pain?

• People with no training in content design have publishing rights all across your organisation.
• Those people don’t understand the Content Management System (CMS) and regularly hack solutions that work for their piece of content right now, resulting in broken pages as soon as something gets updated.
• Your web/comms/digital team suffers from low morale and high staff turnover as their job is essentially to respond to ‘urgent’ requests for content that could have been flagged up a month ago, combined with firefighting poor publishing decisions made elsewhere in the organisation.
• Your small central team has lots of responsibility but very little power.

One way to overcome these problems is to rethink the shape of the writing and publishing function in your organisation. Or in plain English: organise your content team.

Different ways to organise a content team

If you’re experiencing the pain I just described you’re currently organised in a distributed structure. There are several other ways you could do things and there are pros and cons to each approach. I’ll go through each one briefly and then recommend one.

There are 4 common team structures:

1. Distributed
2. Centralised
3. Hub-and-spoke
4. Matrix

1. Distributed Model

   You have people across the organisation with publishing rights. The benefit of this is these people are embedded in teams and can represent that team on the website. They have good relationships with subject matter experts so can get answers quickly. Quite often they are the subject matter expert, so can just write something and publish it, knowing that it’s correct.

   Senior managers often like this model because they think it’s a cheap way to solve the website problem. Instead of hiring a team of specialists to manage it, you just buy a CMS that’s relatively easy to use and can handle a lot of publishers, then get people with day jobs to do the web content too.

   I mean how hard can it be? Everyone in the organisation can write, so let them do the website as well as writing reports and emails.

   One of the most frequent problems with today's websites is not lack of content, but an excess of content. Without a strategy for continual review, refinement, and especially, de-duplication, users get frustrated and give up.

   — Noz Urbina

   The problems with this model are:

   1. Writing for the web is a professional discipline - and the people publishing content on your website don’t know how to do it. The content tends to be longer than it should be, poorly structured, not optimised for search engines (and therefore hard to find), and doesn’t meet accessibility standards, which means lots of your users can’t use it.
   2. The website is likely to grow every year and become increasingly unkempt. Publishers in a distributed model generally publish something and call that ‘job done’. But websites need constant care and attention to keep them in shape. So while it seems like a cheap way of solving ‘the website problem’, you’re actually just creating a debt that will need to be paid every few years in a big chunk in the form of a new website.
   3. No one has an overall view of the website. There is no overarching strategy, varied quality, varied tone, inconsistent style. This is bad for your brand reputation, creates risk (who knows what’s on there?) and generally leaves your users searching elsewhere for the information. Bad for business.

   More can be less. Huge sums are often wasted on agencies or teams incentivised to generate ever more traffic to sites. But imagine throwing thousands more cars into a neighbourhood that is poorly signposted, with roads in disrepair, and poor lighting. It's not pretty. Governance puts in structures that make sure authors and users can move through a system, not get stuck in a mess.

   — Noz Urbina

2. Centralised Model

   This is where you have one central team responsible for the content strategy and the content. It’s great for small organisations. It solves all the problems of the distributed model.

   Not only does it get rid of the problems, it tends to lead to a consistently improving site. The team can learn from each other, sharing ideas they just found out about in a new blog post, on a course or at a conference.

   The central team is made up of professionals in the field. They love discussing the correct use of a particular sentence structure and delight in the difference between the en-dash, the em-dash and the hyphen. A passionate content team can empty a pub within half an hour and not even realise.

   There are a couple of other problems with the centralised model which mean they tend not to be sustainable:

   • The model doesn’t scale. As the organisation gets bigger, you need a larger and larger central team. They get increasingly remote from the rest of the organisation, the team itself gets quite complex with layers of management, and it gets harder for the rest of the organisation to get anything on the website quickly. What might be a priority for a certain part of the organisation isn’t a priority for the content team. So frustration builds and relationships fray.
   • It can seem, and be, quite authoritarian. If a team has absolute power over what goes on the website, and they’re also passionate about content quality, content strategy and the correct use of a semicolon, they can be a bit challenging to work with. Again, frustration builds and eventually something has to change.
   • It looks expensive so rarely gets the resource it needs. The team is too small and is always dealing with more work than it can handle. This exacerbates the frustration problem for everyone - including the team itself.

3. Hub-and-Spoke Model

   This is the model I generally recommend when you have a fairly large organisation with a fairly large website. It’s a mix between the distributed model and the centralised model, organised in a way that allows for proper website governance.

   It’s called ‘hub and spoke’ because you have a central team (the hub) holding everything together and with overall responsibility for quality, but you also have as many distributed teams as you need (the spokes) with as much autonomy as is sensible.

   You can organise it in different ways. The hub might be responsible for:

   • Organisation-wide content.
   • High traffic content.
   • Certain content formats (eg overview guidance designed for a general audience, news and campaigns).

   Each spoke could be responsible for content that relates to their specific area of knowledge - certain types of specialist guidance for example. This is usually niche content that’s extremely important to the people who need it, but it requires a level of technical knowledge that means it would be slow for a central team to deal with it effectively.

   Because of this, and the fact that this type of content isn’t likely to be part of the user journey of most users, it doesn’t make sense for a central team to commit their time to trying to do this content justice. Far better to devolve it to the relevant spoke team.

   Here’s an example of what the hub and spoke model might look like:

   The exact makeup will depend on your organisation’s requirements, but the idea is that you have someone in each spoke who is responsible for the content in their area. You don’t just devolve the bits of the site you’re not interested in to a random selection of people with publishing rights and hope for the best.

   Ideally you also have a quality assurance function in each spoke. That might be the same person as the lead, depending on how big the spoke team is.

   The central team might be organised in a way that allows it to provide shared services to the spokes. So a spoke team could request help from the user researcher, or maybe the delivery manager function is for the entire hub and spoke team, not just the central team. The central team could also lead on managing a shared road map for the entire site.

   All these are ideas that may or may not meet your organisation’s specific needs. You should develop your own model, and build in flexibility so it can continue to develop over time.

   The way you organize your content team can make or break your team's morale and effectiveness. Position your content peeps to be more proactive than reactive and, consequently, succeed.

   — Colleen Jones

   Developing a content community at your organisation

   The central team should be responsible for:

   • Overall content strategy and structure of the site.
   • Overall quality of the content on the site.
   • Supporting the spokes to make sure they can play an active role in the site at the necessary standard.

   One way to do this might be for the central team to lead on developing a content community for the organisation.

   Slack is quite often used for this kind of community. A place to discuss issues, ask questions, share new knowledge and interesting blog posts, and generally feel like you’re part of something, not stuck in the Outer Hebrides of the organisation struggling alone.

   The community might also decide to keep more stable content (eg ‘How to do x, y or z’) outside of Slack in a wiki or on an intranet. Maybe there’s also a weekly mailout to community members.

4. The Matrix

   Matrix management came out of big organisations in the 1980s. Say you have a Head of Widgets. They’re responsible for all the widgets produced by the organisation in all countries where the company operates.

   Then you have someone who’s in charge of everything that the organisation does in Japan. This includes widgets.

   The widget department in Japan therefore has two people to report to. Hopefully those two people get on and coordinate their work. If that happens then the organisation is great in Japan and it’s also great when it comes to widget production across the world.

   The trouble is, if someone in the widget department in Japan has a problem, who do they talk to? They need to spend an extra £100,000 to fix the problem. Whose budget does it come out of? Who decides if that person gets a bonus that year?

   In short, lots of potential, and lots of potential problems too.

   In the content world, there are two ways to make use of the matrix. You could have someone responsible for a subject area on the site across all types of content (eg employment issues). Then you’d have someone else responsible for a section of the site (eg campaigns content).

   So when you’re doing a campaign about employment issues, those two people have to coordinate their work. If it goes well, the campaign is better because it properly takes into account everything else going on in that subject area on the site. And the user journeys for new traffic coming in through the campaign should be excellent.

   The other way it could work is when your content ‘team’ isn’t really a team because you’re not focusing on the website, you’re making digital products and services. The content designers don’t sit in one big team talking about semicolons. Each content designer is embedded in a multidisciplinary team, along with other UX disciplines, developers and whoever else.

   You have a manager for the multidisciplinary team responsible for making a great service. Then you have a manager responsible for all the content people across all teams, making sure the content across all products and services works as well as possible and feels like one experience to the users.

   The matrix works well when:

   • People in the organisation talk to each other and cooperate.
   • The team members are comfortable taking responsibility for their own work and dealing with a certain lack of structure and clear lines of responsibility.

   These types of organisations are lovely to work for, but they tend (in my experience at least) to be smaller and younger. As the organisation grows and matures, you get territorial disputes, miscommunication, competition for budget, silos and a fragmented culture. Ironically, the size of organisation that the matrix was designed for might well be the worst place to try it.

Many large organisations have hundreds, or even thousands of people with rights to publish on the website. And then they wonder why the website is difficult to use!

A publishing model like that is impossible to manage. There will be no overarching content strategy (or if there is one, it will be unknown to or ignored by the vast majority of publishers). No one is in control. It’s risky for the organisation and frustrating for the user. Something will have to change. You need a new model.

In short, ‘governance’ means who can say no to whom, and when they get to say it. Getting your governance right can make or break your website or digital service. It is very important.

I can’t emphasise this enough. Everything else in this book only works if you have your governance in place. It pulls all the pieces together. Workflow, proposition, user needs, agile - none of it will work if you can’t say no to the right people at the right time. If you can’t say “There’s no user need so we’re not going to create content about that” and know, with confidence, that no means no, you may as well not bother.

If someone in your organisation can either publish it themselves, or simply go to their boss, who goes to your boss, and the result is you end up publishing something with no user need, or something that’s full of technical language no one but them can understand - in that moment your organisation has killed content design.

Well-structured governance is your Excalibur. Grab that sucker, get it out of that stone, and never let go! With a weapon like that you can fight the good fight.

Innovation won’t come from labs, it won’t come from offsite away days, or from AI or Blockchain or whatever the next over-hyped technology ends up being. True innovation comes from teams that do. Teams that are allowed to do.

— Mike Bracken

Why you need toget this right

The main reason why governance is important is people have different perspectives on what good looks like. They also have different priorities. For some people the top priority is to serve the organisation, for some it’s to serve the user/customer, and for many it’s to serve themselves.

If you have a strong governance model, executives should never have to resolve an internal dispute about the website, because everyone will know how it works.

— Hilary Marsh

I shall illustrate this by talking through a made-up coffee business.

Life cycle of a made-up coffee business

When an organisation is young and small, it will only survive if it effectively serves its users. Imagine a sole trader selling coffee from a stall on the street. If the coffee is not very good, if the stall is in an inconvenient location, if the sole trader is rude, or if people prefer tea, that business will either need to change how it functions so it meets user needs, or it will quickly fail.

As an organisation gets larger and older though, things change. Let’s imagine that sole trader did everything right. They secured some proper investment, scaled the business, got a great logo, and now have a franchise in every high street in every town and city in the whole country.

The person who serves you coffee in one of those franchises probably has a different set of priorities to the sole trader when the business began. They have no stake in the business, are not being paid well, and probably don’t see this job as their career. They may still be great at serving coffee and the customers may love them. But if they aren’t, the business as a whole will not fail and the people in head office won’t ever get to hear about whether or not this particular barista was great or terrible.

Then there are the people who own that business. They never see the customer’s face. They see a spreadsheet with numbers in it. One of those numbers is the profit margin. Another is how much return they got on their investment this but somehow they don’t care about those as much.

The owners of the business only indirectly care about the customer. And whether or not the customer is happy isn’t necessarily the top priority.

Perhaps, for example, they do some research and find out that if they switch to a coffee that’s 5% worse they can get it 10% cheaper and only lose 3% of their customers. That sounds like a great deal! It’s not a great deal for the customer, but it’s a great deal for them. That spreadsheet now has some even better numbers in it. Mmmmm, I can smell the leather seats on that new car from here.

Finally, there are the many people in the middle. Hundreds of thousands of them! They have made a career in this made-up coffee business. They have committed decades to it. They understand the rules, they know what works and what doesn’t in terms of improving their career prospects. They have friends at work who are pretty much like them and generally, as work goes, they are happy. Keeping things going exactly as they are works well for them.

Now let’s imagine some new starters arrive in the organisation. The people in head office have decided that in order for the business to prosper in the long term, it might be a good idea to actually think about what customers want from the business and then get everyone in the business to do their best to give the customer what they want. Weird, huh.

These new starters they’ve hired to make this happen keep going on about ‘meeting user needs’. They don’t dress right, they don’t act right, they’re not company people, but for some reason the bosses say they know what they’re doing. The thousands of people in the middle of the organisation unconsciously but pretty much unanimously decide that they are just going to wait around until these young upstarts fail and leave. Between now and then, they will cooperate if they absolutely must, but it’s not going to be high priority, and it better not get in the way of how they do things.

Governance and culture change

What happens next in this made-up coffee business is one of 2 things:

1. Beginning with the best of intentions, the new starters get to work. They start trying to change things so that the organisation can best meet the needs of its customers. However, at each turn they run into a quiet wall of apathy, broken promises, slow response times, dilution of the approach, reframing of the key messages, and general dragging of feet, for as long as it takes, from a significant percentage of the workforce. It takes a while to notice, but the new kids eventually realise they are failing to make any real headway with the whole user-needs thing. One by one the new starters get frustrated and leave, or resign themselves to the fact that nothing ever really changes in this place and they may as well join the status quo. Maybe they made things 1% better. That has to count for something, right? And the old way really isn’t so bad. And if you stay long enough and keep your head down you get great benefits. Corner office, anyone?
2. The new starters begin their user needs project by creating a set of clear, enforceable rules to make sure the new culture of user needs takes shape. Every time these rules are challenged the new starters are able to point to the clear, signed-off document that details how this goes. When the challenger points out that they are a special case, a unique, snowflake-esque being that deserves special treatment, the new starters are able to politely disagree and escalate the issue to their boss, their boss’s boss, or as high as it needs to go to get the issue resolved. Because the rules are clear and the top of the organisation is behind them, the new starters know that they will win any argument. The lovers-of-the-status-quo start to realise that they aren’t going to get anywhere with their usual sabotage routine, and inch by inch, the culture changes. A new normal is embedded in the organisation. The made-up coffee company now produces great coffee, has friendly baristas, and develops a whole range of other innovations that help customers have a great experience and end up increasing the profits and market share way more than the old way had ever done. In the end, everyone is happy.

What good content governance looks like

When it comes to content, the main thing to remember is you need to separate ownership of the user experience from ownership of the facts.

This means that the person or team responsible for making sure a piece of content is factually accurate should not be the same person or team creating and publishing the content.

It also means that the person who is an expert in the facts can’t specify how those facts are communicated to users. Content designers are the ones who do that part. Because they are the experts in that part.

People associate the term "governance" with red tape; with barriers and being held back. Good governance is like the roles and hierarchy in a theatre production team or military strike force. Clear rules and roles make you work faster, not slower.

— Noz Urbina

Ideally, you have two (or more) experts in complementary fields collaborating positively to produce great content. Because this is digital content we’re talking about, the content designer has the final say about what goes live. They must take account of the subject matter expert’s (SME’s) views, and must change any content that is factually inaccurate. But they don’t need to take into account any comments that are editorial in nature, and they need not phrase content in a specific way (such as using language lifted directly from law) purely to satisfy an SME or lawyer that the content is factually accurate.

Effective content is a partnership between subject-matter experts and content publishing experts.

— Hilary Marsh

Plain English that makes sense can be factually accurate. It doesn’t contain all the nuance of the words used in the original legalese but the average person will be able to act on them without hiring a lawyer. This is what the website is for. If the average person can’t make sense of it, the website has failed (unless the website is specifically and exclusively designed for lawyers or other specialists - and even then plain English generally works best).

Who can say noand when

In the section on workflow, you’ll see there are different stages a piece of content generally goes through. There’s a drafting stage, a review stage, a fact check stage, and perhaps a sign-off stage. You might have other stages, such as a legal compliance stage, if you’re working in a specific sector that requires it.

Workflow and governance are joined at the hip. Workflows are usually what we'd like to happen. Governance is what kicks in when reality gets in the way. Governance is the jack and the spare that get you back on the highway.

— Noz Urbina

You need to arrange these stages in a way that makes sense, and allow the right amount of time for the different stages. If your fact check stage is 5 days or 10 days long, that’s when the content designer can’t mess with the content and the SME can make their comments. At the end of that stage, the content (plus comments from the SME) is once again owned by the content designer. The SME can’t add any more comments at that point. Instead, this is the time for the content designer to address the comments already made.

If you start to mess with the stages, or allow your stages to get messed with, it won’t be long before your project falls apart. Obviously if something’s not working or you think of a way to optimise it further, that’s different. Part of the kanban way (see chapter 6 on agile) is that you should continuously incrementally improve your production process.

But what you shouldn’t do is let your second draft get held back indefinitely because the SME keeps forgetting to comment. You shouldn’t allow 5 rounds of fact check when you’ve agreed 1 round because this SME demands it. You shouldn’t have 3 weeks of discussion with a lawyer about fundamental aspects of the final content if the workflow states they must comment during the fact check stage.

You must be quite hardcore about this. You’ll be amazed how many ‘special cases’ you experience. If you start to allow it, you open the floodgates to chaos.

So design your governance model at the beginning, build it into your workflow, get it signed off by the most senior person you possibly can, and stick to it. You project will go so much better if you do.

A mature governance structure provides strategic alignment and increased efficiencies within your content team. Without a governance model, tasks like onboarding new writers or restructuring can be monumental. Do your future-self a favor and make an early investment in governance. You'll thank yourself later.

— Mike Petroff

Content design is fundamentally about acknowledging that people matter. We care about them and try our best to give them a good experience. We help them do what they came to do as quickly, easily and low-stress as possible, and then we leave them alone.

When you see a site, particularly a public sector site, that hasn’t had the benefit of effective content design, you remember the bad old days when people just published what they thought was important, rather than what users needed to know. I’m extremely keen that these days never return.

What makes goodcontent design?

You need a balance of three things:

1. User research
2. Analytics
3. Content design best practice

If you lean too much on one of those pillars, the whole thing falls over. You need qualitative data (such as user research) but don’t be paralysed into inaction if you don’t have it, or don’t have enough. You can always change it later.

You need quantitative data (such as analytics and online surveys) so you can see the big picture. But often the data just isn’t there, or is inconclusive, and you need to do what you think is best anyway.

And you need content design best practice. But if you rely solely on principles of writing for the web you probably won’t meet the actual needs of your actual users.

Here are a few principles to work by:

• Put the most important information first.
• Keep it short.
• Use plain English.
• Use lists.
• Focus on the user need.
• Break it up with subheadings.
• Structure it around the user’s mental model, not the subject matter expert’s.

If you take time to understand the mental model your users have when consuming your content, you'll be able to structure it for faster, easier, more pleasurable consumption. It's always so much easier to navigate - within a page or between them - when things are laid out in a familiar way.

— Noz Urbina

You need to fight hard for content design. Many in the organisation won’t understand the importance, and won’t see the difference. As a content designer, quite often you’re the user’s only advocate. You’re the one who talks both to the digital team and to the subject matter experts and the lawyers. It can be a tough job.

Know when to hold em, know when to fold em

The strategy is delivery. In the end, you need to get the content out there. So protect the content, but don’t be afraid of pragmatism. If you’re in the middle of a huge argument with a lawyer about the general versus legal meaning of ‘reasonable’ and it’s stopping you from moving forward with the rest of your project, maybe let it go for now. You can always revisit when things have died down.

Good enough is sometimes better than perfect. Don’t get too dogmatic about all this.

I’m Buddhist and over the years I’ve seen so many groups from this school or that school convinced that their way is the only way. All other ways are either derivative, inferior or degraded forms of the One True Path.

It’s amazing how attached people can get to non-attachment. The world of agile reminds me of this sometimes.

Some people see agile as a project management methodology. Others see it as a mindset. Yet others see it as an approach. I see it as all of those things.

People get attached to the way they see agile, and the way they think it should be done. If you’ve been taught agile or your team is doing it, it may be that there are some significant differences between what you do and what I write here. That’s OK. Diversity is healthy for communities.

If you’ve never worked in an agile way before, I hope this chapter will help you to get something going. For digital projects, it really is the best way forward.

The waterfallapproach

The pre-agile ‘waterfall’ approach to project management was developed during the industrial revolution. If you’re trying to build a big bridge or a skyscraper, waterfall is what you need.

Waterfall essentially means ‘first A, then B, then C’. Some things might not be dependent on each other so you might be able to start A and K at the same time, but you won’t be able to do B or L until they’re done.

There is some element of this in digital projects, but nothing compared with building a skyscraper.

With a skyscraper, you need to get the foundations in before you can do much else. And you can’t build floor 10 until floor 9 is complete. You can’t put the carpets in before the floors are done.

Digital projects aren’t like that. With a digital project you might want to build a floor, put a carpet in, test it with users, then scrap it and build a different kind of floor and put tiles on it, then test it again. It’s a different approach.

Going back to waterfall, if you want to build a skyscraper you need a very good, detailed plan of what the skyscraper is going to look like before you start building. You need to know exactly how much it’s going to cost as well. If you run out of money at floor 36 of a 42-storey skyscraper, the project has failed. Again, digital projects aren’t like this.

And yet, digital projects have traditionally been managed in the same way:

1. Write a detailed project plan.
2. Write a functional spec and a technical spec.
3. All stakeholders discuss and eventually sign off plan.
4. Spend loads of time and money building website as one gigantic beast
5. Launch the magnificent beast (2 years later).
6. Everyone celebrates and pats each other on the back.
7. No one visits the website.
8. Changing the website is very expensive because of how it was built and the contract that was signed.
9. Stakeholders commission a new plan.

If you’re a traditional manager in a large organisation, taking this approach seems like the low-risk way of getting the website done. At least until point 6 is done.

After all, you don’t have to commit to anything until you’ve seen a very detailed, costed plan. You know exactly what you’re buying. You know how long it’s going to take. And you can watch, week by week, progress report by progress report, to ensure that the plan is being followed and the budget and timescales are both on track.

Agile doesn’t work like that.

The agile approach(from a waterfallperspective)

You go to the person holding the purse strings in an organisation and say, “We think there’s a problem. Can we have some money please so we can see if we’re right and come up with an idea for how we might solve it?”.

That phase is called ‘Discovery’.

Let’s say they gave you some money and you ran a discovery. The next phase is where you say “Hi there! Remember me? Yes that’s right, the one with the problem. Yes here’s the data to prove it. We think we might have a way of solving the problem but we’re not sure. Could we have some more money please so we can see? Don’t worry, if it’s wrong, we’ll just throw what we build away and try something else.”

That phase is called ‘Alpha’.

Let’s say your manager likes you and decided to go double or nothing and let you run the alpha. What happens next?

The next phase is ‘Beta’. In that phase you take the thing that looked most like it might work in alpha, and try it in public, on a large scale, with real people. So now your poor, faithful, in-it-up-to-their-neck manager has you standing in front of them saying, “Hello! Yes we have something that looks like it might solve the problem. We’re really excited! What we’d like now is for you to give us a bunch more money, quite a bit more actually, then we’ll build a ‘minimum viable product’ [which translates to your manager as ‘half-baked idea’] and launch it in front of your customers. Yes, that’s right, real ones. And we’ll ask them what they think! Don’t worry, we’ll tell them it might well not work properly and then we’ll mess around with it loads right in front of their eyes until it’s approaching something that looks reasonable. It still won’t be finished though.”

So that’s ‘Beta’.

Finally, you’ve messed around with it so much, done so much testing and got so much feedback that you’re sure you’ve understood the problem and you’re also sure that what you’ve come up with solves that problem for your users. You’re happy, your organisation is happy, your users are happy. Job done!

And that’s how you get to ‘Live’.

Agile is great because by the time something is live, it definitely works. The same can’t be said of a waterfall project. Unfortunately, before you get to live, traditional managers can find the whole process quite anxiety producing.

Buying agile

I spend quite a bit of my life writing proposals to undertake digital projects. As I write this I have three of them to amend. I’ve been asked to amend them because there’s not enough detail. The people who asked me for the proposal understand how digital projects go. But their bosses - the ones who need to sign off the money - generally don’t. So they want lots of detail about exactly how the projects will be run, what the steps will be, how long each step will take, when each step will be complete, etc. In short, they want me to give them a waterfall-style breakdown of an agile project.

The true answer (no matter whether you’re doing waterfall or agile) is that nobody knows. How long is a piece of string? We will juggle things and if there’s a budget and/or a deadline, we will hit it one way or another.

But that’s not what people want to hear. It requires trust in the person, and when you don’t know the person, how can you have trust?

So, as a small company, I often have to play the non-agile game and try to sell agile once the relationship is built and we’ve proved ourselves.

This is frustrating, and not just to me. Recently there was an ‘unconference’ (where the participants decide the agenda) on agile procurement. Lots of companies who are confident and able at running agile projects and getting great results are coming up against the same problem.

This problem is wasting lots of public money. Procurement frameworks like those on the Digital Marketplace are trying to change things. This is a great step forward. But unless the mind changes, reality doesn’t really change. You can pull the tail off a lizard but a new one always seems to grow back in its place.

So here is my pitch to those anxious about agile and why it’s OK to chill out a bit...

Agile is low risk

On the face of it, agile looks really high risk compared with waterfall. A manager has to give some money without knowing what they’ll get in return - or when. They may even end up with nothing at all.

But in reality, agile is way lower risk than waterfall. As you can see from my parody above, by the end of the process, you have something that works. What’s more, you’ve had plenty of opportunity to know in advance whether your assumptions were wrong (which they usually are to a greater or lesser extent), and respond accordingly.

If you’re going to fail, you fail fast, at a fraction of the cost of doing it the old way. This is what makes agile low risk.

Furthermore, if the landscape shifts or you get significant new information while you’re in the middle of your project, agile lets you respond. You don’t have to go on following your plan regardless as you would in a waterfall project. You can change direction and still get paid. You’re judged on your ability to home in on what works,not whether you followed the plan or not.

In the fast-moving world of digital, this kind of agility is vital. In the slow moving world of building skyscrapers, following a plan is the best route to success.

The signs that things have changed are subtle. You have to really get inside a project to see why. You need to build up some history of doing digital in different ways. For a manager who isn’t steeped in digital, it’s not surprising that a digital project looks pretty much like a non-digital one:

• You have a thing you want to achieve.
• It requires money.
• It will take some time.
• There’s some risk that it won’t succeed.
• You need people with the right skills to work together to get the result.

I mean, what’s so special about digital?

But if you’ve been a practitioner working on digital projects run the waterfall way, and then you get to work on an agile project run well, it’s like this massive weight has been lifted off everyone’s shoulders. You can just get on with it and make great stuff that delights users.

Why it’s OK to get naked in front of your customers

Apart from the phantom risk of the unknown that appears to float around an agile project (but isn’t scary once you’re used to it), there’s also the apparent risk of embarrassment from standing in front of your customers while your trousers fall down.

It seems positively foolhardy to launch something that’s not finished. But the world is changing, and so is your relationship with your customers. In reality, if you communicate it properly, users are very happy to have the opportunity to try out the thing you think might be significantly better than the thing it will replace. They also appreciate the opportunity to give feedback at a time when it might actually make a difference.

You’re giving your customers power and co-designing with them for their benefit.

How many times have you battled with a terrible website, knowing full well that if you complain about it your complaint will lead precisely nowhere? Imagine the feeling of empowerment when you can basically co-create the next website with the organisation. All the issues get ironed out before the project team wanders off. Change happens quickly. Bliss!

The agile mindset

I hope I’ve given some sense of what it feels like to go agile. It’s a mode of being or a mindset as much as it is anything.

The Agile Manifesto that kicked this whole thing off is actually really short. It simply says:

• We are uncovering better ways of developing software by doing it and helping others do it.
• Through this work we have come to value:
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
• That is, while there is value in the items on the right, we value the items on the left more.

To make this even shorter, agile is about trusting our people to make stuff that works. We don’t want long reports, a really long planning phase, or an even longer contract that commits our supplier’s soul to eternal darkness (plus a gazillion sub-clauses to define specifically what a ‘soul’ is, what ‘darkness’ means, and exactly how the one will be committed to the other).

At the core of agile is the requirement to exhibit central values and behaviours of trust, flexibility, empowerment and collaboration.

— Association for Project Management

How to do agile:the short version

Start with a bit of goodwill and trust. Build on that by setting up your project so you can show your client/boss things that work on a regular basis.

Let your teams manage their work in a way that makes sense to them. As a ‘manager’ your job is really just to remove any obstacles that stop the team from getting on with it. You are more of a facilitator or ‘servant leader’.

There’s a saying that the chief is the poorest member of the tribe, because when anyone has a problem, they go to the chief. It’s a bit like that, only with more sticky notes.

How to do agile:the longer version

Since agile is fundamentally what I’ve just told you, you can do it any way you like that has those qualities and achieves positive results. But in practice, there are a few approaches that have been developed that tend to work well in agile projects. They’ve become so popular that often people think they’re what ‘agile’ means.

I think it’s important to have the wider context within which these approaches sit. And if they don’t work for you, evolve them into something that does.

Kanban

Kanban was developed at Toyota in Japan. It means ‘signboard’ in Japanese.

It’s all about efficiency. You achieve this by optimising the flow of value through a business. But what the hell does that mean to us?

We use a kanban board to watch how a project moves from having everything still to do to having everything completed and delivered. Quite often the kanban board takes up a wall in the office. The wall is filled with sticky notes or cards. Each note or card represents a task.

For remote/distributed projects, the ‘wall’ can be done perfectly well on Trello, Pivotal Tracker, Jira, or whatever product tickles your fancy. Personally I like Trello.

The wall is split into columns representing your workflow. At its most basic, there could be 3 columns: TO DO,DOING, and DONE.

Generally, they’re more sophisticated than that. For example, your columns for a standard website content project might be:

• Not started
• 1st draft
• Internal review (in my circles this has become known as ‘2i’ - which began life as ‘second pair of eyes’ and gradually got contracted so it was easier to write on a kanban wall!)
• Ready for fact check
• Out for fact check
• Back from fact check
• 2nd draft
• 2i
• Ready for sign off
• Signed off
• Published

Each ticket (ie sticky note or card) would be a content item. By watching the work move across the wall, you can easily see how fast things are moving and whether there are any bottlenecks at any point in the process. If there are, you can address them, thus keeping the flow going.

In my experience, bottlenecks tend to happen at 2i (eg because there aren’t enough 2i people available, or because the drafts going into 2i aren’t of sufficiently high quality) and fact check (usually because the people who need to fact check the content are really busy with other work and this fact checking business doesn’t feel high enough priority to them to take precedence over the other work on their plate).

For a service design project, the workflow will be different. You may need to factor in the build phase (where the developers take what you’ve done and actually build it so it works). You may need to factor in weekly testing. There may be a user research phase running in parallel or at certain points in the process. Etc, etc.

Some principles of kanban:

1. Start with where you are.

   Map your process as it is right now, then evolve it incrementally to maximise efficiency. Big sweeping changes freak everyone out and therefore cause their own inefficiencies.

2. Anyone in the team can suggest a change.

   In the car factory, if anyone on the shop floor saw a way to improve production they could stop the production line and suggest it. You don’t have to be a manager to spot what’s not working.

3. Focus on finishing by limiting your work in progress.

   Now personally, I think this is very relevant when you’re making cars and less relevant when you’re creating content. You don’t want your factory filling up with half-finished cars. With a digital project, you don’t have the same problems with storage. But the principle is definitely worth adhering to unless there’s a very good reason not to. You have to decide what the limit should be. On the one hand, if you can’t do any more on one thing you’re writing because you’re waiting for some questions to be answered, you don’t just want to sit there twiddling your thumbs. On the other hand, if that means you don’t push for answers and you end up with 10 things on the go at the same time, you’ll lose your train of thought, quality will suffer, and maybe nothing will ever get published.

4. Don’t break your process.

   Once you have a workflow in place, follow it except when you’re improving it. I’ve found in content teams that they often receive requests for something that would break their system.

   - “This article is really urgent. Can you please stop your work on the other things and do this one. Just this once?”

   - “I know we agreed to fact check drafts in 5 days but we had other things to do so the next few will be 6 weeks. But when they’re done can you push them to the top of your pile and get them signed off really quickly because our manager wants to see them.”

   - “We urgently need to discuss your ideas and be informed at the end of each day what progress you have made. And we will be making changes to your work. Please send us everything as a printed out document. We will then put lines through things we don’t like and add changes in biro and leave it on your desk for you to amend.”

   You need to practise saying no, diplomatically and politely. I see so many content teams stuck in a chaotic swamp, reacting at breakneck speed to whatever gets thrown at them from elsewhere in the organisation. It’s not efficient, it’s not fun, and it doesn’t benefit your users. Stop it!

5. The blockages are the priority.

   If there is a blockage or bottleneck in the process, solve that first. In reality this often takes some time, but basically, don’t ignore it and hope it goes away.

6. Ditch what you don’t need.

   I mentioned at the start of this section that kanban looks at the flow of value. Overly bureaucratic processes might make others in your organisation feel more comfortable about what you’re doing, but they don’t add value. The end user doesn’t benefit. The cost of production is higher and the speed of production is lower. So keep looking for what doesn’t add any real value and get rid of what you can. If you currently need 4 rounds of fact check and 3 levels of sign-off before you can send a tweet, maybe there’s a way to streamline that process.

Scrum

There are entire books on scrum methodology. In this section I’ll just cover the absolute basics.

Scrum is a way of running a project by dividing it into ‘sprints’. A sprint is the amount of time it takes to get something delivered (that might not mean finished, but it has to be a clear point in the process where you can hand off to someone else). Often, a sprint is a week or a fortnight. It’s quick - that’s why it’s called a sprint.

A sprint generally:

• Starts with sprint planning - where your team looks at what is left to do, decides how much it can commit to deliver this sprint, and decides who will do what.
• Ends with a retrospective - where your team looks back at the last sprint and decides what worked, what didn’t and what could change to improve future sprints.
• Includes a daily ‘stand up’ - which always struck me as ableist and in need of a change but is basically a quick catch up in the morning where every team member says what they did yesterday, what they’ll be doing today, and anything blocking them from getting on with it.
• Often includes a show-and-tell - where you share your work with others and get feedback.

The team has two managers - one is in charge of the quality of what you’re doing (a product manager or content lead) and the other is in charge of the process and what the team is delivering (a scrum master or delivery manager). They work together to provide the team with the conditions they need to produce quality at pace.

To move your organisation towards a content strategy based on user needs, you need your organisation to change.

If you’re following the approach outlined in this book, you’ll probably be putting together a new:

• Proposition
• Workflow
• Governance process
• Team structure
• Approach to making decicions

In short, lots of new stuff.

You and your team may be convinced of the benefits, but the rest of your organisation probably doesn’t realise there’s anything wrong with the way you do things right now, and they might even like the website the way it is.

To bring about your content revolution successfully, you need to get these people on board. If you don’t, they will either resent, ignore or be entirely confused by the new way of working.

Then, when you need their help to get a piece of content fact-checked, you won’t get the result you want. And when they send you something to put on the website out of the blue and you say no, they’ll not like you very much.

That damages a vital relationship. Their experience of the new approach will be that it doesn’t work, because they used to be able to get something on the website when they needed to and now they can’t.

This will be especially true if they used to have publishing rights to do it themselves.

To make sure this doesn’t happen, you need to communicate before, during and after any changes are made.

Before: User needsworkshops

The people in your organisation each have a unique perspective on what your organisation is about, what the website is about, who the users are, what they need, and why they need it. You need to take these perspectives into account.

You also want to explain your vision to them and why you’re doing what you’re doing. As part of this, you want to create a space where people can give their opinions and ask questions.

User needs workshops can be a nice way of combining all of this. When I’m working with an organisation, we’ll generally have a user needs workshop for representatives of every part of the organisation that has anything to do with the website.

By getting out there and talking to people, you get to explain what you’re doing, answer questions, gather perspectives and generally get the word out that things are about to change. There will definitely be things you haven’t considered. User needs workshops can help you amend your plan before you’ve even started.

1. Invite your stakeholders and outline an agenda to make sure expectations are clear for any preparations required and the desired outcome.
2. Start with a short presentation outlining what the changes are about, then give some time for questions and discussion.
3. Have tea and cake. This is an essential step! Then all but a few people leave and we do the workshop.

By this stage, the people in the room understand what ‘user needs’ are, and can start to work with the user story format:

• As a ...
• I want to ...
• So I can ...

The workshop is about capturing what the participants think the user needs are.

In this way, you've:

• Flagged up that things are changing.
• Explained why.
• Gathered views and opinions.
• Answered questions.
• Given people a way to participate so they’re part of the change rather than innocent bystanders having the change forced upon them.

Of course, you’ll need to do plenty of talking to actual users to come up with the user needs you end up taking forward. But the stakeholder user needs workshops are helpful to get a sense of how close stakeholder and user perspectives are. If they’re miles apart, it’s likely you’ll need to put extra time and effort into showing stakeholders exactly what users are saying they need, and exactly how well the user-needs-based content performs compared with how the content they thought was important (but users don’t actually care about) performs.

During: Bloggingand Public talks

When you get going, blog. Tell your story, make it exciting, keep interested parties up to speed on progress, share what you’re learning, invite feedback.

If you just go into a room for 6 months and lock the door, then come out with a website or service and say ‘ta-dah!’, you are much more likely to get push back from the organisation. Push back is inefficient and not fun. Avoid it as much as you can by taking conscious steps to keep your colleagues enjoying the ride.

As well as blogging, speak at every opportunity you can. If your organisation has a ‘town hall’ event, speak at it. If it doesn’t, start one! If there’s a conference you can speak at, do it. If you get an invite to anything, just go.

Getting out in front of people might not be your cup of tea. I’ve found that, ironically, professional communicators are actually very bad at telling their own story. We tend to tuck ourselves away and quietly write things. Meanwhile everyone else in the organisation is blowing their own trumpet, and then we wonder why we’re undervalued! Get out of your comfort zone and tell your story.

After: See during

Actually, there is no after. In reality, we are in perpetual beta, always learning, always improving, always in process. Keep doing what you were doing with the blog and the public speaking. Maybe get some posters and stickers made up and give them to people. For some reason adults still like being given stickers.

It's time totransform

Building a content strategy around user needs takes some knowledge. But really, that’s the easy bit. Actually delivering that strategy means:

• Changing the way your organisation thinks about things.
• Reframing its collective view of what ‘digital’ means.
• Re-prioritising values so that meeting the needs of users is at the top of the list (where it probably was in the early days of the organisation).

My top 7 tips for making this happen are:

1. Communicate, and keep communicating

   That means listening as well as speaking. If people feel heard, they’re more engaged. Engaged people are more likely to support what you’re trying to do.

2. Be flexible

   The road to success is never straight. The map is not the territory. When you get into it, you’ll need to be smart about what to compromise on, and when to stand firm.

3. Divide it into manageable chunks

   Yes I know everything needs to change, and it’s really important that it all changes quickly. But the reality is it’s been broken for a while. Don’t work your team into oblivion. Neither hurrying nor tarrying, you will arrive at your destination.

4. Manage the mood.

   This is a hard road. It’s easy for people to lose heart when they’ve had a million arguments and the end is still out of sight. You will need to evangelise to keep people excited. You’ll also need to buy cake on a regular basis.

5. Just start.

   You might not have all your ducks in a row yet, but just start. All you need to know for sure is what the next step should be. You will never feel ready, so don’t wait for that feeling before you go for it.

6. Try not to see the organisation as the enemy

   I know it can be frustrating, but try to give the system a break. The sluggishness is there for a reason. For lasting success, you need stability as well as change. If things go well and you end up running a successful project, the organisation will start to protect your work. And you will become the establishment!

7. Look after yourself.

   Think in terms of team, task and individual. Sometimes the task will come first. Sometimes the team will come first. But don’t totally lose sight of your individual needs. Burnout is not fun. Go out for a walk. Get a massage. Buy yourself a treat. At the end of the day, it’s only a website!