(upbeat music) - So, what do you think of when I say the word content? For most of us, our thoughts immediately turn to the words. After all, isn't that what content is all about? It's the stuff that fills the lorem ipsum.
It's the ingredients you put into your wireframe, so they make more sense.
It's what gets the message across.
And as a content professional, that's been one of the biggest challenges that we've had. Everyone's been focused on the words.
And unfortunately, that often means that the words and content have come at the end of a project.
It's come after everything else has been looked at. It's come after the user research has happened. It's come after the customer journeys have been mapped. It's come after the design.
It's come after even the technology assessments. So, happily we're kind of changing our approach to content. We're maturing a little bit in that space.
We are thinking a little bit more about what our customers, what our clients, what our users, that terrible word, may need. But unfortunately still, there's very much the focus on the words, the editorial side of content strategy. So, today I'm actually going to touch on some of the other elements of content strategy that you might want to have in your UX, or your design toolkit, that will also help you produce a really valuable, and really great user experience, or a product, or a service.
So, I'm going to touch on empathy.
So not just deciding what content to write, but how do you actually know if the content you're producing is empathetic? I'm gonna touch on content systems, because without the infrastructure in place to store and display and structure your content, how are you actually going to help those people do the things that they want with your content? And I'm also going to just touch on teams, because behind all of this, there are people creating this content, and if you don't enable them and empower them to do a good job, well then, that's when your beautiful shiny new product quickly biodegrades when it gets handed over to the business.
So first off, who's seen this little red book? The little red bible of content strategy.
There's a few content people in here in this. So this book came out a number of years ago now, by Kristina Halvorson and Melissa Rach.
And it was kind of the first book that looked at content strategy as a discipline, and it broke it down into a couple of different aspects that supported a core strategy.
And those were substance, so what content needed to be created? Structure, so how was it structured? What metadata was required? How was navigation and things like that going to work? It also looked at the process, the people and workflow required for content as well. So, Kristina actually spoke at South by Southwest a couple of months back, and she's talking about a slightly different approach to looking at content strategy.
So she's divided into two different elements. There's content design, which seems to be a big buzzword at the moment, which is great.
So content design takes a look at that editorial side of content, but then also the experience of content.
So how do we actually make sure that people are experiencing our content in the way that we want, and the way that supports their needs and goals? And then also system design.
So, what structure and what process are needed to create these amazing experiences we want with content. And this new look at content kind of fits with what I wanna touch about today as well. So, the first thing is empathetic content.
How do we know when we're actually creating content that's empathetic for our customers and our users? Now, we all know that empathy is about putting ourselves in other peoples' shoes.
And from a content point of view, I think that that takes in three kind of elements. The first one is creating content in the right tone. So content is a deeply emotional thing when you think about it.
You can be deeply feeling a lot of emotions when you're actually interacting with the content. You might be really happy, you might be excited, you might be terrified, you might be confused, you might be feeling all of these things.
And content can actually make you feel things as well. It can make you feel excited, it can make you feel terrified, it can make you feel confident or not so much. So choosing the right tone and understanding what tone is appropriate for the context that you're trying to produce as content is very important. The other aspect is, and it's gonna sound like a real duh, okay, but you gotta make it readable, right? People have to actually be able to decode that content of what you're producing.
And when we read, there's actually a two part process in play.
The first part is decoding the words, so actually recognising that this word for table is a table. But the second part of that is about comprehension. And this is often where we kind of fall down a little bit, because we assume because people know and recognise the word table, that they may understand table as a word in different contexts.
And they may not.
They might not realise that that table doesn't mean the table of data that they're reading about.
So, when we actually look at empathetic content, we have to look at this combination of things to make sure that what we're producing does have empathy for the people we're writing it for. So this is a real example, taken a few years ago now, thankfully, of an insurance letter.
So, you would get this letter if you had applied for, or made a claim against a life insurance policy. So, by the very nature of it being a life insurance policy, someone close to you has probably died.
This letter is telling you that they've decided not to pay the life insurance policy. So, quite terrible.
If you look at it, the tone, do you think the tone's appropriate for such a potentially emotionally fragile state? Probably not.
It's very cold and impersonal.
It wouldn't make you feel better or confident, or anything at all, when you actually look at the words themselves. So, probably for most adults of a reasonable level of education, there aren't any words there that you wouldn't be able to recognise as a thing. Right? There's nothing overly hard there.
But when you actually break it down, and looking at the context of the words, and the comprehension around that, even though you would recognise the word avoided, would you know what that meant in this particular context? Perhaps not.
If you were not in insurance, if you were the average person on the street who has never had to make any sort of insurance claim before, avoided might be something that you don't actually know the meaning of. Same with breach.
Breach is a word, you might have heard it before, but do you understand the context as this is being used? Duty of disclosure, and benefits.
So when you break it down like that, overall, this content is, it doesn't have an ounce of empathy in it whatsoever. And these are the sort of things that we as content professionals, as UX professionals, as design professionals, can work together and avoid.
So, how do you start? You start where we all start.
You start by embedding some content questions in your user research.
So, whether that's with your contextual inquiries, and talking with people about how they're using content, how they're feeling when they're reading or interacting with a piece of content, because it doesn't have to just be words.
It might be video, it might be audio, it might be whatever.
So, understand how they're feeling.
Are they kind of a bit nervous? Are they using this content because it might be an application form for something they really care about, or that they really wanna get right? So, they're sort of a bit apprehensive.
You can even print out a piece of content, and get them to circle the words that make them feel more or less confident about what they're going to do after the step, and whether they understand certain things. So as you map these out, whether it's your interviews, whether it's your service design, whether it's your customer journey mapping, embed some of these content questions in there, and really get a good sense of how people are feeling when they're actually using this content.
I've used before a simple worksheet like this. It's actually really good, not so much for the end user, but for the internal stakeholders who have never had to think about how people use their content before in their lives. And just map it out, as you go through different content types.
Map out how people might be using that content, and how they're feeling.
Because you'll have different use cases across the organisation.
Your web content might be quite different from your customer service content, which might be different how you want to do email, which might be different how you want to do your marketing copy, and might be completely different again for your chatbot. So, map out your different content types, and get a really good understanding for how people are going to be using that.
Now, the next thing is to test the readability. Now, a big caveat, and I know the content people here are going ah, readability scores.
They're not perfect, but they do point out the real red flags, right? They point out the really complex sentences. They often point out better word choice.
This one here, the Hemingway app, it's an in-browser tool.
So you cut and paste content, and it goes through all those different highlights, and say, hey, this sentence is really complex. It's a bit too long.
Consider shortening it.
This word might be a better word choice in this sort of situation.
And then it generates a score.
So it will generate a grade level rating score, and for a lot of projects that I've worked on, it's like a grade five or six reading level that you're trying to aim for.
They're not perfect. You can put gobbledygook in here and it will give you a good rating score, but it's a bit of a sanity check.
The next thing is, and this is the bit that we often forget about, is do they actually understand? So what if they can read those words.
Do they actually understand what they mean? And one of the tools that you can use to test this is a cloze test.
Again, not perfect.
But basically what you do, and everyone's picking on Facebook, so I did as well. So this is the Facebook privacy statement, a couple paragraphs long.
You take a few paragraphs of your content.
You remove every fifth or sixth word.
Doesn't matter if some of those words are and, or the, or little ones.
You don't have to pick out all the keywords. And then you get people to fill it he blanks. And this is about understanding this kind of collection of content.
Do they understand the context? Do they understand these words altogether? And, what you're trying to aim for is above 60% or so success rate.
So, below that, you've got something wrong. Above that, it's actually quite hard to get 60% or higher, but you're usually heading in the right direction. They understand that collection of words.
I haven't actually used this before, but someone tweeted about it the other day. I was like, oh, that's really great.
So, it's kind of adding this extra layer over the top of, it might be readable, people might understand it, but are there other kind of inherent biases there? Gender, race, religion.
Other inflammatory things in our content that we don't really realise? Because we all design things and see things with our own experiences and lenses, and sometimes we miss stuff out.
And so this was just a really cool concept that it flags the other stuff that we might not think about.
And then of course, you need to let your content producers know how you create this content with empathy.
And the perfect place for that is in a style guide, which is part of your content system, which is my next point.
So content systems.
We've had so many people touch on design systems, and as Sarah mentioned this morning, a design system is there to scale a design practise. To pull together all of these reusable components, with a set of standards and guides so that you can produce things that are consistent, but then also you get more effective and efficient with how you can build things.
And content's the same, right? We need to make sure that there's consistent information out there.
And as we scale up, we realise that content isn't just a word on the page. We have content in apps, in Wikis, in intranets, in CRM's, in chatbots, and everywhere. I'm working for Westfield at the moment, so we have content in digital directories.
We have parking content.
We have everything.
We have this ecosystem of content.
But, the end user doesn't care about that.
They don't care about this mess behind the scenes. They wanna have consistent information.
They wanna be able to trust that information. They wanna have the same information, so they're not calling your call centre, because they think they're gonna get a better service. So, a content system is looking at that infrastructure needed to be able to provide this information.
And then breaking it down further, it's not just identifying where, in this sort of breadth of the ecosystem everything fits. It's also looking at what are the relationships between these bits of content? How do we want these little attributes to fit together, to talk to each other, to be consistent across schemes? So one of the first places that you start, is looking at a content model.
And as Sarah, apart from her wonderful books on ethics and designing for real life, there's also another one about structured content, which is also pretty much a fantastic book if you are interested in the space.
And it's looking at, okay, we have all of this stuff. In order to make it sharable, to make it omnichannel, to make it filterable and searchable, and all of these things that we wanna do with it, we really have to break it down into these smaller pieces that we can model around. And you start by looking at those different content types. So, a couple years back I did a project for a magazine, and they had this recipe database, and it's the perfect example of doing structured content, and I was very lucky that I had the opportunity to work on it.
So you look at a recipe, right? And you go, yeah, recipe, that's got some stuff. It's got a title.
It's got a image.
Some yummy stuff.
Some ingredients.
Some steps to make it.
Pretty straightforward.
And then you actually break it down, and you go, hey, wait a second.
We can actually make this much more structured. We can look at not just lists of ingredients, but quantities.
We might want to build a shopping list out of this, so we need to break it down into those individual little molecules that can make that happen.
We also might wanna be able to let people know whether it's a dinner or a lunch. If it's gluten free, or if it sort of fulfils some other need.
How many servings does it have? How long is it gonna take you to make? And all of these little bits of the information, you start breaking down, and building out a system that is going to hold your content there.
And this is part of that content system.
As you look across everything that you're producing, you can start standardising it, and identify the metadata that goes attached to it. And this is how you can, it doesn't matter. It's agnostic to any display, or how people are gonna see it, or design.
It can be used anywhere.
The other thing you may have noticed in there, in the little recipes, are tags.
And everyone's talking about tagged content. Tags are great.
Tags are great, but you also need a really robust taxonomy driving it behind the scenes. And this is another place that, the intersection of content strategy, and UX, and design, and dev, it's a really good space to collaborate, because we all have these embedded languages of how we end up label things, of how we categorise things.
The languages that we use.
And this is a really good starting point to develop a taxonomy that can be shared across different systems.
And it's interesting actually, your presentation Sarah about showing the design system at Adobe.
This can also feed into things like calls to action. How do we actually label things to be consistent? What do they mean? How do we make all of this come together and fit together, and make sure that people are sharing these different ways? So, in summary with content systems, it can cover a lot of things.
It is closely related to design systems.
All of the common attributes, common components, labelling, that can all be part of a content system. But we also care about metadata.
We care about identifying those different content types that we have, and how they fit together, their relationships between them.
We care about content prioritisation.
So even when you do have all of these modules that you might sort of Lego brick together, what is still important? How do you actually understand what should be prioritised, perhaps in responsive, or on an app, or with a chatbot? So, that's something really important to have in the content system as well.
Taxonomy and tagging.
And finally, the author experience in the content management system.
Because again, there are people creating this content, mostly.
And we have to enable them to make smart decisions about how that content needs to be created. Which brings me to my final point, about teams. Because, content really is easy.
It's people that's the hard work, right? People are messy.
People care.
Content is so personal.
Even when you go into a project where the content's been a complete mess, you have to really realise at some point in time, someone has taken the energy, the time out of their day, to actually create that content.
And nobody goes to work to do a bad job.
Unless you're a sociopath, but that's okay. But, most of us, we wanna do a good job.
We wanna be recognised for positive things that we do. So, if the content has been really bad, or anything like that, something in this system of support has broken, to be able to create that content. So teams are super, super, super important. What you need to cover in team stuff? So, keep an eye out for it.
If you've got a big digital transformation project, what are the implications for the roles and responsibilities required then to take that forward, and to make sure it's a robust, sustainable framework in the future? Do you have new roles that you need to define? Have you identified who's going to be the custodian of some of these things? Who does make the decisions around keeping the taxonomy up to date? Who makes decisions around navigation, style guide, all of that sort of stuff? How do we actually make sure that the right people are making the right decisions? We also have approvals and workflows.
So, as things change, as things evolve, as new decisions have to be made, is it a very clear process that that can happen? A lot of projects that I work on, for some people, people love approval workflows. They're like, oh yeah, this person can do that, and they can ...
We can loop back, and they can review this, and they can tick this, and the CMS will publish it, and it will be awesome.
But quite often that's an underlying problem in why things have got so messy at the moment, because you have approval bottlenecks.
People then just circumnavigate the whole process to get things live, and everything goes out the window. So how can you actually have workflows and approval that are efficient, effective, focus on the important stuff, and let the other stuff run free and be much more quick and easy to do? Because if it's quick and easy to do, people would do it.
They won't look for something else, and a way around it.
Training and skill development is really important right now.
I know, myself, trying to keep on top of everything that is changing at the moment is really, really difficult.
So how do you equip your teams to understand the implications of conversational design? How do you get them to understand the systems? How do you really make them feel confident in the way that they do their work? So, understanding the skills and training required. Same with recruitment and team structure.
Do you really need a UX writer? Do you need a service designer? Do you need a content strategist, or is that content strategist role merged and mishmashed a bit together with some of these other roles.
So have those discussions, and don't be afraid to talk to HR about it, because it might mean some changes to position descriptions, and all that fun stuff. And then finally, a community of practise, which is probably one of the most important things ever. One of the things that I've seen in recent projects is this real challenge between an agile project team, that have been working, working, working, delivering, delivering, delivering, and then it's done. The initial site's up and running, and then content gets handed back over to business as usual, and it's usually in a team that has nothing to do with agile.
So they've had all of the benefits, and all of the expectations around this kind of test and learn, and iterations, and everything like that, and they get chucked back into an environment that just doesn't support it.
So how do you actually equip people to take the best of agile, and actually use it in day to day? And from a content point of view, it's aligning a lot of those, that lifecycle, to the content lifecycle, and just making sure people are equipped to be able to keep on top of things. It's not just a set and forget, things are live, check it in 12 months time. It's like a continual improvement, and it's breaking things down into how you actually do that in a business as usual environment, which is super important.
So, in summary, I'm confident that all of you already knew that content strategy is a lot about editorial stuff. But for your next team, for your next project, I hope also that you think about empathy, and you think about how you can actually create test, retest, that your content is empathetic, and is suiting your end user.
I want you to think about content systems.
I want you to think about how you build that sustainable framework and infrastructure, so the end user can use their content in the way that they want to do use it.
So they can filter and search, and they can use it across systems, across channels. And finally, I want you to think about teams. Because people are at the heart of what we do. People are the people- people are the people.
People are the ones who are using the content. People are the ones that are creating the content. So let's make sure that they're equipped and able to do that in the best way, because that is better UX for everyone.
Thank you.
(applause) (upbeat music)
