Greg Dunlap: Designing Content Authoring Experiences – Episode 210

Podcast: Play in new window | Download

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

Experience design for readers of online content gets a lot of attention. The authors who create the content and get it ready for publication aren’t as well served.

In his new book, Designing Content Authoring Experiences, Greg Dunlap addresses this situation, showing content-system creators how to design better interfaces, streamline workflows, and otherwise improve the lives of content authors and managers.

We talked about:

• his 20-year history as a CMS expert and the launch of his new book, “Designing Content Authoring Experiences”
• the huge gap between the needs of CMS authors and the attention paid to them in CMSs and their implementation
• how he includes content author needs in his content strategy and CMS implementation processes and workflows
• the organizational dynamics that typically lead to the lack of consideration for author needs
• how a good authoring experience supports any number of business goals: better SEO, more efficient operations, better content, better content discoverability, etc.
• how to balance conflicting needs for structure and flexibility in content operations
• the importance of understanding and accounting for the differences between content creation and content publication
• possible issues that can arise from using collaborative authoring functions in CMS workflows
• the ever-evolving of authoring tools and practices in decoupled architectures
• the hazards of using page builders in content authoring
• how he tries to keep structured content top of mind in organizations
• some of the criteria he uses when evaluating content authoring projects: the org’s content maturity, its size, the technical skills of the system users, etc.

Greg’s bio

Greg Dunlap got started in content management in the early 2000s, building custom systems for small clients. In 2006 at the Seattle Times Company, Greg got involved in the Drupal community, eventually leading one of the eight core initiatives for Drupal 8. Since then he has focused on building large-scale publishing systems for clients around the world. Greg makes his home in rural Washington with his wife Nicole and a small menagerie of animal friends. In his spare time, Greg is an internationally ranked pinball player and loud-music concert goer.

Connect with Greg online

• LinkedIn
• Bluesky

Resources mentioned in this episode

• AuthoringExperience.com
• Authors are also users – a new book on designing content authoring experiences (review)

Video

Here’s the video version of our conversation:

Podcast intro transcript

This is the Content Strategy Insights podcast, episode number 210. Five years ago at the Confab content strategy conference a speaker asked the audience of seven hundred to raise their hand if they loved their content management system. One hand went up. Greg Dunlap was the only person in the room with close ties to the CMS world. The other six hundred and ninety-nine were professionals routinely forced to use content systems that had failed to consider their needs. Greg’s new book, Designing Content Authoring Experiences, aims to fix that oversight.

Interview transcript

Larry:
Hi everyone. Welcome to episode number 210 of the Content Strategy Insights podcast. I’m really delighted today to welcome back to the show, Greg Dunlap. He was on, I can’t even remember how many episodes ago talking about this same subject, but we’re going to get deeper into it today. Greg is currently the director of content strategy at Bixal, a consultancy/agency, and he’s also the author and the reason he’s here today of the new book, Designing Content Authoring Experiences. So welcome Greg. Tell the folks a little bit more about what you’re up to these days.

Greg:
Thanks, Larry. As you said, I’m a Director of Content Strategy at Bixal. We are a consulting company that focuses on work in the federal government space. I’ve been bouncing around in the CMS world for the last 15, 20 years, and one of the things that’s been something that’s interested me since I got started was not just the experience of the people who use the website on the front end that we work for, but the people who are doing the authoring experience on the back end.

Greg:
This started for me when I was working at The Seattle Times and we did a big CMS rollout and one of the people in the editorial team came to me and said, “Where is this piece of functionality that we used to have and we don’t have anymore?” I realized that the reason why we didn’t have it anymore is because nobody had ever asked the people who use the CMS every day what they do with it. We had done this gigantic rollout with everybody involved except for them, and it set a light bulb off in my head about how these people are often marginalized in the CMS development process. Nobody thinks about them. We can just dump our product on their plate and they can just use it without any consulting. That sparked this whole idea in my head, and it’s something that I’ve been bringing into my work a lot for the last 10 years and eventually led to this book being written.

Larry:
You’re reminding me. I think I met you about a year or so before this, but at the Confab, I think it was in 2020 [actually 2019]. Laura, what’s her last name [Laura Robertson] from England, did that great talk.

