Michael Andrews: Managing Content in Design Systems – Episode 147

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Google Podcasts | Stitcher | TuneIn | RSS

The emergence of design systems has created new content strategy and content management needs and opportunities, especially with the advent of headless CMSs.

As a long-time UX practitioner, content strategy evangelist, and content systems expert, Michael Andrews is uniquely qualified to talk about how to manage content in these new systems.

So far, the most important lesson he has learned from working with content in design systems: Don’t forget to apply the basic content strategy lessons we’ve learned over the past 20 years.

“You really are not going to be as good a content designer as you can be if you don’t tap into the incredible body of knowledge that’s been developed over the past 20 years in content strategy.”

We talked about:

• his work at Kontent.ai and his history as a UX and content practitioner
• the emergence of content practice in design systems, currently “more guidelines than executable processes”
• the problems with tightly tying content to specific uses in a design
• the main benefit of headless content management – “decouple the visual layout of the UI design from the content itself” – so the same message can be conveyed in multiple channels
• how content strategy practice manifests in design-system work
• the current state of tooling for working with content in design systems
• the benefits of working with content from a single source of truth
• governance issues that can arise when working with content in design systems
• the benefits of bringing well-established content strategy and content modeling craft to design-system content
• how a content model can help manage content variants and variations in a design systems
• the importance of having the right content structured and ready for uses like personalization experiences

Michael’s bio

Michael Andrews is content strategy evangelist at Kontent.ai, a headless CMS. In this role, he champions better practices for managing all kinds of digital content. Over the past two decades, he has worked as a consultant in the fields of user experience and content strategy in the United States, Europe, and Asia, advising clients in a diverse range of industries. He’s spoken at various content-related conferences, blogs extensively, and has written two books about content metadata. He has an MSc in human-centered computing systems from the University of Sussex.

Connect with Michael online:

• LinkedIn
• Twitter

Video

Here’s the video version of our conversation:

Podcast intro transcript

This is the Content Strategy Insights podcast, episode number 147. As design systems have emerged over the past several years, content designers and content strategists have begun to work with their design and engineering colleagues in new ways. As a content strategy evangelist working for a headless-CMS company, Michael Andrews has a unique perspective on this growing segment of the design and content worlds. His biggest take-home lesson so far? Don’t forget the basic content strategy lessons we’ve learned over the past 20 years.

Interview transcript

Larry:
Hey everyone. Welcome to episode number 147 of the Content Strategy Insights podcast. I’m really delighted today to welcome back to the show, Michael Andrews. Michael was on about three years ago talking about metadata strategy, but we have a much more topical thing to talk about today. We’re going to talk about the role of content and design systems. So Michael, welcome. Michael’s an evangelist, a content strategy evangelist at Kontent.ai, and welcome Michael. Tell the folks a little bit more about your work there at Kontent.ai?

Michael:
Well, thanks again for having me on again, Larry, delighted to be here. Yeah, I work at Kontent.ai, which is a headless content management system and really trying to bring the new and best practices of content strategy to our customers and folks who might be interested in moving to a headless approach to content management. And I’ve been working in UX and content strategy for over a couple of decades now. I started out in UX, which is not really a common background to get involved with content. So I’ve been very interested in the intersection of content and user experience, how we can make that process more effective and ideally more sustainable.

Larry:
One of the things that’s emerged the last four or five years, I guess, is the role of design systems in UX practice, and that is a way to articulate patterns and foundational design decisions and organize content or organize design components in a design system. And just the last maybe year or two, I want to say that it seemed like there’s been attention to the role of content and design systems. So can you talk a little bit about where are we at? How are we doing with getting content into design systems?

Michael:
Yeah. It is interesting to see the emergence of content and design systems, and I think we have some companies that are really looking to build that out. Other companies are maybe curious about it, but they haven’t done so much yet on it. But I would say generally speaking, it’s a case of the design systems, as you pointed out, have been underdevelopment now for the past half decade or so, and the content piece of that has been a much more recent arrival.

