Rachel Lovinger: Content Modeling Innovator – Episode 109

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Google Podcasts | Spotify | Android | TuneIn | RSS

Many content professionals were first introduced to the practice of content modeling by Rachel Lovinger’s 2012 A List Apart article on the subject.

Content modeling gives teams of authors, managers, designers, and programmers a shared understanding of a content ecosystem. Before they write a single sentence or line of code, teams align on a common language that keeps their work in sync.

Content modeling accounts for everything from the authoring experience to metadata strategy to the end-user experience. It helps team visualize the content landscapes they are creating, and it serves as a conversation starter for any number of important stakeholder interactions.

We talked about:

• her content strategy and content modeling work at Publicis Sapient
• the content-modeling lessons she learned working on the content and CMS for Entertainment Weekly at Time, Inc.
• her identification at one point as “a content manager of content management systems”
• her discovery when she interviewed for her first content strategy job that she was already doing everything in the job description
• her shift from content strategy to more of a focus on content modeling
• one of the big benefits of content modeling: its ability to help you visualize the landscape of the content you want to create
• the importance of accounting for the CMS authors’ experience into your content model
• her work more than 20 years ago with a headless CMS
• her early work around organizing keywords and other metadata into controlled vocabularies
• her push for training and guidelines in many of her system implementations
• how a content model can help streamline documentation creation and author training
• how content models can serve as a conversation starter for important stakeholder interactions

Rachel’s bio

Rachel Lovinger is a Group Director of Content Strategy at Publicis Sapient in New York City. With over 20 years’ experience in online publishing, website development and content management, she’s an internationally recognized thought leader in the discipline of Content Strategy. She regularly works on public-facing and enterprise projects, developing content models, metadata strategies, and overall content strategies for clients in a wide range of industries, including automotive, publishing, medical, financial services, travel, and entertainment. Rachel is dedicated to exploring a future in which information is well-structured and well-described, and connections are more easily discovered.

Links mentioned in the interview

• Rachel’s Twitter profile
• The Nimble Report, 2010
• First Principle: Disambiguation, March 2012
• Content Modelling: A Master Skill, April 2012

Video

Here’s the video version of our conversation:

Podcast intro transcript

This is the Content Strategy Insights podcast, episode number 109. To build a good system of any kind, like a modern content system, it’s important to give everyone involved a clear picture of the system – before you start designing and engineering it. A content model gives authors, managers, designers, and programmers a shared visual understanding of a content ecosystem, before a single word or line of code is written. Rachel Lovinger was one of the first content professionals to develop and teach this important content practice.

Interview transcript

Larry:
Hi, everyone. Welcome to episode number 109 of the content strategy insights podcast. I’m really happy today to have with us Rachel Lovinger. Rachel works now at Publicis Sapient, and welcome Rachel, tell the folks a little bit more about what you do there at Publicis Sapient and how you got into content modeling.

Rachel:
Hi, Larry. Thanks for having me and sure. So I’m a Group Director of Dontent Strategy at Publicis Sapient, and I’ve been there, I guess 16 years. Worked on a number of different projects. The company has gone through several name changes since I’ve been there. So it keeps it fresh, it doesn’t feel like it’s been 16 years. And I would say earlier in my career, I did probably a wide range of content strategy type things. But then probably for the last decade or so my work has been pretty focused on doing content modeling for clients. A lot of web platform type projects. We tend to work a lot using AEM and the developers that I work with have come to rely heavily on the content modeling documentation that I help create for these projects. It’s pretty gratifying.

Larry:
Nice. And you’ve been documenting this practice as long as anybody, as near as I can tell. You wrote that famous article in A List Apart, that’s almost 10 years ago now, I think, about where you talked about content modeling , I forget the subtype, but anyhow, tell me about that article and how you came to articulate what you were doing as content modeling.

Rachel:
Sure. Well, I think it’s funny actually, before I was even a content strategist before I’d heard of content strategy or heard of content modeling, and before I was at Razorfish slash Sapient slash Publicis Sapient, the various name changes, I was working for Time Inc. For a website called Entertainment Weekly, ew.com.

