Rebekah Wolf: Including Content Design in Design Systems – Episode 142

Podcast: Play in new window | Download

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

Content has always been a key element of any design system, but content designers have only recently become part of these system teams.

It’s still early days, but the role of content in design systems is evolving rapidly. Rebekah Wolf has been part of that evolution through her work as a content designer on Microsoft’s Fluent design system. She has also built a professional community around the subject with the Design System Content Club Slack that she founded and facilitates.

We talked about:

• the Design System Content Club community Slack that she facilitates
• her take on the state of the discipline of content in design systems
• how to get design system leaders to invest in content
• her content-design work on Microsoft’s design system
• the need to educate executive sponsors of design systems the value of content
• how to deal with the challenges of inheriting design-system content that was created without a content designer’s help
• the benefits of including guidance elements like decision trees in design-system content
• the importance of including practices like journey mapping as you are designing content for design systems
• her thoughts on evangelism, onboarding, outreach, and other communication around design-system content – and the importance of leadership support for this
• the difficulty of measuring and analyzing design-system content creation and use
• the importance of remembering that content work in design systems is still a new and growing field and that you are not alone

Rebekah’s bio

Rebekah Wolf has years of experience leading content design and strategy for Microsoft’s Fluent Design System and scaling content design across the company. When she’s not busy advocating for content design and applying systems thinking at Microsoft, she facilitates the Design Systems Content Club Slack and supports others in their design system journey.

Connect with Rebekah online

• Design System Content Club Slack
• LinkedIn

Video

Here’s the video version of our conversation:

Podcast intro transcript

This is the Content Strategy Insights podcast, episode number 142. When you think about design systems, things like component libraries and design tokens probably come to mind. But content is arguably the most important element in any design system. Like any product, a design system benefits when content designers guide users – in this case, internal users of the system – on their journey. Rebekah Wolf has done a lot of content work in design systems, and she facilitates a vibrant Slack community, the Design System Content Club.

Interview transcript

Larry:
Hey, everyone. Welcome to episode number 142 of the Content Strategy Insights podcast. I am really happy today to welcome to the show, Rebekah Wolf. Rebekah is the facilitator of the Design System Content Club Slack, and has done a lot of work on content and design systems. So welcome, Rebekah. Tell the folks a little bit more about your work on the Slack channel and in the design system world.

Rebekah:
Yeah, thanks for having me, Larry. So I am, like you said, the facilitator of the Design System Content Club on Slack, and this is a global community of content designers and content strategists who are either seasoned pros when it comes to design systems or they’re just starting to get into the design system world and looking for ways to contribute and share ideas and collaborate with other people.

Rebekah:
And it’s grown leaps and bounds really organically, but it’s still kind of a really close-knit community, even though it’s so big. We share a lot of information on the Slack channel and then we have monthly, or maybe semi-monthly meetups where we talk about different topics related to design systems that we’re all interested in. And, yeah, it’s been this really great way to collaborate in an area where a lot of us are working in silos.

Larry:
I love that.

Rebekah:
It’s been really fun.

Larry:
Yeah, I mean, there were a lot of reasons I wanted to have you on the podcast, but my whole point here is to democratize the principles and practices of what we’re all up to. And you have a unique view on that in there. I can remember not that long ago that you didn’t even hear about content people on design system teams and now you have this vibrant growing Slack community.

Larry:
What’s your feel for where are we at? Do we have a lot of people? Are there enough content people in design system work or do we need more, need fewer, need different? I guess what’s the state of the discipline of content in design systems?

Rebekah:
Yeah, I feel like we are still in really early days when it comes to content design for design systems. I feel like content design itself as a practice for UX is still fairly early. So it kind of makes sense that we’re just starting to understand that we need to be integrating content designers and content strategists more into the design systems. Right now it feels like maybe there’s one content designer working on the design system at different companies, maybe two. And then at a lot of places it’s just a content designer working on a product team that has an interest in design system work and wants to contribute wherever they can, but it’s really just kind of a side project for them. It’s not something that they’re fully invested in.

Rebekah:
So we have a long way to go, but it feels like we’re on the right track. It feels like a lot of places are really starting to understand that this is integral in a design system functioning the way it should.

Larry:
We probably have enough examples of places that do and don’t have content people in their design systems. Are there any real hallmarks or things that jump out in places that do have content people involved?

Rebekah:
Yeah, the places that I, over the years, turn to a lot for guidance on how things should be done the right way are Atlassian’s design system, and there’s Shopify,’s Polaris design system. Intuit has an excellent, not only design system, but a content system for its products.