Michael:
So we don’t see the level of detail, I think, in the content aspect of the design system that we see in the UI definition part of it. With the UI piece of it, we have a lot of detail there where you’re defining these components in really production-ready detail. So you can create tokens that you can really push into production, reuse these particular pieces of the design system, modify them quite easily through code, things like that.

Michael:
We don’t have anything really production-ready when it comes to the content that’s in design system. It tends to be much more advisory notes about this is the kind of things you should do, this is a tone you should use here. These are the good words that you should use or shouldn’t use. But even then, there may be some exceptions to it. It’s much more guidelines rather than executable processes that you can implement straight away. And I think this is pointing to maybe the different intents behind the design systems as they were conceived originally by front end developers and the expectations that content folks have for design systems. I think they’re coming from slightly different perspectives there and maybe that is going to resolve itself, but maybe it’s also just creating some divergences in terms of what people want these things to evolve into over time.

Larry:
As you talk about that, I think we could probably all agree on the top-level benefits of a design system or that notion of consistency and efficiency, doing things better and quicker and making it consistent across the board. But very quickly after that, we seem to diverge the design people and the content people. Do you have any success stories about… And designers are all about diverging and converging. Have you had any good convergence success stories?

Michael:
Conversions between…?

Larry:
Well, in terms of getting… Well, actually, let me contextualize that a little bit differently too, because when I think about content in design systems, I think about… I think most of the content that’s in design systems now is around documentation of… The stuff that we think of as the content and design systems is like the guidance, the style and voice and tone and brand guidance and all that stuff. But I also think a lot about those UX strings that are in there that most of which are buried and ensconced in Figma at this stage of the game.

Larry:
And then I also think about the instance data, the substantive attribute-based data that populates instances of the designs and each of those three kind of has… I don’t know, can you manage all three of those in a fancy headless CMS like yours?

Michael:
Well, yes, I think you can, but this is really the interesting thing is that often, when we see content designers working alongside their colleagues who are designing the UI itself, we find that they are defining very specific text strings to accompany specific widgets in a UI design. And this is causing a tight coupling between the UI widget and the text that is being placed in that widget, and I don’t think this is actually a healthy thing to do. So one of the things I’ve observed in my career is that the UI design tends to get revised at a fairly fast pace. It is common to revise your UI design, refresh it or maybe even radically change it on a fairly quick frequency because there are new front ends that come out that give better performance. People decide they want to update the look of it, all kinds of reasons driving that.

Michael:
The content itself, what you need to communicate, that has a much greater permanence to it. You need to decide what it is you want people to do, how you need to convey that. So you don’t revise that as often. So when you are coupling those words, essentially trapping them inside a button and that button keeps changing, you’re potentially having to rewrite that button text just because you’re visually redesigning the layout of your UI. I think organizations across the globe are finding that is a pain point they would like to do away with.

Michael:
So as you mentioned headless, that is really the benefit of headless is that you are able to decouple the visual layout of the UI design from the content itself. So the content itself is structured where it has an independent existence from the UI design and people can revise that UI design without breaking the content as a result of that. But people need to start understanding the value of planning their content outside of the context of a very specific widget in order to take advantage of that.

Larry:
Right, because as you’re saying that, I’m realizing that, and we talked about this a little bit before we went on, that same intent, that same purpose is probably best embodied in the content associated with it. And that content could show up in this widget, that widget, some other gizmo, some other doohickey, all kinds of different components in that system. That’s what you’re getting at, right?

Michael:
Exactly so. We somehow with design systems have allowed content folks to believe that that’s the one expression. If you have a notification, it needs to show up in this particular notification box, but we can start thinking across different channels and realize that that notification box may not appear that way, but they still need a notification. You may need to get that notification in an email or you may need to get that notification in some sort of voice channel. And so we can’t just think about the expression as defining what we need to communicate. We need to first start with what we need to communicate and then worry about how we’re going to express that, and is there just one way we’re going to express that visually or will it be alternate ways that we may need to do that?