Greg:
Yes.

Larry:
She asked, and this is etched in my memory, a room full of 700 people, and I’m sitting over to one side and she asked, “Hey, who in this room loves their CMS?” I look around, one person stood up and it was you because everybody else…

Greg:
I tell that story in the beginning of the book.

Larry:
Oh, good. Because that’s the best story ever, but it also speaks to that was a room full of the people you were just talking about.

Greg:
Yeah, exactly.

Larry:
The people who were forced to use these systems. The need was clear for something like this. The other thing you say early in the book is that this is a lot of work. This isn’t just tidying up some stuff. This is a whole parallel project to, you think you’re building a website, but you’re really building, you need to build along with it, this authoring system. How big is that disconnect among orgs getting that?

Greg:
I think it’s incredibly large. I mean, because the book is basically outlines the process for properly designing for your content authors and treating them as users just as much as you treat the people who use your website as users. If you’re going to treat them that way, then you go through the same process. You have to research them to learn about their use cases, you prototype potential solutions with them, and then you implement and test those solutions and support them over time.

Greg:
That very much parallels the different process that you go through when you’re designing an actual front end for a website. It involves all of the same skill sets. It involves designers, it involves engineers, it involves content strategists, it involves executive stakeholders, and it really is like a parallel web development process. In most projects, it is very far from a parallel web development process.

Greg:
I think that a lot of that just comes down to this idea that these content people are just at the bottom of the chain of command at any given organization and that people view them as just like word pumpers. We see this all the time at organizations where people are like, oh, this person knows something about a topic. They can write the content for the website or whatever. I’m not the only person who have talked about that on your podcast for sure.

Greg:
This view that anybody can write, anybody can do this work, and so there’s no specialization, there’s no needs for it that need to be catered to. Part of me telling this story is just to say that that’s not true. That if you do this work, you will make better content and you will get better ROI on the system that you’ve spent a lot of money building. I think that’s a really important message to get out.

Larry:
We didn’t plan it this way, but the episode right before this one, I don’t know if you’ve listened to it yet, it just came out, was with Sarah Johnson who just wrote a book called Content-first Design. Starting with the content and a lot of parallel issues. I think this is going to be an interesting pairing in the sequence here.

Larry:
But when you talk about authors or users too, that’s one of the things you talk about in the book and just talked about, and you have this parallel process to go through them, which has never done well. How close in your work, I guess, because you’re probably doing as well as anyone. How close do you feel like you’re getting and how do you carve out whatever bandwidth you can for these concerns?

Greg:
I mean, I say at the beginning of the book that I outline a ton of things that you can do to help authors in the book, but I admit that there’s never been a project in which I have done all of these things. Usually what I’m doing is I’m taking the pieces that I can or that I can apply to the project that I have at hand and working them into the process.

Greg:
For instance, when we do discovery with a client, I always make sure that the content authors or someone from the editorial side is represented in the meetings. That’s like a step one to make sure that they’re involved and can make their voice heard, and that’s easy. Well, it’s mostly easy, and that moves a lot of what follows along and can say, well, who is this person and what are their expertises and needs? That leads to interviews with other content authors and that can feed into definition of functionality, into identifying pain points, and that leads in different directions depending on how it goes.

Greg:
I think it’s more about we never carve out a bucket of hours for content authoring. It’s more about how can we build it into our existing process and make it something that we keep top of mind as we’re doing any amount of work that we’re doing. Because a lot of times the things that improve the authoring experience, it’s just about making smart informed choices where you might otherwise make a choice that is not smart or informed or that you just don’t think about at all.

Greg:
I talk in the book about, for instance, the order in which you put fields on a content entry form. A lot of people don’t think about that. They just create the fields and they’re in whatever order they are, and it’s not thinking about it is more work. It’s just getting yourself into the mindset that this is a detail that you need to think about.

Larry:
That’s it, that mindset shift. Because I want to back up just a little bit. When you said that typically authors aren’t involved, or content people and authors are generally not as involved as they should be or need to be. Who’s making, are these usually IT decisions or executive level? Where does that disconnect start in the acquisition? Because you buy a CMS, I guess that’s where this all happens or a CMS implementation service, and then all this that we’re talking about unfolds. I want to back up just a little bit.