Rebekah:
And then recently I kind of put out a call on LinkedIn about how design systems are funding content design, and turns out those are actually the gold standards. They’re actually fully investing in content design with not just one content designer, but in a lot of areas two content designers, which I feel like is still not enough, but it’s way better than a lot of places are doing. So it’s exciting to see that these gold standard places are the ones that are investing more in content design.

Larry:
That’s interesting. Most of the places I’m aware of just have one, if you’re lucky. I’m curious about the places that have two or more content designers. Do they specialize in different parts of the design system or do they pick up each other’s workload? Is there a emerging trend there, or…?

Rebekah:
Yeah, that’s an excellent question. And I mean part of the reason I put out that question on LinkedIn was so that I could connect with those content designers who are working on those design systems and figure out what the strategy is and how they’re involved, and how do they get those design system leaders to really invest in the system? What does that process of influencing people who are at the top, who might not be as aware of what content design is? So I don’t have any clear answers yet, but that’s kind of what I’m after right now. I’m trying to figure those things out.

Larry:
That kind of what you just said kind of echoes what’s been happening with content design in general, like just figuring out how to get the resources to get enough content designers to serve products well. And I guess in a sense, a design system is just another product and so in that sense, getting people involved, but it does seem, because the users of that product are internal, it seems like it’s a little bit different. Are there unique challenges to getting staffing for design systems, do you think?

Rebekah:
Yeah, I can really only speak to the challenges that I’ve faced at Microsoft with our design system. One area is that I feel like it maybe not thought about as much athe return on investment is. What is the value that a design system brings to its users? Which is hopefully the entire company, not just designers, but engineers, PMs, any stakeholders that need to have reusable components and patterns.

Rebekah:
And I think right now one of the problems is that we don’t have really any consistency when it comes to how we’re approaching those problems and the understanding of what content design brings to solving those problems as well. So it’s really, we need to be a little more focused on educating the people who are at the top, who are funding these roles, and how to do it in a way that will bring the most impact and value to everybody who’s using the system. So helping them understand not only who should be contributing to it in a really focused way, but what is the value in doing that?

Larry:
Yeah, the way you’re talking, you’re reminding me of the generic benefits of a design system, the main two I think being consistency and efficiency. And you’re doing that for internal teams, so it seems like the impact of this kind of work, it seems like if you were deciding on staffing, it seems like it’d probably make more sense or as much sense if you had a limited budget to fund the content designer in the design system over anybody in any one particular customer facing product. Or am I jumping ahead of myself there?

Rebekah:
No, I think that that’s true. I mean, we have to start with the design system. I mean, that’s the foundation for all of the products. And what I found with the Microsoft Fluent design system is that the core components that were originally built were not built with content design in mind.

Rebekah:
So whenever I was working on Power Apps for Microsoft, years ago I saw that the components, the high value components that are used in all of our products, things like dialogues and message bars were not built in a way that supported the content. And content in my mind is the main piece of the product. It’s how we’re communicating with customers. And if it’s not done in a cohesive way, it can lead to confusion. It can lead to uncertainty. It can lead to a lot of problems. And that’s just one area of content design for a design system.

Rebekah:
So if we’re fully investing in that design system with content design, it will have this trickle-down effect where the designers, if they’re not working with a content designer on their product, they will at least have that foundation already built in and be able to create the right content for their product.

Larry:
Right. And the way you just said that, something you just said about the way… You kind of inherited some of the components that you talked about earlier. And I’ve also heard you talk in other contexts about collaboratively working with designers and other people in the design system team to develop components. It seems like the latter is probably better to the design from the front, so you’re not inheriting like what you did, but both happen all the time. Can you talk a little bit about contrasting those scenarios? You probably are going to be tasked with working in both situations, but I’m imagining the approach must be a little bit different.

Rebekah:
Yeah, so whenever I came into the design system work at Microsoft, none of the components were built with a content designer. So I was looking at a lot of issues with not only how the component looked, but how people were writing content inside of that component and the lack of continuity through content patterns.

Rebekah:
So I was sort of starting from the wrong direction in my mind. In my mind, this component would’ve been built with a content designer, and then that content designer could make sure it would work with a variety of different content needs and scenarios. And then we could bake in some standard content patterns, like title case versus sentence, case, punctuation, headings, things like that. And then also have those that content guidance that’s specific for the component or pattern.

Rebekah:
So whenever I joined, I was kind of working backwards to figure out how to create that guidance, then bake in those content patterns into the system by going into the UI kit and making sure things weren’t title case or had end punctuation where we didn’t need it, things like that. And then as I saw opportunities to build a variance of a component and do it in a way that took the content into consideration, I would partner with interaction designers and engineers to build a component that actually worked for the content.