Larry:
A couple of things come up out of that that just come up in a lot of other contexts as well. And you’ve probably dealt with this a lot as a headless CMS guy. One is that notion of educating authors on new ways of authoring for these, because there’s this… The WYSIWYG expectation in a lot of people’s minds about how that works. So there’s both that, the need to educate authors, and then there’s also the need for maybe a new kind of collaboration between content people and design people about how do you maintain that intent and purpose while still working in your… not silos, but that separation of concerns that comes with decoupledness, that makes so much sense? There’s still some coordination and communication that needs to happen there. Can you speak to those dynamics?

Michael:
Yeah. So I think we have a tradition in the content strategy discipline of writing content with intent. So you lay out the points you need to make and you can have a structure in mind upon which you develop specific content. So your content follows a structure and it breaks the content into discrete pieces that represent a message that you need to convey or a piece of information that you need to convey. So that tradition is there, it’s pretty well-developed. There’s actually, people have come up with whole methodologies of different ways of doing that. So there’s not just one way of doing that, but that’s there and available for people to use, to plan their content, to take the requirements that they’ve identified through the business requirements as well as looking at the user research and what people need to understand, what they currently understand and what they want to know, all that can be planned ahead of time.

Michael:
You can then develop some prototype content independently of any visual design, and that can be placed in a content management system, especially if it’s a headless one. And then you are able to connect that to any design. So the way decoupling works is not that you aren’t connected at all, but you’re connecting this through APIs. So it basically will map a particular message or a piece of information to a place where it is expressed and people can show that content, present it in multiple ways. So maybe there’s not just one design being considered. There may be multiple designs and you can see how it looks across different designs or different touchpoints. And that’s really an important need now is to see how that content appears on different touchpoints.

Michael:
And you also, many organizations are trying to localize their content. So they’ll have content for different geographic regions, quite often in different languages. And how that content appears, the localized variants in different presentations will be different as well. But we now have the ability to connect the content. If it’s stored in a headless CMS, you can connect that to wherever you are developing your design. Or if you have an existing design, it’s pretty easy to connect it to that. And you can see how it looks if you are currently developing a design and a tool like Figma. There’s a plugin that works with our CMS that lets you take it from our CMS directly into Figma, and you can see how it’s being presented. So people then can collaborate and have that conversation about how the content is working with the UI design without having the UI design dictating what the content is.

Larry:
As you say that, now I’m curious about the tooling around this. You mentioned that your CMS has a plugin for Figma that helps manage that. And I know there’s tools like Ditto and Frontitude and others like that. Again, as the industry expert, what do you think the state of that tooling market is? Or do we have what we need or are you seeing room for improvement there?

Michael:
Well, I think there’s going to be room for improvement. So I think people have been using… They’ve realized that Figma itself is not very good for content. It wasn’t designed to manage content. So it has given rise to things like Frontitude or Ditto or plugins like that. The limitation I see for those kinds of tools is that they are not really content management systems. So they’re a midwife to the birth of the content, but you still got to get the content out of those things in order to deliver it, to deploy it, to get it delivered to customers. And so that’s a barrier. When you are able to connect your design or your front-end directly to a CMS like our CMS, kontent.ai, you don’t have that gap. You really have a single source of truth for your content.

Michael:
Everyone knows where the content lives. You’re able to see how all these different pieces of content are related to each other. And you get the big picture there, and you can see that maybe that button text that you’ve written is appearing across multiple designs and you don’t get that visibility now when you are really having a Figma first approach to how you’re developing this content. You have blinkers on you focused on that one screen and how that text appears on that one screen. And you don’t realize that there are other products out there that also need to convey that same message on that text and you need the ability to see how these other apps or our websites or whatever are going to use that text.