Greg:
Yeah, sure. I don’t think it’s intentional. I don’t think anyone’s sitting around saying, “We don’t want the content authors involved in our process.” I just think they’re not thinking about the content authors at all. Because when you look at the IT people and the executive stakeholders, that’s like a whole nother world that’s just completely outside their purview and that they have no visibility into whatsoever. They just assume that any CMS they’re going to drop on these people is as good as any other CMS etc.

Greg:
It’s not that these people are excluded, it’s just that they’re just not thought about at all. I think that’s part of what we do whenever I come into a situation and say, “Oh, who are these people? How can we get them involved in the process?” A lot of times the people that we’re talking to on a project won’t even know, and we’ll have to go dig that information up.

Larry:
You’re reminding me that I’ve heard people the most disparaging way to talk about this dynamic is that the decision makers have abdicated their responsibility to these other people in this, but that’s not, but what you just said, it’s not that. It’s like they’re not, at worse they’re ignorant. They’re certainly not malevolent. It is just not on their radar screen.

Greg:
Right, exactly.

Larry:
That’s really, and so I guess your attitude as you go into this… Is it just sort of matter of fact like, well, we’re at this stage now and here’s this authoring consideration. Is that how you operate?

Greg:
It’ll be something like I can come to the table and say, “Hey, we’re hearing from a lot of authors that they’re having problems with document management.” That’s a very common complaint from authors. We will have talked to them. We’ll have understood what their problems are with their current document management facilities, and then we can start proposing solutions. Again, a lot of the times those solutions are no more or less work than any other solution. It’s just a matter of identifying the needs and creating a solution, and also making the argument that if we have better solutions for the content authors, it’s going to result in better content.

Greg:
If they can upload content more easily, taxonomize it and classify it more easily, have a better idea or understanding of how it’s used and why, then you’re going to get better content that users can find better. It’s going to have better SEO. It’s going to be more easily to classify and filter. All of these things will come together, and the authoring experience feeds into all of that. Because one thing that will not get you better content is authors who want to get out of a CMS as quickly as possible because they can’t stand using it.

Larry:
No, that’s a great point. That sort of gets it, that goes back almost to when you said the form field sequence. If you just do a kind of road, I can see how that would be boring, but if you did it, tailor it to their workflow, as opposed to how it’s ultimately going to look on the page, that probably makes a lot more sense.

Larry:
How big is the delta between those? Also, so there’s that dynamic. There’s also the parallel dynamic I think, of people being used to working with WYSIWYG page building, page editing kind of things, and that authors at that point wanting control over the whole experience. Am I right in relating those things?

Greg:
Oh yeah, absolutely. The second chapter of the book is structure versus flexibility, and it’s all about that basically. It’s about how structure informs content, and a lot of authors don’t like structure. They see it as more work. If you copy and paste from a Word document and dump it into a body field, that’s very easy for you, but it’s not going to support the content needs of the organization. However, if you break everything out into a hundred component fields, that’s going to be a lot more work for the authors and they’re not going to like that.

Greg:
There’s a balance to happen there where you have to figure out how to meet the technical needs of your organizations, but at the same time meet your content authors where they are. Because there’s a quote I use at the beginning of a book from Deane Barker where he says, “The number one reason why CMSs re-platform is because their authors hate it.” If your authors are constantly complaining to you about how your CMS is hard to use and they can’t do what they want to and all of these things, then that’s a problem. But if the CMS doesn’t serve the needs of the organization, that’s also a problem, and figuring out those things and where that balance lies is unique for every situation.

Larry:
Based on what you just said, I want to jump to the last chapter. In the support chapter, you talk about the idea of copy decks or templated Word docs or Google Docs. They’re used to enter that. It just struck me that that was at the end of the book, and this is what you were just talking about is in chapter two. Is that just an add-on extra thing that some people do or is that… Because I’ve heard of a number of those situations more lately, like capturing stuff from a familiar document management thing that an author is familiar with? How does that fit in?

