I recently had a fascinating discussion with Marte Gråberg and Beate Sørum of Kreftforeningen – the Norwegian Cancer Society – discussing the human-centred process they have in place to manage content.
Web Editor, The Norwegian Cancer Society
Digital Fundraising Consultant
Marte: It’s great to be here.
Beate: I have to admit, I’m really annoyed now, after having read your book.
Rick: I’m sorry. I didn’t do it on purpose. I promise.
Beate: It’s not you.
Marte: It’s the developers we’re annoyed with. You’ve exposed their secrets.
Beate: We were both nodding a lot during the first chapters of your book. It sounded so familiar.
Actually, I’m really glad you’re out there talking about these problems. As you say, the developers think in terms of code – in terms of the specific technical problem. They don’t understand how the people using the system think. So they don’t recognise the real problems.
Rick: I could rant for hours about that. But we’re here to talk about what you’ve been doing at The Norwegian Cancer Society with regards the author experience. Can you talk me through your set-up, your experiences, what works and where the challenges are…?
Beate: Sure. Our case is of how we’ve made our author model work in spite of the CMS.
Rick: Let’s face it, that’s what everyone needs to do these days.
Beate: That’s true.
Our system [name withheld to protect the guilty] is much better than what we had before. But it still does a lot of things you outline in the book, like arrange everything as a page. When I want to make a list, I have to make a billion pages for it!
Beate: And each type of list does it in a different way.
Marte: Yeah. It doesn’t make sense for the author to think that way. I want to add a name to a list: why do I have to go through the whole process of creating and mapping a page for that?
Beate: And it takes a lot of time.
Rick: I can imagine.
Beate: But let’s start at the beginning. Marte, maybe you can talk through our author model; how the editorial board works.
Marte: Sure. Our web site is owned by a group of us. It’s not just me. It’s not distributed content generation. As a team – a central editorial board – we’re jointly responsible for the content.
Beate: We try to create a human web of knowledge.
Marte: We’re not just posting what others give us. We’re not just rewriting what’s already there. We’re keeping track of everything. Between us, we remember what’s there. We figure out where new content should go. We detect the patterns so things link up nicely.
Beate: And we make sure the content gets reviewed regularly; every six months or so. A rolling programme.
Marte: We have to take control of that ourselves. There are no automatic reminders.
Rick: How many of you are there on this editorial board?
Marte: There are ten people working with the content directly. Seven meet every week for two hours. It’s a lot of people, each with a different background: someone from research; someone from the telephone helpline; someone from fundraising…
Beate: We represent the different disciplines of the cancer society.
The key is that everyone on that board must spend a minimum 25% of their time working on the web. The cancer nurses who maintain the most important content have 50% of their positions dedicated to working on the web.
That’s how we’re able to maintain control. Everyone invests so much time that we don’t have to waste time remembering how things are done. Or remembering how the different pieces of content go together.
Rick: I like that 25% rule. It keeps everyone involved. In so many organisations, maintaining the web is an afterthought that no one ever has time for.
Marte: Sometimes, it’s difficult to maintain. We set this up two years ago. We still have to reiterate the need.
Beate: Yeah. You have to keep reminding the leaders.
Marte: Keep the managers invested; keep reminding people that our weekly editorial board meeting is mandatory.
Beate: It’s human nature. People are excited in the beginning. They like to see their content go live. But keeping the flow going is difficult.
Rick: That reminds me of a behaviour I see a lot on the web: the project approach.
You have a project to get something onto the web. But no one thinks of the web as business as usual; no one thinks about maintenance.
Marte: Yeah, that’s true.
That’s what we’re trying to solve with this governance model. We don’t want things to go back to the way they were once the project is done. This model is our attempt to avoid silos: it stops people creating their own content in isolation. Everyone knows what’s going on; no one can create content for their own section without considering how it relates to everyone else.
Rick: That’s great.
Marte: We still have people trying to do their own thing; but because we’re collaborating, we find out.
Rick: How do these meetings work? What’s the process for discussing new content?
Marte: Nothing gets published unless you take it to the editorial board. There you have to answer five questions:
- Who is the target audience?
- What message do you want to get to this audience?
- What will you achieve by getting this message to this audience?
- Does this message help the audience?
Beate: The last isn’t so much a question:
- Describe the user scenario. How do they find and interact with the message?
Marte: Yeah. Did they get here as a result of the search?
Beate: How will they use the content?
And we ask them to explain why the web is best channels of this content. More often than not they’re still thinking: “We did this thing, we have to publicise it on the Internet.”
Marte: And we will challenge them. Maybe you should just go tell someone. Or tweet it. Or put it in a folder for later.
Rick: That’s a good list. It ensures that content is only published if it can be justified. But what about end-of-life? Do you ask about the scenario when the content will have done its job? What’s the scenario in which we remove this content?
Beate: Oh, that’s a good one.
Rick: Or at least review it.
Marte: So far we’ve used the questions to disincline people from sending us content that doesn’t belong on the web site.
Beate: One of the key things in our model is maintaining the new page. We don’t focus on news. Everything we do goes into persistent content of some kind. That means we’re always working on our existing content. Of course, we are adding to it when we see more is needed, but we don’t get that flow of very obsolete content.
Rick: I like that. No dumping of news.
Beate: Oh, we have a news section. But it’s a very small section, and we have rules for cleaning it out.
Marte: We don’t archive news.
Beate: Our site is very much a constantly evolving and improving pool of content. We don’t need new content; we need relevant content. What was relevant yesterday will be relevant tomorrow. The challenges for those facing, dealing with and fighting cancer don’t change every day. We don’t need new content for its own sake.
Rick: That attitude is a breath of fresh air.
Beate: Sometimes, based on our organisational focus – our ongoing projects – we’ll realise that there are gaps in the content. Recently, we added a fair amount of content about death. Even though survival rates are up, there are still a lot of cancer-related deaths. We hadn’t properly addressed that subject, so we needed new material.
The cancer nurses worked on that. They kept the editorial board informed of the content they were creating. And the board made suggestions for titles, and types of content; the way things should be phrased. There’s a lot of collaboration.
Marte: Yeah. And we don’t leave it to the person who knows the field. We make sure those who don’t specialise in the subject read it, and can tweak it before it goes out.
Beate: They pick up on the jargon. They make sure others can understand the subject.
So, what I’m hearing is that you’ve implemented the human system, based on real needs. You’re not letting the technology lead. But unfortunately, the technology isn’t helping, either.
Rick: How much time and effort are you putting in to this? If you had the budget and someone to implement it, how much effort could be offloaded to supportive technology?
Marte: Oh, that’s a difficult question.
Beate: Right now, I think ten of those 25%s go into setting up the content in the CMS. We could save a lot of time if the CMS helped us with that, rather than giving us hoops to jump through. But how much, I dunno…
At the moment, even though the technology isn’t helping, the hardest part, as Marte said, is maintaining the human culture: keeping people invested.
Marte: Motivating people.
Beate: We spend a great deal of time doing that. Even if the technology were easier, it would still be an issue.
Marte: Maybe, if the CMS could help us know where to focus our effort, we wouldn’t have to spend so much time on the human motivation side. As you mention several times, the unhelpful environment saps the authors’ engagement and focus.
Beate: Yeah. There’s a lot of work we have to do manually. If the system integrated, if the data from Google Analytics were coupled with the pages in the CMS, we could get warnings when contented isn’t performing well. We could see changes. It would be great if the system would show us these little red flags every now and then.
Marte: Also, if we decide to change a term or phrase that we use, it would be great if the system could tell us where the instances are that we need to change.
Or where figures need to be updated, like the cancer numbers from 2012.
Beate: Some of those are quite obscure. Of course we can easily update the places where we talk about statistics for the various forms of cancer. But those figures may be mentioned on a page telling people where their donations go. It’s hard keeping those updated.
It can be really hard managing the content we have when we have to create all these pages that aren’t really pages.
Marte: There’s no overview of all those bits. So that’s where the confusion sets in. We find a lot of things by accident more than by architecture.
Beate: Another problem is that we become very much dependent on the people involved. We’ve seen a bit of that when people leave. The new people coming into the group don’t have the history from the development process. They haven’t been part of setting the rules.
Rick: And that was going to be my next question.
How do you on-board new people, and what are the challenges with it?
Marte: The challenge is getting the history of the strategy, the philosophy, across before they’ve been here too long. You have to get them on board with the process before others start asking them to publish content.
Beate: Yeah, you need to get them loyal to the strategy early on.
Also, getting them to actually invest the amount of time that they should can be challenging. They might be told by their manager that they’re going to this weekly meeting. But they don’t understand that this means 25% of their work on an everyday basis. It’s not just the board meeting.
Our governance culture isn’t the norm. It takes time to become a good content curator. People aren’t used to that.
Also, our writing process involves the board member aggregating content and then writing it in a form that suits the web. It can be hard to tell colleagues to just provide bullet points. Or to treat whatever they provide is a draft. People feel that they’re telling colleagues that what they provided isn’t good enough.
Beate: We have to give them the confidence to know that that’s not what you’re actually saying; it just feels that way. What they’re doing is improving the content to be fit for the web, because that is their job.
Do you give them special writing training, to support this?
Marte: Yes, we do. We have writing training every six months. Everyone on the board attends every time, because we all need to be reminded how to communicate effectively.
Unfortunately, the people who started working here in the summer haven’t had the proper training yet. Our next one’s in January.
Beate: But new people on the board work very closely with Marte on the first couple of pieces. So in that way, they get informal writing training immediately. And of course, they have our style guide.
And as Marte said, we do this training every six months as a group. Because it’s easy to fall back to old habits.
Marte: We need the reminders.
Beate: Keeping the lingo out. Keeping the language active. Saying “we” instead of “the cancer society.” Sticking to our tone of voice. It requires constant practice, even by the experienced people in the group.
Marte: We have to write about people, instead of at people. Especially when we’re talking about something as personal as cancer. It feels harder to write “You might experience this,” rather than “A patient might experience this.” But the content is much better for the user if we can get over our own uncomfortableness.
I think the new people also see that those of us who’ve been doing this for years still get it wrong. That helps. I still make the same kind of mistakes as a person who doesn’t write that often.
Rick: Because that’s not how we speak. How we speak, how we think: it’s a mess.
Beate: Exactly. Your first draft is going to be all over the place. That’s just how the brain works. Which is why we have to keep forcing ourselves to rewrite the content several times. Even if you have been writing for six years, you still need to edit.
Rick: It sounds like you’ve got a system that works well, even if the technology isn’t helping you yet. Is it a complete system, or is there still ongoing technical development?
Marte: We’ve still got a lot of satellite systems that haven’t been migrated to our central platform. So yes, there’s still ongoing development.
Beate: But when we bring our satellites onto the main platform, we try to make sure that everything is reusable across the system. We don’t want to end up with things that can’t talk to each other. We don’t want duplicate functionality. We certainly don’t want to duplicate content.
This means we can maintain a consistent style across our campaigns. Our campaigns can reuse content from the main site. A Pink Ribbon campaign is using content from the main breast cancer page.
Also, if a form is converting badly, we can improve it, and that improvement is reused throughout the system. It’s not just for one campaign.
Marte: It also helps maintain consistency through the years when new marketing agencies come in with different ideas.
Marte: We have to tweak things all the time, but we have the basics.
Beate: And of course, there are the constant bug fixes. One of the main things on our to-do list, if we ever get to it, is to fix the inconsistencies in the CMS. We have similar processes that are implemented in different ways in the backend. That makes it unpredictable for the authors.
Marte: That’s always last on the list.
Beate: It is. There’s always some other priority.
Rick: Well, of course. Authors are just authors. They’re not important.
Marte: We can live with it. We can work around it.
Rick: That’s always a tough one. It’s hard to get those controlling the budget to understand that improving the author experience benefits the business, both financially and from a workflow perspective, more than it does the authors themselves.
When you’re moving functionality in from those old satellite systems, what is your process? How do you ensure reuse?
Beate: We used to leave things to the developers. But it never worked the way we expected. It didn’t fit our workflow; the developers don’t understand how we do things. We learned from that.
We started demanding sketches of how things would be done in the back-end. Just as we do for the front end. That point in your book really resonated: everyone is so focused on the end user, they don’t spare a thought for how it’s going to be implemented in the back end.
Beate: But we now expect that attention from our developers.
Marte: It takes a lot of knowledge on the part of the client to be able to make those kinds of demands. You need to know that it’s possible for them to adapt these things. If you don’t, you’re going to take their word for it when they are this is how it’s supposed to be.
Rick: Exactly. Developers will generally try to do as little work as possible. They’ll try to do things the way they always have, because it’s been good enough before.
We were actually quite surprised. The developers don’t understand the existing system. They don’t see that this new functionality is very similar to something that already exists. We have to constantly remind them. We have to show them when something new aligns with something we already have, and then insist on the two working the same way.
Beate: They’re probably working in silos. So the individual developer won’t have the complete overview of our system. Which leads to them thinking in similar but not identical ways.
Marte: We have to be thorough when we ask for something. We have to think ahead, consider how we might want to use it in future, not just deal with the current situation.
Beate: We have to constantly push the developers to make whichever new parts we make as general as possible. And to make sure say that the design isn’t hard coded in, but it’s decided by the CSS we choose.
Rick: I suspect those problems may be based on how your implementation agency works. You never get the same developer twice. With each new bit of work, the person you’re dealing with doesn’t know any of the history.
Beate: That’s why you almost always need a person who can see both the technical side, and the author side, to keep challenging both. To balance the general and the specific. To question whether an approach is really the best way to do something.
Rick: I would say they need to speak the business language too. There are a lot of demands to balance.
Beate: That’s true.
Rick: And I think that wraps it up for now. Thank you very much for joining me.
Marte: Thank you for inviting us. It’s been a pleasure.