Michael:
So if you keep your content in the headless CMS, then you have that single source of truth and you’re able to govern this content in a way that just frankly isn’t being addressed right now when you’re starting your content development and Figma. It’s just not happening.

Larry:
No, that’s so important. Any kind of a design system is the operationalization of a bunch of design ideas, and that’s how you govern stuff is with that. And I’m thinking of even that example you just mentioned of the customer doesn’t care that you have different Figma files for how you’re designing these things. They just expect a fairly uniform experience when they’re doing an action, whether they’re in the app or at a kiosk, at a store or on the website or whatever. But we were talking a little bit before we went on the air about the role of design systems and the role of specifically of content and design systems around governance. You want to elaborate on that just a little bit, how it can help with that?

Michael:
Yeah. So what I see people doing with content and design system is that they’re providing some sort of guidelines that are potentially applicable across the board. So these are terms that we want to use, these are different phrases that we want to use, things of that nature. What we don’t see so much is very specific guidance, like, okay, we have a particular sequence that comes up as an onboarding sequence for example. A lot of the design systems won’t go into a lot of detail about what that content will be for that onboarding sequence, and if you start getting into more complex flows, the design system isn’t really designed to accommodate these things. Design systems are there for more universal components. That was the rationale for a design system really, is to reuse these components across different products. So we got to remember, that’s the purpose of the design system is that it’s not just there to support one product. It’s there to support multiple products where you have these recurring needs that are there across these different products.

Michael:
So we have other places we can do content governance, and for people who come from a content strategy background, which I know content strategy has become an uncool word these days, and I’m deeply pained that that’s the case, that there are people out there is like, “I don’t do content strategy, I’m a content designer.” Lovely, you’re a content designer, but you really are not going to be as good a content designer as you can be if you don’t tap into the incredible body of knowledge that’s been developed over the past 20 years almost in content strategy. And we have things like content models that help to relate all these different pieces of content that are being developed.

Michael:
So part of what a content designer does is develop some very specific and very important pieces of content, but we want to understand how all these pieces are related to one another, how they are reused across different use cases and scenarios, and that’s what a content model can do for us. Content strategy has a very rich tradition for looking at having standardized processes to handle the content lifecycle, for example. So it’s not just about developing very specific pieces of content to deliver for a particular release of a product, but we got to think about what happens to that content after the release of the product? When do we need to revise that content? When do we need to retire that content? Things like that. We have a rich tradition of looking at that and developing governance around that.

Michael:
And then our policies and procedures, things like that. We have a lot of work that’s been done in content strategy that I think that people who work in a content design role can leverage. But I’m bringing this up just to maybe set the expectation that the design system itself isn’t necessarily the right place to manage all that kind of governance. We have other kinds of tools that we can use, and when people look at a design system and want to see content reflected more in the design system, they may be trying to put things into the design system that design system was never really designed to accommodate.

Larry:
As you talk about that, I’m thinking I have this whole new lens on separation of concerns. Not that these are completely separate, but you have your strategy thing going on, you have your governance thing going on, you have your design thing going on. And just maybe for any one practitioner to be clear in your own head that those are maybe not separate and distinct things, but they’re separate concerns that you want to take into account in different ways. Is that correct interpretation?

Michael:
Yeah. They’re all things that are connected together, but they all deserve their own dedicated focus so that we can really understand the death of issues there and be able to iterate on these things and get better at them. So if we really just are trying to entirely ride on the coattails of a design system, which is really being ultimately decided by another discipline of people who are UI designers and front-end developers, then we’re not really owning these issues that we ourselves need to claim ownership for and be able to improve, and also just plant our flag and say saying, “No, we are the source of truth on the lifecycle for the content, and we have a way of managing that.” And we’re not going to try to just put an appendix to the design system that maybe is not going to be read by people because people are expecting the design system to tell them what tokens to use for different widgets that they’re producing.