Greg:
I was actually just in discussion with someone on LinkedIn recently about the discussion around content creation versus content publication, which is because CMSs are basically a content publication platform, not necessarily a content creation platform because a lot of times content in the creation phase has to go through levels of review. A lot of times those people who are reviewing it are people from outside your organization or in roles that don’t have access to the CMS, so they can’t review it when it’s in the CMS.

Greg:
One of the things that familiar or interfaces like a Google Doc or a Word document provides you is that collaboration, an environment that’s very mature, that’s been used for a long time and that everybody is intimately familiar with regardless usually of their skill level with any content management system. You could send a Word doc to your legal team and they’ll be able to comment to it and mark it up in a way that maybe if they went into the CMS, they wouldn’t have an understanding to be able to do so even if the CMS allowed that kind of functionality.

Greg:
That’s where when I see something like a copy deck where we basically break down the fields into a Word document or a Google Doc and say, “Here is the subhead field and it has this many characters and it’s going to appear on the page in this way.” Then there’s a screenshot of the page with the subhead marked on it and that title marked on it and all of the pieces marked on it. It puts everything together in a way that provides an extensive amount of information about what needs to be provided and a visual reference about how that information is going to be used on the pages.

Greg:
Then this provides a place where people can work on the content outside of the CMS if they need to or even before the CMS is built. One of the things that we use those for all the time is we’re in the middle of a migration. People want to start on content, but the CMS isn’t ready. We start building these copy decks for them so they can start putting content together in advance. Then when the CMS is ready, it’s just a matter of pulling that information from one place to the other.

Greg:
Those can be in Excel. We’ve done situations where people do that free population of content in Excels, and then we have automatic import functionality and stuff like that. There’s different ways to go about it, but I’ve always been of the opinion that when you’re dealing with content creation, especially in very collaborative environments, there’s no need to bring all of that into the CMS. We’ve got tools that are good at it, that are mature, that people are used to, and I see people building this kind of functionality into the CMS all the time and it just feels like a waste of time to me.

Larry:
That’s really interesting because I’ve seen a couple of CMS vendors who pitch that as a benefit. Hey, it’s just like working in Google Docs. But I can imagine, but I’m sure you’re more knowledgeable of the issues that that raises to have a collaborative like a Google Doc inside your CMS. Tell me why that’s not such a great idea.

Greg:
I mean, I don’t know if it’s a bad idea. I just don’t know how functionally helpful it is. Because again, one of the things that we run into all the time is the external user problem. You’re writing a case study that you’re doing in collaboration with a vendor and the vendor needs to have access to the case study to approve it, but they don’t have access to the CMS. You’re not going to give them a login. In order to do a lot of these collaborative features, that’s the kind of thing you need.

Greg:
The same thing with your legal team. These are lawyers. They’re not CMS and content editors and they’re familiar with a Word doc. You send it to them, they could do it and send it back to you. Whereas in the CMS, this is a new interface they have to understand. Are there requirements that they have to have around keeping revisions or tracking changes and all of this kind of stuff?

Greg:
It’s like all of these mature functionalities exist in tools that everybody already uses, and I think there’s a problem of getting the information from those tools to the CMS, which is something that is a solution that I think that people could work on. But putting it into the CMS has always just struck me as kind of misguided.

Larry:
Yeah, that’s really interesting. I wonder because seen architectures that do that, that will have deep user permissions for the vendor level. You don’t touch anything, you just to okay this. Same thing with legal approval and stuff, and that kind of workflow.

Larry:
I also think of this whole new field of enterprise UX, which seems very aligned with what you’re doing. I mean Lou Rosenfeld has a whole conference about it now. I think there’s other events about it as well. I’m trying to figure out how all that comes together. In the decoupled architecture world where you have a headless CMS and then maybe there’s some adjunct workflow things. Have you worked in architectures like those or… ?

Greg:
I have, and I think that one of the things that I’ve encountered with them is that, and it’s definitely getting better than it was five years ago. The authoring experiences and the headless CMSs was pretty abysmal in many cases, but I think they’re improving a lot over time. But I also think that one of the things that we’ve been seeing a lot in the market. There was, I forget who wrote it, there was a big discussion going around LinkedIn a while back about the race to the middle in the CMS market.

