This video is the twentieth in our Content Strategy Advent Calendar series.
Today, Rachel Lovinger talks to us about the value of content modelling, not just from the perspective of the results of content modelling, but rather the process, the collaboration and the conversations that you have in order to create that content model.
Hi. I’m Rachel and some of you may know I’m really into content modelling. I’ve done a lot of work with it and speaking about it and writing about it over the years. It’s an important part of creating structured content. But today I want to talk about how it’s not just the artefacts, the documentation the results from content modelling, what’s really valuable about it is the process, the collaboration and the conversations that you have in order to create that content model.
So it might start with, for example, you take a look at some designs and you think you might start documenting and then you realise you have a lot of questions. Which of this content is static? Which is dynamic? Which of it is going to be updated frequently. Which of it is relatively stable? What’s behind those tabs? Is it more of the same of what you see or is it different stuff behind the tabs?
All of these questions that you start to ask yourself, you should then have a conversation with your designers and ask them what the intention was and if they haven’t figured it out already, help them make those decisions and work together on making those decisions. At the same time you might also find yourself working with them to, if they’re making a system, a structured modular system, instead of designing like one-off pages then you’re going to help them sort of normalise across the different designs so when you see things and you can see common patterns emerging you help encourage them to create consistency in their designs.
Once you’ve got a really good sense of that, the intentions behind the design, then you can sit down with people that are actually going to be developing and you start having conversations with them. You tell them about what the decisions are that need to be made. You tell them about the intentions behind the designs. You can ask them questions about the best way to implement something that’s really complicated. And you give them a chance to ask their questions, so that you can get answers for them, well in advance of them sitting down and committing things to code.
Then the third set of conversations, or they can be interwoven with the others, is the conversation that you want to have with your actual content creators. So these are the people who are going to be using the system that’s created and you can ask them questions when you’re deciding between multiple ways of doing something. You can validate some of your assumptions about what their content priorities and needs are, and you can basically get their input and involvement in deciding how to implement this in a way that’s going to be supportable and maintainable by them.
One of the things that I see that comes up very frequently, for example, is the question of how much of something should be automated verses how much control do authors need to have. So let’s take a simple example. Say you’ve got a page that has a list of other pages on it and you can either, you’re trying to decide whether you want to have the authors just select those articles and then automatically pull the titles in to create the list, or whether you want to make your authors write those headlines again, or those page titles in the context of the list.
So one of those methods obviously is a lot easier to maintain and the other one takes more effort but it gives them more control over what they want to say in that context. But the decision of which direction to go is going to have a lot of impact on the day-to-day lives of those authors, of those content creators. So giving them a chance to weigh-in on what’s a higher priority for them, or if they tell you they really need to do both, then maybe you have some kind of hybrid mechanism that by default pulls in those titles but gives them the ability to override the titles when needed.
You can come to those sort of compromises, but you can really only do that if you know what their needs and priorities are. So having all of these conversations in the course of creating that content model is what really ensures that in the end you come up with an approach to structured content that supports all of the design intentions and also is maintainable by the people that will actually be creating this content.
So go forward and have discussions with your team. Thanks.
Rachel Lovinger has worked in online publishing, website development, and content management for 17 years, with various ambiguous job titles. She’s now a Content Strategy Director at Razorfish in New York City, where she’s been part of the Content Strategy team for over 10 years. And she wrote the content model for the new Razorfish.com site.
Rachel works on digital projects for clients, developing content models, metadata strategies, and overall content strategies. She’s dedicated to exploring a future in which information is well-structured and well-described, and connections are more easily discovered.
In 2010, Rachel published Nimble: A Razorfish Report on Publishing in the Digital Age, about the challenges and opportunities facing traditional publishers as they move into the digital realm. She’s also written numerous articles and given presentations all over the world on content strategy, content modelling, metadata, and disambiguation.