Larry:
I got to say, you’re getting me a little riled up because you’re speaking to the choir here, and I’m like, you’re giving me more things to get riled up. Anyhow, we’ll save that for another podcast episode. But, hey, one thing I wanted to circle back to, you mentioned the word variance a while back in the context of localization, and that’s something that’s accounted for in Figma. There’s ways you can have variance on components in there, and just as you can have a variant of a design component in Figma, you can have a variant of a content element in a CMS, and localization being the current one, but are there other kinds of variations, variants that you can account for in a CMS?

Michael:
Oh my heavens, yes. And that’s really why it’s important to manage this from the perspective of having a content model that’s defining the structure of the content. And then you can decide where you want to have variations and why you’d want to have those variations and even develop guidelines around when to use different variations. So besides localization, we have variations, anything relating to personalization. And personalization is one of these things that is a hard thing to get right, and the reason people don’t get it right is because they generally don’t have the content in place to deliver the right personalization.

Michael:
But these are things not just where you’re located or are things like that, but it’s what products that you use and getting very specific about what content you would want to see, having certain products that you use or all kinds of things can be personalized. And we’re not talking the kind of trivial things like, “Hi Larry,” but it’s much more about what’s going to be relevant to you that’s not going to be relevant to someone else? And thinking not about the big blob of the user out there who has this loosely defined persona, but getting very specific about what it is that different individuals need at different points in time.

Michael:
And so we get a lot more control by having a structure around the content about what we present to people at different stages of their journey. We can start thinking about what they’ve seen already, what they know already, what their likely next action is going to be, what maybe people with different dispositions may… Some people may be ready to take that next action. Other people may need to get a little more detail in depth, thinking about their comfort levels, their knowledge levels, all these kinds of things are things that we can start defining as variants. And we can start defining variant images as well, depending upon the needs, people may need to see different things or certain things may be more appropriate for certain kinds of users and for other kinds of users. So a lot of detail to define there.

Larry:
So I have our next episode planned already around personalization. But hey Michael, we’re already coming up on time. These always go way too fast and especially with you, but it could go for hours. But hey, before we wrap up, is there anything last, anything that’s come up in the conversation that you want to revisit or just anything that’s on your mind about design systems and content?

Michael:
Yeah. I would really encourage people to really… If you’re a content designer who’s working with your colleagues in other UX roles, really have a conversation about where that content is being stored and how it’s being stored because I think it can get a little technical sometimes, and maybe people will defer to their colleagues that they know best about how these things are done, but I’ll tell you that a lot of teams are doing things like they’re storing the content that appears in apps, say in a GitHub repository. And I’ll tell you that is not really a very scalable solution. It does tend to fragment what works of different teams are doing. There are a lot of issues there.

Michael:
So it may feel a very comfortable thing for developers right now. They’re just focusing on getting that next release out, but it would really be useful to have a conversation like could there be a smarter way to store that content and have it accessible to people on the content team and have it accessible across different teams and allow the content people to do things that are not going to be creating cross interference with the UI design team because we have the benefit of the decoupling there?

Larry:
Yep. No, that’s a great articulation of the benefits of decoupling to wrap up. Well, thanks so much, Michael. Oh hey, one very last thing before we wrap. What’s the best way for folks to stay in touch, to follow you online or to get in touch if they want to contact you?

Michael:
So I used to be active on Twitter, but a lot of folks, I’ve basically really gotten a little disillusioned with Twitter, so I’m not on there very much, but the best place to find me is with LinkedIn. You can just look for me, Michael Andrews. I’m at kontent.ai, kontent with a K, and I’m happy to connect with any of my peers in the industry and I’d love to have conversations arising from that. So please do reach out to me.

Larry:
Great. I’ll put that in the show notes as well. Well, thanks so much, Michael. I really enjoyed the conversation.

Michael:
Thank you, Larry. Really enjoyed it myself.