Larry:
Yeah, Deane Barker.

Greg:
Yeah, and it was a lot of discussion about how the decoupled CMSs, which had very focused on structure, completely decoupled from presentation, were having to move more towards what the monolithic market had in terms of accommodating the needs of marketers, of people who want to have more bespoke control over pages. That’s where all of these page building applications started coming into play and people started building those into the headless CMSs, which is sort of anathema to what their original technological argument case was.

Greg:
But at the same time, the more monolithic CMSs, I worked a lot in Drupal, have had to make a shift towards being more API centric and decoupling from display because of the technological realities of the market, the desire for people to work with JavaScript frameworks like Next.js or React or whatever to build their front ends.

Greg:
When we talk about the race to the middle, that’s what we’re talking about. The things that distinguish the two architectures are slowly coming together to create a meld. I think that when we talk about what we saw in decoupled architectures five years ago, that’s a reason why a lot of that change has happened.

Larry:
From the authoring perspective, how does that affect that? Have there been changes in the vendor offerings or in how you operate to keep the authoring to as best you can, keep that authoring experience at the foreground as we’re sorting out this other stuff about decoupled architectures?

Greg:
I think that we have seen a lot of changes at the vendor focusing on authoring experience. I mean, one just small example I can think of is that recently… One of the biggest problems, especially when you have a fairly complicated architecture in which pieces of content are connected to each other. Say, an event that has locations and you create an event and it has to have a location that it references and that location doesn’t exist yet. What’s the process to get that location created?

Greg:
In a lot of cases, you used to see that what would happen was you would have to abandon the event you were working on to go create a location. In many cases, if the location was a required field say, abandoning that event meant not being able to save any of the progress that you already had. Now you’re in a situation where as an author, not only have you wasted your time, but you’ve got to throw all this away. Go create this event, this location, come back and now recreate the event that you just started creating. Obviously, that’s a very frustrating situation.

Greg:
That’s an example where I can think of a couple of vendors in recent years have come up with solutions for that that involve remaining in the context you originally were when you’re creating or adding connected content. That’s like an example of something from an authoring experience that’s making things a lot better and the kind of thing that people are starting to pay attention to more.

Greg:
I know a lot of people look at page builders as an improvement in authoring experience, and I think that that is a mixed bag. I go into this a little bit in the book, but it’s a much broader topic to be discussed. I think that the kind of things that like Jeff Eaton and Karen McGrane have been talking about in terms of the impacts of using page builders are really good background material to go more deep into that topic.

Greg:
But it’s one of those situations where authors love that flexibility, but it’s another situation where the more you use page builders, the more generic your content becomes. As an organization, having a bunch of content that’s very generic that you can’t identify pieces of structurally or semantically becomes a real downside over time. That’s what I see in a lot of organizations is they start using page builders in one place.

Greg:
We’ve got these monthly marketing pages we’ve got to make and we can’t structure them, so we’ll use a page builder, and then the page builder starts slowly creeping into all of the rest of the content at the organization because everybody loves how flexible it is. Then suddenly what you’ve got is a hundred thousand bespoke pages and nobody knows what they are, why they were created, how they’re structured, and then the whole process of everything that structured content comes with. From accessibility, from mobile friendliness, from findability, filterability, all of that stuff gets thrown in the trash and then those organizations find themselves in a real mess.

Larry:
How do you educate clients about that because that seems, especially that discoverability bit, because Scott Abel’s done a ton of research about how much time authors waste looking for stuff and doing the same thing over again or cutting and pasting. How do you keep that on people’s agendas, in their minds?

Greg:
It’s hard. You have to keep, when we work with clients, we try to be really explicit about what’s going to happen and how it’s going to happen, but it’s one of those things where it’s like you just have to keep telling them over and over until they understand. Unfortunately, a lot of times the clients that we see have already gotten into that situation and they come to us and say, “How can we fix this?” It’s like they’re already deep in a mess, and it becomes much harder when you’re deep in a mess to fix it.

