Podcast: Play in new window | Download
Subscribe: Apple Podcasts | Spotify | Android | TuneIn | RSS

Most enterprises and software companies now have design systems, and many have content operations and/or design operations teams.
At Cisco, Barbara Blythe works on the content design operations team. She focuses on sharing content guidance across the products she serves, enabling not only content designers but also their UX design and engineering partners to efficiently create consistent product content.
We talked about:
- her content design ops work at Cisco
- how content design ops differs from content ops
- their cross-functional approach to empowering designers and engineers, as well as content folks, to use the content design system
- her involvement in the design of new bots to govern voice and tone and style
- her thoughts on how AI might affect content design ops
- some of the benefits, beyond consistency and the efficiency, of using a content design system
- how systems like hers permit content designers to focus more on content strategy and other work that may be more impactful than surface-level UX writing
- some of the work she does to evangelize their content design system
- Cisco’s federated model of integrating their many design systems
- how they share content practice lore across Cisco
- her advice for folks interested in creating a content design system
Barbara’s bio
Barbara was a Classics professor for six years before transitioning from academia to tech. As a content designer specializing in content design ops and content design systems, she creates tools that help content designers, UX designers, and engineers create consistent product content more efficiently. She designed and built a content design system for Cisco’s CX Cloud and PX Cloud products, and she’s now expanding it and developing ways to use tools like AI integrations to make it even easier to use. Barbara lives in Virginia Beach, where she enjoys birdwatching, gardening, and growing shiitake mushrooms.
Connect with Barbara online
Video
Here’s the video version of our conversation:
Podcast intro transcript
This is the Content Strategy Insights podcast, episode number 181. Over the past decade or so, enterprises and startups have adopted design systems and built teams to scale their design operations. In a few places, those practices have come together in content-specific design operations. Barbara Blythe works on the content design ops team at Cisco. As in many modern enterprises, there are never enough content designers to serve all of their needs, so Barbara’s operation focuses on empowering cross-functional partners to also work with content.
Interview transcript
Larry:
Hi everyone. Welcome to episode number 181 of the Content Strategy Insights podcast. I’m really happy today to welcome to the show, Barbara Blythe. Barbara is a senior content designer at Cisco, big hardware manufacturer you may have heard of, probably runs half the internet stuff you’re doing every day. But welcome, Barbara. Tell the folks a little bit more about what you do there at Cisco.
Barbara:
Yeah. So thanks, Larry. It’s great to be here. So at Cisco I’m working on CX Cloud and PX Cloud, which are SaaS products that give network administrators a unified view of their network assets along with insights and analytics. And I specialize in content design ops. So over the past about two years, I’ve been working on building a content design system and I can talk in a little bit more about what I mean by that because I think it means something a little different to everyone who’s building them.
Barbara:
Now I’m really expanding it and trying to find ways to increase adoption and trying to find ways to use tools like say AI chatbot integrations to make it easier to use for people who might be, say, a little reticent to dive into a style guide or to sort of sift through documentation. What are some ways that we can make it easier to use these tools. And just to give a basic idea of how I’m thinking of these terms and job titles, because that’s always a big topic we could probably talk about for an entire podcast episode.
Barbara:
But when I think of content ops, so there’s content ops and then there’s what I think of as content design ops. So with content ops, I’m thinking a lot about things like creating governance and strategy for things like how content is created, how it’s structured, how it’s organized, how it’s displayed. Maybe things like working with a CMS, digital asset management editorial, that kind of thing.
Barbara:
When I’m thinking about content design ops specifically, I think there’s definitely some overlap. But I think of it more as being focused on what content designers need to do their jobs more efficiently and create consistent higher quality product content at scale. So it’s really focused on the UX aspect and different folks who work on content design ops, if you ask them what they work on, some of them are more focused on process and workflow.
Barbara:
Some of them are more interested in things like design systems, which is more where I settle on that spectrum. But really, anyone who does content design ops is interested in working to remove obstacles that are in the way of creating great product content.
Larry:
Yeah, you said a minute ago, the things that always come up about design systems, that’s mostly what people have talked about. I got to observe that there’s not that many people who are privileged like you are to work just on content design ops. That’s so cool that that exists. But in that content, in the design systems world, they always talk about efficiency and consistency is two of the main goals. And you just said both of those words, so it makes sense that those would appear there.
Larry:
But as you talk about that, when I think about… And you also mentioned the content ops side, including the CMSs and DAMs and all the sourcing of content. Are you more concerned then with, like you said, the front end, the presentation of the content, but working with the designers about helping them do that? Is your work mostly to support content designers per se, or do other people use this content design operation that you’ve built?
Barbara:
That’s a great question. So one of our goals is actually to make content creation and content reuse more cross-functional in our work. So when I think about how content designers on product teams are creating content, it’s an embedded model. So the content designer is embedded on the product team and they’re either creating content from scratch or sometimes they’re taking maybe some placeholder copy that the UX designer wrote and they’re working on it and maybe they’re hunting around for say, examples that are similar to what they’re writing.
Barbara:
And that’s great and it produces some really high quality content, but it takes a long time to do. And there can be definitely some inefficient and duplicate efforts. And unfortunately, there’s just not enough content designers to go around. And I think this is a very common theme, especially with the say, the tech market downturn. Head count is a problem and if there’s lots of new work coming out, not enough content designers to go around.
Barbara:
What you hope and what we certainly hope in my org is that we can basically empower and equip the designers and even the engineers to be able to make better decisions on any content solutions that we’ve already worked on. So that can mean things like say, pulling content out of a repository. If it’s approved content, it’s right there, just click and drag.
Barbara:
It can also mean maybe even more advanced things like one project we’d like to do is create a VoiceFlow based bot that will create error messages. So devs can tell the bot, hey, this is the error, these are the conditions around it, this is what the user can do. And it hopefully would give them at least some starter copy that would meet our content guidelines and give them some ways to create content that doesn’t always have to be reviewed or approved or iterated on by a content designer.
Larry:
Interesting. I love that it’s error messages that you’re starting with this voice agent because that seems like one of the more, not standard, but it’s like there’s thousands of things that can go wrong, but there’s just a style that you want to have happen.
How does that look like in the way that a content designer, UX designer, an engineer might see, might experience that bot? You said VoiceFlow, so it’s sort of a traditional voice agent, script driven. Or tell me more about that bot.
Barbara:
Yeah, before the show, we were talking a little bit about a style guide bot that a colleague, Melody Kim, and I are creating. And that’s actually, that’s the one we’re working on currently. The error message bot is a future project that we’ve been thinking about. So we haven’t exactly designed how this would work, but the idea would be similar that we would be putting in as training data, a bunch of error messages that are approved that the content team has decided fit all of our guidelines.
Barbara:
And we would be ideally even creating maybe some templates that these can follow because there’s a lot of error messages where maybe the particulars are different, but you could templatize it in a way. And so we’re going to be putting those in and I think the goal would be that the designer or the dev or whoever’s using this bot could put in basically whatever information they have, what happened, what can the user do to remedy the situation.
Barbara:
And it’s not just going to spit out a message, but hopefully one that maybe follows our overall style guidelines, but also takes into account some specific templates and patterns we put together for error messages.
Larry:
Interesting. And the way you describe it, this is like an LLM training model based chat agent that you’re training on your… You just put in all of your current error messages and go from there? But let me back up from that because it sounds like you’ve already done the style guide bot, right? Because you have some more empirical things to say about that, I’m going to guess, right?
Barbara:
Yeah. So with the style guide bot, the rationale for thinking about why we might create something like this is, I think I mentioned adoption is something we always want to improve. So we started with a style guide. We built it out to the point where I can say it’s really a content design system at this point because it has not just a style guide with abstract stylistic guidelines, but we’ve got patterns and templates and components.
Barbara:
And the problem though is that it’s still something you have to go into this tool, we have it in zeroheight, that’s the tool that our design system uses and that we’re using for the content design system. You have to go in there, you have to be on VPN. And not everyone wants to be on VPN all the time because it can slow down your bandwidth, and you have to hunt around. And we did actually a lot of work on making the IA a little better in terms of making it easier to find what you’re looking for.
Barbara:
But still not everyone wants to go hunt through a system or a style guide or whatever you might want to call it, it’s still a tool you have to sit through. So we created this bot and what we did is we basically stripped out pretty much all the content from the whole content design system and then we started organizing it just in a Word doc. We actually tried other ways and the Word doc was the easiest way to do it. Sometimes the simple ways are best.
Barbara:
And what we found is that if we used hierarchy, so we’re organizing, it’s just text, but we’re organizing it by H1, H2 bullet points to give the bot a sense of what is a coherent entry and then within that entry, what are the parts of the entry that are say, about casing, what are the parts that are linking you out to a repository?
Barbara:
And so we put it in there and then within, I would say a week or two, we’re still fiddling around with it. We haven’t quite released it yet, but within a week or two, we actually had a pretty good MVP bot where you can ask it questions like, what are the casing guidelines for an accordion section heading?
Barbara:
Or when is it okay to use a popover and when should I use a tooltip? And it’s able to answer questions like this, and we’re hoping that this is really going to increase adoption for our content guidelines, not just among content designers, but hopefully among designers and maybe even devs as well.
Larry:
That’s so interesting. I love the way you just described that. When we first connected, I was like, “Oh, she’s probably doing all kinds of cool CMS stuff and everything.” “No, we just have a Word doc. And that’s always how it is.” It’s always like a spreadsheet or a Word document or something that you’re doing, and I love that it’s properly structured.
Larry:
But it’s sort of semi-structured in that sense in that you’ve got it semantically tagged essentially with the heading levels and bullet points and stuff. Is that learning fodder for a large language model or is it a data source for a retrieval-augmented generation model or?
Barbara:
I would say it’s more retrieval-augmented generation, I think, in this case. And I’m not up on all the technical specs behind how this literally works with the VoiceFlow, it’s more my colleague, Melody, it’s her purview. But yeah, it’s basically going in and using this as using basically just this document, this Word doc, which I think is about 60 pages at this point, and just using that as the background knowledge.
Barbara:
So if you ask it why is the sky blue? Then it’s going to say something like, well contact Barbara and ask her because it knows that that’s something that it doesn’t have information on. But I think what’s really cool, I think about the possibilities with AI and content design systems is I think they can interact almost like a flywheel where they’re each propelling the other forward. So I think right now having a content design system and having that structured content I think is really important to be able to create a style guide bot like we created.
Barbara:
But conversely, I think AI might help create, especially in the future, it might help us create content design systems. Right now it’s a little bit rudimentary. You could ask ChatGPT to maybe give you some documentation on a component, and you might use that as you’re creating documentation.
Barbara:
But I could imagine maybe a future in which we could literally feed the entire prod UI into an AI platform and it could basically spit out a draft rudimentary content design system where it’s gone through and identified opportunities to create templates or to componentize or templatize because it’s found all these strings that are maybe very similar but slightly different because they were written by different content designers, but then you can converge them.
Larry:
The way you’re describing that I’m thinking of whenever you embark on a situation like that, on a project like that as a human being, you’re very quickly get to the point where the tediousness of it bogs you down. But that tedious task accomplishment is things that AI agents are great at. Hey, it’s funny, I actually have a whole other podcast on content and AI, maybe in a few months we should check in when the error message thing is going and you got more about that, maybe check back in on that.
Larry:
But I want to also check in about just the generic benefits of having a content design system. Generically, we talked about the consistency and the efficiency, but also it seems like, and you mentioned also earlier staffing issues. Nobody’s overstaffed these days. We’re all pretty lean and as we operate. So tell me, I’m assuming there’s a benefit to just an impact that you can have as a content design team with this operationalized stuff in place. Is that a fair guess?
Barbara:
Yeah, I would say so. When I think of some of the biggest challenges I think that content designers are facing right now, and actually these challenges are what led me to become interested in content design ops in the first place. I think there’s a lot of challenges because whether you’re creating content from scratch in a given screen or whether you’re just working with say, some placeholder that your UX designer put in there, that’s a lot of work to create things from scratch.
Barbara:
It’s also a lot of work, even if you think, well, I’m going to save myself time by looking around for some examples. You have to find those examples. You have to hunt through Figma files, you have to maybe hit up all your friends, all your colleagues and say, “Hey, do you have an error message that looks like this?” But you can only do that so often.
Barbara:
And so you’re going through and there’s a lot of redundant efforts. Maybe you’re solving a content problem that someone already solved last week, but you just don’t know that they did. And so having things here in a system I think is really helpful, because once someone has come up with a solution to a content problem, or maybe even your whole team has, you’ve sat there and litigated this and hashed it out, you’ve come up with a solution, let’s encode it. Let’s put it in the system so no one has to discuss it again unless it turns out to be deficient in some way.
Barbara:
I think it really helps with, like we talked about allowing designers and engineers to pull approved copy. I think also it can be really helpful because content designers are really bogged down by a large, I think, with what they sort think of as surface level copy editing work. So content designers always have been very vocal about wanting a seat at the design table. They want to have that seat at the table that allows them to get in early on design projects when there’s still time to be involved in these strategic decisions.
Barbara:
And I feel like I certainly don’t want to speak for all design orgs that have content designers, but I think a lot of content practices have now achieved that seat at the table, but it’s hard to make use of it because they don’t have time to do this work that has a lot of the deeper strategic work that has a lot of impact when they’re stuck with all the surface level copy editing work. And I think it’s easy to say things that you hear a lot on LinkedIn, well set boundaries just say no, only choose impactful work.
Barbara:
But the problem is if you do that, then if this surface level copy editing work is not being done and copy’s going to development and leadership is seeing maybe terminology inconsistencies or casing problems, the buck stops with content. So it feels like there has to be a solution where we can automate some of that surface level work to buy ourselves time to do the deeper strategic work. And I think that’s what the modular automation of a content design system can help move us towards.
Larry:
Yeah, that makes sense because if you have those basics accounted for in the operation, theoretically you’re freed up the automatable stuff like the style, or even like you said, the surface level writing. That’s probably one of the first things that AI agents are going to be able to help with.
Larry:
But regardless where it’s coming from, I don’t know if you listened to about four or five episodes back, I had Relly Annett-Baker, UX writer content design lead at Google, and she was talking about how those words are just like, that’s maybe 15, 20% of the job, 80% of it is figuring out what to write. And we got to see at the table, we’re sitting there, we’re still writing, and you’re like, “No, I freed you up with the system. You can go out and do more strategic work.” That’s the benefit?
Barbara:
Yeah, I would say so. And that’s the dream. I guess it’s easy to say things like, well, we’re going to automate all the surface level work and then all you have to do is the deeper strategic work. I mean, of course in practice, a content design system, at least in its current incarnation, is not automating all of the surface work. But I think we can, as we build them, really pay attention to the things that are really important.
Barbara:
So I read something really interesting in Dan Mall’s latest book on design systems that really stuck with me. And it made me realize that as I was building this content design system at Cisco, I think I was too focused for a lot of that time on trying to be exhaustive thinking I need all of these different things and if I don’t have these specific components, it won’t be a content design system. So I have to have all of these things.
Barbara:
And Dan talks a lot about this idea of pilot programs. Instead of at the beginning when you’re building your design system, and of course he’s talking more about sort of standard visual and interaction design systems. But he says, when you’re building them, don’t be focused on being exhaustive at first focus on pilot projects.
Barbara:
Think about what could provide a lot of value. What are some issues that you’ve heard of from multiple product teams, the same issues keep coming up and start there and define those things. So this will probably sound really random, but something that kept coming up for my product teams is a little tiny label that goes above a table and it explains the number of items that are in the table. If it’s paginated, it might say 1-10 of 23 assets.
Barbara:
The thing is, product teams were writing this little label in all different ways. So no matter where you clicked in the product, you were seeing this in different ways and it made it look very inconsistent and confusing and just defining one tiny little label, just a little template for how you do that suddenly it didn’t just save everyone time, but it stopped everyone having to constantly be discussing this and asking their content designer how to format it. So it’s like, look for those little opportunities that might be small, but they will provide a lot of value.
Larry:
That’s so interesting. I love that. I’d forgotten that example. I had Dan on the podcast about 10 or 12 episodes back talking about that. And I loved that pragmatic approach, and it sounds like that totally aligns with how you’re operating as well. I’m sorry you were-
Barbara:
Oh no, please continue.
Larry:
Sorry. No, sounded like you were going to say something. Again, one of the other benefits we talked about earlier is that, or not benefits, but that’s sort of like you mentioned the issue of adoption. That was part of the reason you did the style guide bot, I think I’m reminded of this because I’m thinking of the conversation with Dan Mall.
Larry:
But that’s a classic issue in any design system is adoption. That you don’t build it and they will come. It’s a constant ongoing, not promotion, but a little bit of evangelism and communication and ongoing education about it. Are you finding the need to do that with the stuff in your operation?
Barbara:
I am, yeah. One thing I’m actually going to start this week actually, so this is very topical for me, is we have a weekly design huddle, which is where we get all the UX folks in the org together. So it’s a nice way to socialize with the designers and the research folks and see what’s going on. And I’m going to start doing actually a weekly update and just giving everyone an update on these are the new things in the content design system, and it’s just very simple.
Barbara:
It’ll probably only take two to three minutes, but I realized, well, our design system is doing that, so why am I not evangelizing and giving these just quick updates just to keep it top of mind. I think sometimes it’s not even that my colleagues don’t want to use the system, they just forget that it exists. So I think we need to keep things top of mind. I’m hoping that the bot will help as well in just making it easier to find these guidelines.
Barbara:
I’ve also lately been thinking a lot about this thing called the IKEA principle, where the idea is that, I think Dan Mall talks about this too, he has so many amazing things in his book. But the idea that if someone contributes to building a system, they’re going to be more likely to want to use that system and engage with the system. So what I’m realizing is that it’s mostly been me creating these things.
Barbara:
And obviously, I’m doing a lot of collaboration with my teammates and the content design team with engineers and designers, but it’s largely me spearheading creating these components and these repositories and so forth. And so what I’ve realized is that I think if I bring others into this process more and give them some ownership over, maybe they’ve created that component or they put together that template or whatever it might be, I think that might give more of a buy into the system.
Barbara:
I know that this is true because designers that I’ve worked with on creating components are the ones that I see in those files using them more. And I think the medium is the message too when it comes to designers using content governance. If it’s in a tool that’s totally separate from the design system, and also if it’s not in Figma, if your designers are working in Figma, they’re going to be less likely to use it. It’s not going to look as familiar.
Barbara:
So it’s like literally if you use the same visual design that your design system is using to put their documentation together, it’s just going to feel more like the design system if you can house it together with the design system. Just make it look like and feel like and be housed where their normal workflows happen, which is in the design system.
Larry:
Go out and meet them on their journey and just give them what they need. As you were talking about that, I was wondering the scale of your content design system compared to Cisco’s broader design system and the interaction between them, is that an ecosystem that you fit into or are you off to the side? How’s that set up?
Barbara:
Cisco has a very federated model. So Cisco acquires a lot of companies and brings them in, and it’s a little bit complicated because you might think, well, you would just immediately have these companies that you acquire, you would immediately have them use your design system. But actually that’s not typically the way that we do it.
Barbara:
We typically, and it varies case by case, but typically they continue using their design system, their branding, and sometimes there’s sort of a convergent process where sometimes they will be brought in to use another design system. But Cisco actually has a great number of design systems. I’m not even sure how many, but many of them.
Barbara:
So the one that I’m working with and the content design system that I’ve built that it sits alongside, those are specific to our products, the CX Cloud and the PX Cloud, but there are many other design systems and products within Cisco.
Larry:
That’s interesting. And you mentioned that it sounds like content design is an embedded practice. Is that across Cisco that generally content design is embedded in the product line?
Barbara:
There are definitely different models and different design orgs within Cisco, but that does seem to be pretty common, having an embedded model.
Larry:
And I’m just wondering, is there anything like a community of practice where you all swap tips and all that usual community activity?
Barbara:
There is, yeah. And it’s sort of increasing because something that my manager and other leaders of these content design practices have even in recent months been thinking, this is something where we should really be getting together more. There are other content designers out there, why are we not sharing knowledge?
Barbara:
And I’ve actually very recently started a Webex space, a sort of a messaging space and started an event. We haven’t even had our first meeting yet, but we will in a couple of weeks, to get together folks who are interested in creating content at scale.
Barbara:
So not even just content designers, but all sorts of content creators across Cisco who are interested in finding ways to use content design systems, style guides, AI automation, all different tools for creating content more efficiently and consistently at scale. So I’m hoping that we can really share our practices and what we’re doing, and hopefully I’ll learn a lot as a result.
Larry:
And it occurs to me, that’s probably a very fertile cross-pollinization thing there. With all these acquisitions, you probably have a lot of different kinds of talent as well as the usual product marketing product people, website content. And the technical support documentation team at Cisco must be huge. So plenty of content people there.
Barbara:
Absolutely. Yeah, and it’s interesting too because on other teams, sometimes I’ll talk with content designers who have something specific that they’re really good at and they can share their knowledge on that. There’s one content designer who’s very good at collaborating with research, and she’s very interested in up and coming tools and processes for doing content research specifically. So there’s definitely a lot to learn with the cross-pollination.
Larry:
Yeah, that’s just that notion of content research. There’s Erica Jorgensen, and that’s about it in terms of people who really focus on that, so the more the merrier with that. Hey, Barbara, I can’t believe it. We’re coming up close to time. This always goes way too quick. But before we wrap up, is there anything last, anything that’s come up in the conversation that you’d like to revisit or that you just want to make sure we share before we wrap up?
Barbara:
Yeah, so I guess to me just in terms of giving advice to anyone who might be interested in creating a content design system, I think it can be really overwhelming thinking how there’s so much to build, how can I build a design system from scratch? But I think just moving incrementally from a style guide mindset to a modular design systems mindset of thinking of creating content components, patterns, even if you’re only making a couple as they arise and as you find the opportunity to create a pattern or a component that provides value.
Barbara:
I think if you’re just moving slowly, incrementally towards that modular mindset, I think that’s always great. And think about adoption and be strategic about adoption from the start. It’s always going to be a challenge. Like you were saying, Larry, it’s never going to be easy to get people to adopt content governance. So keep evangelizing your system, keep it top of mind, make it something that everyone’s thinking about and make it as collaborative as possible.
Barbara:
Nathan Curtis has this great quote about how the arc of design systems bends towards greater collaboration. And I love this idea that maybe not every design system currently and every org and every place and every instance is really collaborative, but it feels like over the longue duree, I think that’s something that we’re moving to and hopefully we’re able to really incorporate content more into visual and interaction design systems and get a lot more collaboration going.
Larry:
Yeah. I’ve been around for a little while and the thing I’ve seen, everybody’s moving left. Every practice wants to move earlier in the process, and that just logically culminates with more collaboration. Yeah, it’s great to see that. Oh, hey, and one very last thing, Barbara, what’s the best way for folks to stay in touch if they want to connect or follow you online?
Barbara:
Yeah, the best way to connect is on LinkedIn. I love connecting with folks who are interested in content design ops and content design systems.
Larry:
I will observe that your posts there are very interesting and deep and well-informed, so thank you for that. Well, thank you so much, Barbara. I really enjoyed the conversation.
Barbara:
Thanks so much, Larry.

Leave a Reply