Rachel:
And shortly after I started working there, I was actually an HTML developer and then front end, like template developer, but we were working very closely with the editors on the CMS and how they used the CMS. And to me, it was really important coming from this magazine heritage and using magazine content, How do we create experiences that were really sort of uniquely digital? And so shortly after I started working there, they decided to do a redesign of the site. And the designs that our designer was creating were really beautiful, but I kind of wanted to break it down into like understanding better all of the content. So we could really get a handle on how we needed to publish it, what the requirements are for publishing it.

Rachel:
And so without knowing it was a thing called content modeling, I started creating this documentation where, I started out with making kind of like very rudimentary wireframes for each of the page designs and breaking down like each thing that was on each type of page. And then for each thing that was on the page, so say there was like a homepage promo tout kind of thing, I then created a document for each one of those items and I asked all kinds of questions about it. It wasn’t only what I would think of now as a content model, but like, what is the purpose of this content? How do we want users to interact with it? How often is the content going to be refreshed? Where’s the content for this thing coming from? What are the business requirements around this? Do we need to have advertising tagged to it?

Rachel:
You know, all kinds of questions to just basically understand what is this thing and what is its relationship to the content that we were getting from the magazine, and really trying to understand, how to make this. Not just like, we’ve taken a flat magazine and plopped it on a webpage, but make it really sort of dynamic and interactive. And of course, one part of that was what is the structure of this item? What are the elements? It has a headline and a caption and an image and a body and an author and some relationship to metadata and so it captured all of those details as well.

Rachel:
And I can’t really remember when I started to think of that as content modeling or heard that there was a thing called content modeling, but at some point that evolved into, what I now think of as content modeling and became a lot more focused on the structure of the content and the metadata. And the relationships between different pieces of content and things like that.

Rachel:
I guess I have the luxury now to work with a team where other people are capturing things, like, what is the business purpose of this item? And what are the functional behaviors of this item? How do we interact with it? But at the time I was kind of like, just throwing everything I could think of into that document to help myself understand, like, what is it?

Larry:
Right. It’s almost like you were a super webmaster, because that was like a title back then the person who kind of did all this stuff, and you were doing it, but at a very, a pretty high level and with much richer content than many of the websites at that time.

Rachel:
It’s funny. I think at one point my title was content manager and then we joked because I was working a lot with content management systems. And so I was like, “Oh, I am a content manager of content management systems.” Or something like that. Like it was a very convoluted title. But yeah, that was at a point when the magazine, they had a much better handle on titles that aligned with traditional publishing titles. They didn’t really know exactly what kind of titles to give people who were working, just primarily on the digital side.

Larry:
Right. Especially if you’re coming out of time Inc. And they’re what, hundred-year publishing history, they don’t know what to yeah. And so you went from the ew.com and Time Inc. you went into the agency world, did your practice change much in that or were you still were working on kind of the same kind of projects?

Rachel:
Well, it’s funny. So that was my first role working in agency. So when I was at Time Inc. I had transitioned from working specifically on Entertainment Weekly to working in a group that kind of supported all of the different websites in a way. So we worked on different projects. So when I went in for my interview, I tried to make the case for like, “Well, you know, I haven’t worked at an agency, but I have worked in this group that was a centralized group. And essentially the magazines were our clients.” And so, it was kind of similar in that way. And that they seemed to feel like that was an acceptable, close-enough kind of experience. And I think they also, they appreciated my approach to content. As I mentioned to you before, I had not heard of content strategy when I went in for a content strategy position.

Rachel:
But when I read the job description, I was like, that sounds like exactly what I’ve been doing, which was really operating the place where technology and design and business needs meet around content. And so they’d liked that. I showed them actually those documents that I mentioned to you and they brought me on. And I think I did some of that kind of work early on, but it was also, it was probably a much wider range of things.

Rachel:
I think when you’re starting out as a content strategist, it’s helpful to be able to do whatever is needed. Obviously a lot of what content audits and content analysis, and writing things about opportunities and recommendations. And I found myself writing a script for a demo video, or doing taxonomy work, doing tone and voice guides, really kind of everything that you might imagine a content strategist might do. Probably not everything, but a wide range of things.