Rebekah:
And fortunately in the last year, Microsoft has been working on the next version of their design system. And so a lot of these components are being built from the ground up, and I’ve been able to prioritize the components that are high value in terms of content. So things like dialogues, message bars, toasts, building the notification framework, things like that and making sure it’s done the right way with content design. But that does mean that there are components that have to be deprioritized and don’t get content design, that content design love, because I’m only one person and I can’t get to all of them. But that kind of speaks to the need of having multiple content designers working on a design system.

Larry:
Yeah, and that’s such a common scenario you just described as well. And it seems like one of the outcomes of that is often, “Hey, can we have more of you? That was so great.” I hope that’s the case with that.

Larry:
Hey, but I wonder, I just realized we’ve been talking at pretty high level about how to organize design systems and how to strategize about how to get things in there. I’ve heard you talk about a couple of particular things you’ve done in design systems that I really want to elaborate on. When you talked at the Seattle content strategy meet up a while back, the longest list of unanswered questions we had was around your comment around creating decision trees to help designers decide which component to use and how.
Anyhow, can you talk a little bit about that? I think of that as kind of meta guidance or something, but can you talk a little bit about that?

Rebekah:
Yeah, I feel like decision trees are really underused in a design system. I don’t see a ton of design systems that have them, and maybe they’re more internal. They’re not on their public sites and that’s why. But decision trees really resonate with our designers in helping them validate that they’re on the right path when it comes to choosing the right component.

Rebekah:
I noticed that early on we were getting a lot of questions around, “Do I use the message bar versus a toast or a dialogue? Do I use placeholder text versus helper text versus an info icon and a oral call out?” And a decision tree is a great way to help people make the right decision quickly and also validate that they’re on the right component before they even dive into that documentation, because that the scanning the documentation in won’t necessarily help that designer understand that they’re on the right component. They need something kind of a step ahead where it’s like, “Okay, got it. If I go through this decision tree, I know for a fact that I’m on the right component.”

Rebekah:
And then it also kind of doubles down on that coherence across our products and making sure that the customer is getting the same experience no matter what product they’re in or what area of the product they’re in. We’re using the same pattern or component to communicate whatever it is we need to communicate to them. So yeah, they’ve been super, super helpful for our teams.

Larry:
And that’s what you’re reminding me as you talk about that, about the importance of identifying the tasks that they’re trying to… Or the mission they’re trying to accomplish and doing the right tasks to get there. Another thing I’ve heard you talk about is kind of journey mapping and journey discovery for design systems folks. And it seems like, are those seem to me be in the same family, like a journey is just a bunch of tasks? Kind of like what you were talking about. Do you see that the same way or does your journey work a little different?

Rebekah:
Do you mean as far as how our designers and engineers whizz through the design system?

Larry:
Yes, exactly.

Rebekah:
Yeah.

Larry:
When you do customer journey mapping, but your customers are the designers and engineers, using the design system.

Rebekah:
Yeah, yeah. The decision trees are definitely part of it. I think that journey mapping is another area of content strategy that needs a lot more attention because what I’ve seen at Microsoft, which is a huge company with a massive ecosystem when it comes to the design system. So I mean that’s like the core UI kit that has all of the high value components that all of our products need. And then we have these extensions of the design system for different product groups who might have more individual scenarios that they need to account for.

Rebekah:
And then we have these bespoke UI kits for individual products where they might have these really niche scenarios that they need to account for in their product. And unfortunately, I don’t think that a lot of design systems put enough thought in how our users, which are designers, engineers, PMs, move through that journey so that we can help them validate that they’re in the right place and they’re using the right thing for the job. But that’s one area that I would love to spend more time diving into because I think that that’s kind of the starting point. How do people move through a design system, and how do we make sure that they’re confident that they’re in the right place?

Larry:
Yeah, as you’re talking about that, I’m now thinking of you’re that work and the decision trees is like information architecture wayfinding or learning sort of like a tutorial, contextual tutorial stuff to help people through. But it’s all about that, like you said, helping them wherever they are in that journey of creating this component or whatever other tasks they’re doing in the design system.

Rebekah:
Yeah.

Larry:
And that just mentioning that makes me think about, another thing I’ve heard you talk about, I think you mentioned this in another conversation someplace, was that notion of just the general approach to education and onboarding and even outreach and evangelism about the design system. Do you have an approach to that as you’re working with both content designers and other folks on the design system?

Rebekah:
Yeah. One area that I think Microsoft does a really great job that I think a lot of companies could do if they’re not already doing it is having a monthly meeting where people can share what’s happening with the design system and how to contribute. And people can also share their individual contributions, like if they’ve recently built a new pattern for the design system that they want to share. Microsoft does this for the entire design community at Microsoft, so everybody has an opportunity to learn about the design system. So that’s one way.

