Having worked on large and small websites for complex organisations around the world, I find that producing content is only a third of a content designer’s life. The rest is all the other ‘stuff’. It’s governance and workflow, what shape the team is, where to start a project, what success is and more.
This is the kind of ‘stuff’ people don’t always take into account. Too many CEOs think “we know about this - we’re the experts. Just grab the nearest person and write it all! Onwards!” as they charge off towards Google Results Oblivion. They create more content that audiences ignore. Before they know it, those CEOs have a three month workflow process, staff are leaving and no-one can understand why the product or service isn’t immediately rivalling Apple.
The answer is that it’s noise. Content noise, production noise, human noise. It’s just more noise.
I’m really pleased Padma’s written a book to show the other side to a content person’s skill that will help an organisation cut through all of that noise, both internally and for their audience.
We do so much more than just produce words, videos and infographics. You might need to help your organisation understand the value of user-centred content and show them how content-first will save them time and money but this book will help you to bring your organisation with you.
This book is about the vital role of content strategy in digital transformation, and vice versa.
If content isn’t put first, projects and organisations don’t end up doing so well. This book is an antidote to ‘content last’ experiences and ways of working.
It’s less about what order the words should go in, using bullet lists or the benefits of subheadings. Instead, it discusses the organisational processes and the systems and rules you need to ensure your organisation is capable of producing quality content in a sustainable way.
Only when you have a supportive (or at least non-obstructive) organisational culture can you produce content that responds to the needs of your users and get it published. And only when it’s published can your content meet the needs of your users.
From user needs, to getting the right people in place, to workflow and governance, this book will help you get ready to transform your content operations.
It won’t be easy. Content is political and digital transformation requires buy-in from all tiers. The thing is, it’s worth it. If you care about your users, you need a way to give them what they need. And even if you don’t care about your users, the only real way to meet your business goals online is to do it by meeting the needs of your users. So either way, you should read this book!
Digital transformation is a huge subject. A full content strategy must consider multiple channels (across website, social, print, and beyond), marketing and non-marketing content, potentially multiple languages, and how to deliver an integrated and seamless user experience across all of these efficiently and sustainably.
You will notice, however, that this book is quite short! The focus of this book is website content strategy only, though much of the approach is appropriate for other channels too.
Many people think that if you hire experienced content professionals, all you have to do is let them loose and you'll end up with a website filled with great content.
Unfortunately this doesn’t seem to be the case. All too often, the existing culture in an organisation is sufficiently entrenched to make progress towards the goal - meeting the needs of your users - basically impossible.
In your existing culture, your content team might be able to make your site 5% better. Maybe even 10%. You can add a little bit more plain English without anyone complaining. You can cut a few unnecessary words here and there. Maybe you can argue the case to remove the occasional semicolon.
And maybe the time will come when you’ll call that a win. We did our best. It’s better than it was.
Meanwhile you have some extra wrinkles in your forehead that weren’t there before, there’s lots more junk food in the office that people absentmindedly chew on all day, and the energy and enthusiasm you felt when the content designers first arrived has just, well, gone.
Never mind. Not long until retirement.
It comes down to change, and people’s fear of it. People joined the team (you may be one of them!) with ideas about user needs, designing with data, going ‘agile’.
And the people in all the other teams and all the other departments quietly freaked out.
Then they realised you needed their help to make this thing a reality. Some of them were quickly onboard and needed little persuasion. Many dug their heels in and internally repeated some version of ‘You shall not pass’. Convincing them would be part of the challenge ahead.
Getting the content designers in is a very good start. But it’s only a start. This is where the fun begins.
To actually realise your vision of a great website and well-designed services that genuinely meets the needs of your users, you’ll need a whole lot more than an enthusiastic content design team. That’s what this book will teach you.
If you include these elements in your content strategy, you’ll give your team the systems and processes they need to do their jobs. It’s part carrot and part stick. It’s tough to deliver a content strategy like this, but if you just focus on the editorial side, you content strategy is very likely to be ineffective.
I wrote this book because I’m busy. And a bit shy. And grumpy. And I hate phones.
I really don’t want to have to call up your organisation’s customer service, sit on hold listening to so-called ‘music’ for ten minutes, then try to explain my problem to someone who may or may not care, may or may not understand, and may or may not be able to solve my problem. I just want to do it all online, as quickly as possible, with as little thinking as possible required, and then go away and get on with my life.
If your organisation can do that for me, if you can go the extra mile to make my life easier and better, I’ll be your fan forever. I’ll spend lots of money with you over the months and years. And I’ll tell all my friends how great you are. Deal?
I know you would make that deal in a moment. And probably most of the people in your organisation would say they’d make it too.
The thing is, I’ve seen so many passionate people in digital parts of essentially non-digital organisations make that deal in good faith and try really really hard. They charge ahead, lightsaber raised up high. “Onward!”
After about half a mile they turn around and realise the rest of their organisation didn’t follow.
The truth is that getting those people to join you, or at least allow you to do what’s needed, is 90% of meeting user needs. The other 10% is great content design (and interaction design and beautiful coding and so on but this book focuses on the content bit).
If you’re a manager, you need to know this stuff. If you’re a content designer, you need to know it too so you can explain it to your manager.
If you’re in the senior management team, you definitely need to know this. Otherwise, you’ll commit to a digital transformation strategy, put your foot on the gas, release your organisation’s handbrake and nothing much will happen. You won’t know it until it’s too late, but your team will spend the next two years and the rest of your budget with their heads under the hood, twiddling bits of engine and looking confused.
I spend most of my time working on public sector projects. If my team doesn’t get it right, users end up in court for not complying with the law. Or they end up totally stressed out because they have a mental health problem and can’t work out how to get the help they’re entitled to. Or they can’t find out what they need to do to organise their affairs now that their loved one has died.
The internet has become the medium we use to interact with organisations about some of the most important things in our lives. That’s why it’s important. We need to put the right kind of effort into ensuring that experience is as easy, straightforward and non stressful as possible.
Enter your email and we'll send you the Kindle/ePub version of the book.
Organisations generally survive in the early days of their existence for one of one reasons:
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 finds itself in a situation that is all too common:
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:
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.
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
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.
There are lots of ways to do a content audit but generally, it starts with a spreadsheet.
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.
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.
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.
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?
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
Stakeholders across your organisation will also be able to give you insight into the needs of users because:
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.
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
If you do all this, you’ll have:
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?
You want to capture each user need as a user story. A user story looks like this:
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).
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
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.
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.
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.
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.
When I’m running a proposition workshop, I start by asking:
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.
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
GatherContent takes the chaos out of producing website content. Organise your website content in one place, ensuring content is in the right structure, well written and ready for the CMS. GatherContent also manages the workflow and approval processes, ensuring that content is complete and ready on time.
Is this your current pain?
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.
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:
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:
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
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:
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:
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
The central team should be responsible for:
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.
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:
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.
Enter your email and we'll send you the Kindle/ePub version of the book.
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
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.
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.
What happens next in this made-up coffee business is one of 2 things:
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).
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.
You need a balance of three things:
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:
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.
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 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:
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.
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.
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...
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:
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.
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!
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:
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
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.
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 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:
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:
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.
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.
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.
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!
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.
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.
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:
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.
GatherContent takes the chaos out of producing website content. Organise your website content in one place, ensuring content is in the right structure, well written and ready for the CMS. GatherContent also manages the workflow and approval processes, ensuring that content is complete and ready on time.
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:
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.
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.
By this stage, the people in the room understand what ‘user needs’ are, and can start to work with the user story format:
The workshop is about capturing what the participants think the user needs are.
In this way, you've:
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.
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.
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.
Building a content strategy around user needs takes some knowledge. But really, that’s the easy bit. Actually delivering that strategy means:
My top 7 tips for making this happen are:
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.
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.
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.
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.
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.
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!
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!
For my generation, the web is like the motorways/highways built by a previous generation, or the railways/railroads built by generations before that. We are building an infrastructure that fundamentally changes the possibilities, lifestyles and sense of place of the generations to come. (Did you know people used to think the human brain couldn’t function at faster than 30 miles per hour?)
This is a massive responsibility. We aren’t just building ‘cool stuff’ here. We are changing our children’s sense of space (they can now talk idly to granny on the other side of the world in a video conference for free), time (they can binge-watch any TV show they like from the last few decades) and normality (who they think they are and how they think they’re doing is deeply affected by what they see online, not just what they see in their real-world environment).
There are many dangers to what we are doing - roads resulted in noise, pollution and wars for oil as well as an expanded personal world and some very cool cars.
For us, we now have the Hitchhiker's Guide to the Galaxy in our pockets but we also have a massive increase in kids self-harming.
We need to care deeply about what we are doing, and we need to take whatever steps we can in our work to make the web a positive change.
I hope this book helps, even a bit. Please use it to make things better.
Omnichannel Content Strategist and Founder, Urbina Consulting / OmnichannelX.digital
President and Chief Strategist, Content Company https://contentcompany.biz
Content Leader, Author of The Content Advantage, Speaker https://content-science.com/
Senior Product Manager at Harvard Business Publishing
Partner at Public Digital Quote taken from: https://medium.com/iipp-blog/digital-transformation-is-a-leadership-problem-8c0c97f829ca
GatherContent is a Content Operations Platform to help teams produce effective content.
Whether redesigning a website, re-platforming a CMS, or working towards complete digital transformation, GatherContent helps teams:
With fewer revisions and faster approvals, GatherContent ensures an organisations content operations is efficient so they can put content first.
Enter your email and we'll send you the Kindle/ePub version of the book.