Rachel:
And I think over the course of my career, I started focusing more and more on doing content modeling. I had always been very interested in content structure, but I feel really strongly that having a good content model is one of the things that enables us to create a product that where we realize the design, that we make the design come to life. And I’ve talked to so many editors back when I worked at Time Inc. And then stakeholders later, who will say like, “Oh, I hate our CMS. It’s so hard to use.” And I’m like, well, your CMS isn’t inherently hard to use, it’s just not set up for what you need it to do.

Rachel:
And so I feel like asking all those questions, what is this content? What is the purpose? What do you want it to do? How often is it going to change? What kind of decisions do you need to make about it? And then using that to inform how you set up the publishing system, that’s really like, it makes or breaks people’s ability to sustain the vision that you’ve created with your product. So it’s one thing to like launch it on day one and it looks beautiful, but to be able to have something that people can continue to refresh and use and publish and update and enhance, for six months later and years later, and that’s what’s going to make it successful.

Larry:
Yeah. And the way you described that, I think you’ve articulated a lot of benefits of content modeling and what it does for you, but I’d like to back up just a little bit, and I hope you can do this because you’ve been doing this so long, and I hope you can extract yourself from all your expertise and give us like if somebody cornered you at a cocktail party and said, “Content modeling, that’s fascinating.” How would you describe it to them?

Rachel:
Well, it’s funny, I’m going to tell an adjacent story, which actually did take place at a sort of a cocktail party. It was at a conference. I met Cleve Gibbon, you may have heard of him.

Larry:
Oh yes.

Rachel:
So it was a content strategy conference and he was a CTO who worked with content management systems a lot. And I was a content strategist, and we’ve got into this very, this conversation and we were like very excited about it. And he’s like, how do we get technologists and content strategists working together more to make these things happen? And I said, I don’t know, I guess we got to talk more about content modeling and get them to do content modeling. And then we wrote a workshop together about content modeling.

Rachel:
And I can’t remember the exact timing of when we wrote the workshop and when I wrote that article, but they happened around the same time. And just started talking about it a lot more and finding other people who were talking about it a lot more. And now there are several books about it and there’s a whole bunch of people that speak about it. And it’s pretty exciting just getting more people on board with using this as a technique. And hearing the feedback from people, where people are like, “Oh, this is really going to be helpful.” I enjoyed that. So I guess I didn’t really answer your question though.

Larry:
No, but I got to say, I love that story because when you do like the archeology of content modeling, the two names that come up, are you and Cleve. And I had no idea that you had collaborated at some point, so I love how this story’s coming together. But do please define content modeling too.

Rachel:
Okay. Well, I actually almost forgot about this too, but when I first was talking about content modeling, I think there’s a sort of high fidelity and low fidelity ways you can approach it. So, you can get really detailed, but the sort of low fidelity, high level way that you could think about it is really just having an understanding of what are all the types of content we have, and how do they relate to each other.

Rachel:
And, it’s basically like any kind of modeling data modeling or other modeling, how do you visualize the system that you’re creating? And by system, I don’t necessarily mean a content management system or tools, but I mean what is the landscape of content that you’re going to want to create? So at a very high level, you know, you could say, Oh, we’re going to have reviews and we’re going to have interviews and we’re going to have photo galleries. And these things are going to relate to each other in this kind of a way.

Rachel:
And so it’s really at that level, just doing some planning to understand the landscape of content that you’re going to deal with. And maybe that includes things like, the reviews are going to have ratings, but obviously interviews are not going to have ratings. And we’re going to import ratings from other sources and merge them with our own. So we can say our reviewers said this, but users said that, and things like that. So how do you create those relationships between different sets of data and the content that you’re publishing?

Larry:
Right. But then also that’s like, and then the high fidelity part would be like the details about all that and the implementation, is that correct?

Rachel:
So the high fidelity is breaking down. Okay. Well, a review is made up of an image and a tagline and a grade and a body and a headline and et cetera, et cetera. So what are all of the kind of individual parts of that that need to be then captured in your CMS or whatever you’re using to publish your site, to publish your content, I should say, not just a site.

Larry:
Yeah. Now I’m curious, have you done much with headless CMSs or any of the new decoupled architectures?