Rebekah:
And then I regularly meet with content designers who are newer to the organization, to make sure that they are aware that this design system is for them as much as it is for their design partners and their PMs and their engineers. Our design system has dedicated content guidance for every component, and I think that’s so helpful for new designers to understand so that they can hit the ground running and feel like they’re making impact a little more quickly. But it really requires continuous education and evangelism and just listening to what our user’s needs are and allowing them to provide feedback on how the design system can benefit them even more.

Rebekah:
And then having a really solid design PM can go a long way. That’s another area of funding that design systems need, is that design PM can make sure that evangelism and presentations and that sort of thing are part of the rhythm of business for the design system team. So it doesn’t get kind of lost in all of the other day-to-day work that we have to do.

Larry:
Right, as you were talking just then, I was wondering, you you’re really super aware, hyper aware of your users, which is awesome. That’s how we are as designers. That’s just how we are. And among those, I’m just curious, as you’re talking about so much of this content, you said you have content guidance for every component in there, and it’s often designers and engineers that you’re working with. All of a sudden. I’m wondering what percentage of the content in products that you’ve worked with was written by a content designer? What percentage of it was written by a designer or an engineer following the guidance that you provided?

Rebekah:
Yeah, that’s an excellent question. Man, I wish I’d been asking that in our user studies. I should definitely circle back and make sure that’s part of our surveys or our user studies. And yeah, I don’t know the answer to that, but my hope is that it’s being used by our interaction designers and engineers as it is by the content designers.

Rebekah:
And I know that I’ve pointed interaction designers and engineers to that guidance, and I know that whenever I’ve worked with engineers on building components and creating that usage guidance for content, they have been really appreciative of having that context instead of having just like lorem ipsum inside of a component that they’re building, like a prototype. I think it’s really beneficial to everybody, but it would be good to have some actual data to back that up.

Larry:
Yeah, and I was brainstorming in my own head as you were talking about the data that you might get around that, and then it occurred to me it’s probably futile because everything is so collaborative nowadays that you could probably never sort out who wrote that letter, that word, that phrase.

Rebekah:
Yeah, yeah. And then a lot of it is like living in Figma, at least at Microsoft, so it’s hard to get the analytics on how many people are opening which file and which people are opening which file? But yeah,, a lot of it is just anecdotal, just how we’re talking with people and what we hear as far as what people are looking for, what their needs are, that sort of thing.

Larry:
Yeah, and I’ve done enough of that stuff to realize that we probably need new tooling that I think the Figma reporting is pretty rudimentary about basically just who’s using what components or elements. Not much on that.

Rebekah:
Yeah, exactly.

Larry:
Yeah. Hey, Rebekah, I can’t believe it. We’re already coming up close to time and I can think of five more conversations I want to have, but I’d like to keep these around a half an hour. But before we wrap, is there anything left, anything that’s that we haven’t got to yet or that’s come up in the conversation that you want to make sure we get to before we wrap up?

Rebekah:
Yeah, I mean there’s so many things. This time just kind of flew by. One thing that I want to say is, if you’re working on a design system on your own as a content designer, just know that you are laying the foundation for showing the value that your role brings to that design system. You’re not alone. We’re all kind of in this together, and this is still early days. I think we’re going to get to a point where the leaders who are funding this area of content design will start to understand that it’s a critical space to fund, and it requires really a team of content designers working on it. There’s so much space that needs coverage.

Rebekah:
So yeah, don’t lose hope. You’re doing a great job, and I can’t wait to see where this goes in the future. I think it’s going to be a really amazing thing for companies and supporting their teams and also supporting their customers.
And if you want to collaborate with other content designers who are working on similar things, join the Design System Content Club, Slack. We’re all very supportive of each other. No question is off the table. We love just sharing what we know and our approach and helping each other kind of move forward in whatever space that they’re in.

Larry:
Yeah, it’s a great community. I will second that recommendation to get in there, and I will definitely link to that in the show notes as well.

Rebekah:
Awesome.

Larry:
Rebekah, I have to say one thing, just one of the many conversations that I would love to follow up on is just as you were talking a second ago about just the need for multiple content roles on a design system team, just the scope of content strategy needs seems… Anyhow, let’s pencil that in for a visit again in a year or so, maybe. See if we can make progress on that.

Rebekah:
Yeah, yeah. That would be great. And yeah, I’d love to share my approach to just skimming the surface of all of those different needs as a single content designer, and then what we could do if we had a whole team working on that. It would be amazing to see the amount of ground that we could cover and how we could really create a design system that is built for everyone and has even more impact.

Larry:
That’s a great vision to leave this with. Thanks so much, Rebekah. I really enjoyed the conversation.

Rebekah:
Yeah, thank you so much, Larry. It was great talking with you.