Greg:
It can be hard, especially if you’re the kind of company that works on, at my last organization, I worked a lot on re-platformings and we would re-platform and then hand things off. A lot of times I could tell that the people in the organization were not prepared to take on the responsibility that would be required to keep the CMS structured and the content in a place it needed to be to fulfill their needs. That may be because they didn’t have the organizational or political power to do it or because their understanding just didn’t quite get there.

Greg:
But what we tried to do is to find the people with the organizational power and get them the understanding that they need to see what the impacts are going to be. Then especially for places that we continue working with as they come to us and say, “Oh, so-and-so is asking for this,” and you just have to keep telling them, “Here’s the impacts that’s going to happen if you do that. Here are the implications that that’s going to have on your user,” and just continue to work with them and educate them over time.

Larry:
You’re reminding me, you talk in the book about maturity, content maturity of organizations, and that sounds like exactly what you were just talking about. That seems like an important part of your work is to try to get, once you’ve left the project, they’re on their own. But to as best you can… Is that part of your methodology to assess or at least get a gut feel for their content maturity? Does that influence how you operate?

Greg:
Yeah, absolutely. I mean, content maturity is one of the key things that I use when I’m evaluating what kind of authoring experience we’re going to create. There are other factors. How big is your organization? How technologically knowledgeable is your set of content authors? Are they just academics or SMEs, or do you have real content professionals who understand how CMSs work and things like that?

Greg:
Because the content authoring experience that you create for a large scale enterprise software company that contains a lot of technical knowledge, a lot of really knowledgeable users, a lot of people who are very familiar with the marketing needs and the content needs and have a holistic view of the content in an organization, are very different than the authoring experience you’re going to create for a state government where most of the people coming into it are subject matter experts with very little technical knowledge who don’t understand how content operates on the web, who don’t have a holistic view of their content.

Greg:
The approaches that you’re going to take in each of those situations are going to be very different. Even if the content at hand is very much the same because you can’t make the assumptions with one set of users that you can with the other. All of that stuff informs the work that we do when we’re trying to figure out more about the organizations and what kind of solutions we can provide.

Larry:
That opens up a whole thing about CMS vendors and what they offer and oh, this is all you need. But hey Greg, I can’t believe we’re coming up close to time already. We’ll save that for another conversation because that could be a good one. But hey, before we wrap, is there anything last, anything you’d like to revisit from the conversation or just make sure we share?

Greg:
No, I just hope people get a lot out of the book. One of the things that I was thinking of when I wrote the book is I see a lot of discourse about CMSs on LinkedIn and out there, and it’s so much of it seems to be targeted towards very mature, large-scale organizations that are buying DXPs, buying personalization platforms, buying DAMs, buying headless systems and all of this kind of stuff.

Greg:
I just found myself so disconnected from that discourse because what I was seeing with my clients that I work with are clients that are at the bottom of the maturity level, who are just getting started thinking about content, who have one CMS and they’re trying to figure out what to do with it, for one site that may have 5,000 pages, and how can we get better and how can we improve?

Greg:
That was the approach that I took for this book. It’s very simple, very straightforward, very one-on-one type of stuff that we can do to approach content authoring. I wanted stuff that could work for clients at every level to have very approachable, very realistic goals and tasks that they could take on to improve their authoring experience. I hope that people can get something out of it.

Larry:
I got a lot out of it, I’ll say that. It’s a great book. It was like it only took me a few, maybe two, not even two to three hours to read it, but it’s so dense. But it’s just a really good book and I’ve read a lot of books. Anyhow, I’ll definitely link to the book in the show notes. Oh, one very last thing, Greg. If folks want to connect or follow you online, what’s the best place to find you?

Greg:
I’m on Bluesky a lot these days at heyrocker.com, and I’m also on LinkedIn if anybody wants to find me there. Then if you want to know more about the book, I’ve stood up a website for it at AuthoringExperience.com.

Larry:
Excellent. Well, I’ll link to all that in the show notes as well. Thanks so much, Greg, and congrats on finishing the book. That was fun to watch you do that.

Greg:
Thanks, Larry. I appreciate it.