Rachel:
It’s funny that you say that, I feel like having been in this field for a while, I’ve kind of seen a lot of things, it’s sort of the pendulum swings back and forth. So, you start out with like very headless type things, although I don’t think they called it that at the beginning of the century, but the full first serious CMS that I worked in was Vignette.

Rachel:
And Vignette had, oh, what do they call it? It was like a CDS, content deployment system, and then you had to build your own CMS. So one of the reasons actually that I got so into working with the CMS is we had built our own CMS, and the CMS was built in the same language as our templates for the website. And so what we would do is like we would see that our editors were struggling to do certain things, and we would kind of build tools for them that like sat on top of the CMS, that could help create shortcuts.

Rachel:
So, oh, you want to create a photo gallery and it’s very tedious to upload 17 images. We’re going to give you a tool that will upload 17 images all at once, instead of having to repeat that same task over and over. And so in a way, it was because we had that ability to create our own enhancements to the CMS. That was really what got me interested in, how could we structure this content to create a better experience for the authors, to make it easier for them to do the job that they need to do.

Rachel:
And to me that is very tightly integrated with the content model, because the purpose of it is to kind of express what we want to do with the design, with the process in mind that the content producers are going to have to follow to make that content happen. And so having that understanding of like where they were struggling and where they were spending a lot of time doing repetitive things, instead of like creating interesting content, we really were trying to reduce that.

Rachel:
So I started out working in, like I say, they didn’t call it a headless CMS, but it was essentially a headless CMS because we were creating our own interface for it to save the content into a relational database. And then later we started getting tools like what I tend to use a lot, our projects tend to use a lot these days is Adobe AEM, Adobe experience manager. And that is an interesting mix of, I would say like a kind of a very WYSIWYG sort of an interface and a backend that is meant to be very flexible, but the front end causes it to have this still a very like page oriented metaphor.

Rachel:
So it’s like you, you can look at it and it looks like a page, but it’s not really, but it sort of looks the page. And now that has kind of swung back the other way, where I think Adobe has probably recognized that people have a need for this more, what we’re now calling headless CMS approach. And now they’ve added features that let you sort of integrate that kind of approach with their page-oriented approach.

Rachel:
So now we’re using, we have a combination of using page templates that look like pages and then other templates that are more functioning as like a content as a service, where you’re authoring the stuff and it’s exposing it as JSON or something, and then using it in an application. But it’s funny because it sort of takes me back to like 20 years ago where we were just creating these forms, that you’re going to fill out all your stuff. And then, it merges with a template somewhere further down.

Larry:
No, that’s interesting because in some ways that experience to the content creator doesn’t look that much different. You’re filling out some web stuff. And in one case it’s almost a one-to-one correspondence with the ultimate artifact, but in the newer cases, it’s could be, show up in five different places in different things.

Larry:
I’m curious, how much you’ve done with the authoring end of it. Like having to educate content creators about, because almost everybody came from like that old publishing/journalism school where this was not how it was done. Did you have to do a lot of educating along the way?

Rachel:
Yeah, I would say what was most interesting to me when we started, when I was doing this in the early 2000’s, so our authors would write keywords for the articles and the keywords were all over the place, because it was just an empty field and you could type whatever you wanted into it. And then at some point I convinced my boss, like we really need to normalize this and create an actual metadata library and then have a controlled vocabulary of words that we can update regularly, as new movies and books and TV shows come out. And then you can tag your articles with this. And I think now, everybody’s really used to tagging things, but at the time, the editors were like, why are you giving me something else I got to do now I have to search for a word.

Rachel:
And then, we would do things like show them, this is like a big throwback, like Star Wars: Phantom Menace, they were like 20 different ways that people had written it when they typed it in as a keyword because you know, someone would call it star wars, episode one and someone else would call it, episode one with a I. And somebody else would call it Phantom menace the episode one, you know.

Rachel:
So there were all these different combinations and we were like, look, you can either have this, where it’s just keywords all over the place or we can give you a controlled vocabulary and you can tag it and you have the same thing and it’s consistent. And eventually they got used to it. But I think it was also through, people tagging things in Gmail or Facebook or other applications where people started tagging things in, and hashtags and now people were like, oh, okay, this isn’t so weird. But yeah, there was a lot of resistance to that kind of thing at first. And, go ahead.

Larry:
No, I was just going to say that, I’m trying to remember now when like Twitter came around like 2007, 2008, something like that, and that’s when sort of, I mean there had been like WordPress and other CMSs had free form tag fields before that. But that sort of like the popularization of metadata. So that made that education part of it a little easier, it sounds like. Kind of a rising tide lifts all boats kind of thing.

Rachel:
Absolutely. Yeah. And I think now it seems easier. A lot of the clients that I work with, the people that they have who are authoring content, they are hired because they have some experience with doing digital content entry, but there is still always a learning curve when we’re building new things. And so, we’re saying, okay, here’s a new piece of content that we created. So like they’re familiar with the fundamentals of creating content and publishing content in a web interface of some kind. And tagging and whatever else. But we do find especially the more complicated kind of a thing you’re creating, we give them instructions.

Rachel:
And I have worked on projects where, writing a user guide or an instruction guide, wasn’t part of the original plan. And then we handed over and then later they’re like, yeah, we actually really need some kind of guidelines for this. And I always try to push for that, if not actual training, at least some guidelines, because no matter how hard you try to make a system like that be completely self-evident and intuitive, there are going to be things that you just have to explain.

Larry:
Yeah. And everybody does things differently. So does that documentation have to be customized for each like client or project or?

Rachel:
Yeah. It has to be pretty highly tailored to the specific types of content that that client is going to be creating.

Larry:
Yeah. There’s so much in it. I’m almost afraid, in fact, I’m looking at my clock, I’m going, holy cow, we’re coming up close to time already.

Rachel:
So to bring mean back to the content modeling though, I would say, I mean, one of the great things about, one of the additional benefits of a content model is that, it’s actually pretty easy to take the content model and then pivot that into training because you’ve already captured, here are all the requirements for authoring, but in the content model, the primary audience is usually developers. You’re creating a content model as kind of a specification for the developers to know how to set it up.

Rachel:
And it’s generally pretty easy to take that and just change the point of view a little bit to explain to authors how they would then need to author that content, because it’s really kind of the same information. It’s just, here you’re setting up a CMS and now you’re using that CMS. But these are the same fields and the same requirements for what things need to be named and the same possibilities for how things can associated with each other. So writing that content model also gives you a jump start on writing a user guideline.

Larry:
I just remembered the subtitle, your article in Elizabeth part, it was a master model. And so that’s like your boiler plate or not boiler plate, but like your sort of the top level, super set of all the stuff that’s there. And you can use that to communicate with developers, authors, whoever else. Nice. Well, is there anything last, Rachel, anything that we’ve talked about that you want to elaborate on or that hasn’t come up that you want to make sure we get to?

Rachel:
That’s hard to say, there’s so many directions to go with this. I would just say I’m very happy to see how much content modeling has taken off. I think when I started doing it, I was like, I’m just doing a weird little thing that, I need to do for myself to understand how to build this, because I was a developer at that time. And so it’s been very useful. I mean, it’s been very gratifying to, especially when we were like doing the workshop and talking with people and hearing them say that how they were planning to use it and how they would find it useful.

Rachel:
And I think, one of the biggest benefits of it that we haven’t really covered is just how using content models as a way to start a conversation with the people who can help you figure out what the requirements are. To create those relationships with people and get alignment on what it is that we’re all trying to do with this product. I think that’s, and hearing people say, oh, this is going to help me. Like this becomes a tool that helps me talk with my developers. Talk with my designers about what these requirements are. I think that’s the thing that’s been most interesting to see.

Larry:
I think you saved the best for last there, because I think that is like a super high level benefit of modeling. Before we went on the air, we were talking about, I mentioned Jeff Eaton’s quote, that content modeling is really just the friends you’ve met along the way. It’s kind of in that family. Yeah. Well, thanks so much, one very last thing, Rachel, what’s the best way for folks to stay in touch with you if they want to connect online?

Rachel:
I guess, through Twitter and just @RLovinger on Twitter. And I probably don’t tweet as much as I used to, but I can always be reached there. So yeah, that’s probably good.

Larry:
Well, thanks so much. Really enjoyed the conversation.

Rachel:
Me too, Larry. Thank you.