Podcast: Play in new window | Download
Subscribe: Apple Podcasts | Google Podcasts | Stitcher | TuneIn | RSS
Nicole MichaelisDesign systems are quickly being adopted across companies of all sizes and types, from big enterprises to burgeoning startups.
As in all digital practices, content is a crucial element in these systems.
Nicole Michaelis has worked with content in design systems for many years and has learned a lot about how to create and manage the content that powers design systems.
We talked about:
- her journey into UX writing
- how her brief stint as a material engineering student helped to prepare her for a UX career
- her transition from her first job into a career as an independent content professional
- her description of a design system: a set of standards that helps companies scale their design efforts
- how she sees content fitting into design systems
- the importance of keeping design systems up to date, and how content strategy can help with this
- the role of string management in design systems and related tooling systems
- how basic writing guidance can help both writers and non-writers create good UI strings
- the ideal situation where the relationship between content designers and engineers is equal
- the benefits of having staff dedicated to tooling for string management
- how reaching out to folks who are working with the technical side of the design system can help content designers
- the importance of aligning content strings across multiple platforms and in localization programs
- how to work with engineers to help them improve their documentation-writing skills
- her advice to content professionals: “don’t be afraid of the design system”
Nicole’s bio
Nicole Michaelis is a Senior UX Writer at Spotify with 10+ years of Content Design and Content Marketing experience under her belt. Among other things, she hosts the Content Rookie podcast on all things copy and content and teaches at Berghs School of Communication.
Connect with Nicole online
Video
Here’s the video version of our conversation:
Podcast intro transcript
This is the Content Strategy Insights podcast, episode number 113. Over the past several years, design systems have been adopted by companies of all shapes and sizes. Content plays a number of important roles in these systems. Nicole Michaelis has done content work both with and for several design systems in many roles. She has helped everyone from engineers and localization specialists to designers and content strategists create and manage the user-interface strings and other content that drive modern design systems.
Interview transcript
Larry:
Hi, everyone. Welcome to episode number 113 of the Content Strategy Insights podcast. I am really happy today to have with us Nicole Michaelis. Nicole does a lot of stuff. She’s a Senior UX Writer at Spotify. She’s done a lot of work with startups and other businesses, helping them with content strategy, UX, and marketing communication. She teaches a course on content marketing at the Berghs School of Communication in Austria. Anyhow, she’s a very highly accomplished person. Also, does a podcast called the Content Rookie podcast. Welcome to the show, Nicole. Tell the folks a little bit more about what you’re up to these days.
Nicole:
Yay, thanks for having me, Larry. I know that was a tough introduction with all the different things I do, so I appreciate you taking the time to talk the listeners through it. Thanks so much for having me. I’m really excited to be here.
Larry:
Cool. Well, you have, like everybody in this field has an interesting journey in. Nobody just went to UX writing school or content design school and started doing this. Tell us a little bit about how you ended up as a UX writer.
Nicole:
Yeah. It was a long journey that I never anticipated really happening. I graduated back in 2009 from high school. My dad is a professor in physics, so he was very eager, I’m the oldest of four sisters, for me to study physics or maybe engineering if I don’t want to do physics. I actually ended up studying material engineering for the first two years of my, well, after school life. Absolutely hated it, I’m not going to lie. Wasn’t my thing. Wasn’t really into engineering. Was pretty much the only girl of among 73 guys, I think, that were studying that, so it was pretty tough and I ended up leaving after I graduated from my pre-diploma.
Nicole:
It did, however, provide me with what I like to say, good communication skills to talk with engineers or people that have a very technical mindset. That’s something that, later on when I transitioned into UX officially, really, really helped me. Like, communicate with stakeholders, break down UX problems into ways that, really, everyone you are collaborating with, like a PM, a developer, a designer can really grasp them. That’s really helped me later on. Anyhow, after I left engineering, I actually went to business school, because at that point I was like, “Okay, well the one thing that I know for sure that would interest me as a career is maybe starting my own business, or working for startups, really getting like my hands dirty, doing a lot of stuff.”
Nicole:
In business school, I specialized in strategy, storytelling, and marketing, and that’s kind of what got me started on, “Hmm, okay, I’m pretty good at this like strategy/storytelling kind of stuff,” and that’s when I first started freelancing as a copywriter, as a content marketer. Back then, honestly, it wasn’t even that defined yet, all those different titles. I also have to say I went to business school in Germany, which generally was a little bit behind when it comes to digital stuff back then. UX wasn’t even a thing that I heard around, 2010, 2011. I was already doing kind of a lot of UX writing for flows for little startup companies or for companies that were starting to go more digital and provide more digital services, but it wasn’t really called that.
Nicole:
Then I moved to Sweden. This is where I studied my masters. My masters was officially in marketing, but already there, I focused a lot on consumer research and strategy, again, already knowing that I was probably going to dive into more content marketing and UX work. While I was doing my masters, I was already working for startups here as well, where I was doing a lot of that hands on work. Yeah, that’s kind of the move from all the way back from engineering to now UX. I will clarify, I have no official UX training. I didn’t go to UX school. I didn’t go to design school, even though I will say that my first job after my master’s degree actually was, that I worked as a content marketer at Hyper Island, which is a pretty big school here in Sweden, and they also have locations, for example, in South America and the US, and they teach a lot of UX. That was really interesting for me as well, to kind of work there and see how these people were coming in passionate about design and UX, and how they were learning it. I picked a lot of stuff up there, doing kind of on the side beside my work and talking to folks. But, yeah.
Nicole:
Then, essentially, Hyper Island was kind of my first and my last job, because then I officially was like, I just want to freelance from here, and I started working with a lot of different tech companies throughout my career, where I essentially dove right into UX writing work, some content strategy work, some content marketing work, but kind of always trying to bring the two together. I actually think that the content marketing lens is really useful for UX writing as well, and the other way around. Yeah, for the last, a little bit more than two years, I’ve been working at Spotify as a UX writer, currently on the design systems team, which is really exciting. Yeah, that’s kind of where my journey’s right now.
Larry:
Very cool. That’s a great story, and it’s more details and more interesting, not sidetracks, but you have the perfect blend of, this whole thing is about technical stuff, business stuff, content stuff. The way you just described it, wow, that’s fine. It’s like, that’s better than going to UX school, I think, the way you described it. I also like the way you described the combination of strategy plus storytelling, because when you try at cocktail parties, or wherever, when you’re trying to explain to your mom, what content strategy is or UX writing, or any of these content professions we’re in, that’s the most succinct definition I’ve heard, strategy storytelling. Just those two things, because people understand those words, that maybe that’ll get them off your back when they’re asking for an explanation.
Larry:
But, anyhow, the last thing you said really interested me, because it’s an interest of mine too, this work with content in design systems. I think design systems are a fairly new thing. I mean, we’ve all been working with pattern libraries and things like that for years, but the notion of a dedicated design system in organizations is a newer concept. Can you tell the folks a little bit about how you would describe a design system?
Nicole:
Yeah, I mean, I would say a design system kind of sets the standard to help everyone that works at a company manage design, and kind of manage scaling, because a lot of the companies that I’ve worked for, coming from specifically a tech startup background, a lot of those companies go into hyper growth. They hire a lot of people really quickly, they add new disciplines, and they somehow need to make all of that work scale, while still maintaining quality standards and ensuring they have resources like components and patterns that all of these people can reuse without reinventing the wheel over and over again. That was probably not a very great definition . . .
Larry:
Well no, but it certainly gets at the problem space, that it’s like, you can’t reinvent the wheel every time you design an app page or a webpage or any kind of interaction. That’s sort of the point of a design system, right, is to reuse things rather than reinvent the wheel.
Nicole:
Exactly. I think it becomes specifically interesting when we’re looking at product companies that maybe work across a lot of different devices, have to work for a lot of different types of users, because then it really becomes a lot about, okay, how do we actually create patterns that work on an Apple Watch that maybe also work in your car, that maybe also work when you’re using your voice to communicate with a device to start an app, for example, or interact with a product. I think that’s where it becomes really interesting and also really obvious that, okay, we definitely need a system for this, we definitely need to create a standard here that essentially supplies patterns and components to anyone working with a product; engineers, designers, writers.
Nicole:
I personally also have the opinion that, even beyond product teams, people can really benefit from a design system. When I was still working more with marketing content, I really appreciated working with companies that had a design system, because personally, I think even the design and writing guidelines for the product, intended for the product helped me communicate better when I was, for example, sending automated emails, and things like that.
Larry:
Oh, I love that. Because, I think most, I don’t know if this is true, but I think most people would think of it as design systems as mostly guiding layout and font and typography and color decisions across web and mobile apps. But, the way you just said that, that accounting for micro devices like watches and IOT stuff and voice stuff in there. But, one thing that’s common across all of those interactions and all those platforms and all of the other ways that design and engineering come together, is content. The content is everywhere, as Sarah Wachter-Boettcher famously once said. Tell me a little bit about, how do you see content fitting into design systems?
Nicole:
Yeah. I mean, I agree with you, content is everywhere. I think content is such a key component for design systems, that I am always shocked when I talk to someone at a company that has a design system, but they do not have a content designer or writer on the design systems team. I’m like, why are you doing, people? Probably your information architecture could be better. It could be easier to navigate and find things. You could probably scale down on some of the documentation you have, standardize better, things like that. Yes, definitely a great content design is a huge part of it.
Nicole:
I think it touches upon so many elements of the design system, like I mentioned earlier on, just figuring out, how do we actually present the design system? Does it live on a site? Does it maybe live in Figma, which is usually a tool that a lot of designers use directly? How do we navigate it? How do people find it? What’s the information architecture? Do we just have everything on one level? Are there sub-levels? A lot of bigger companies that even have different design systems, they will have one for the web, one for the mobile, one for partner platforms, things like that. How do you connect all of those dots?
Nicole:
How do you make updates to the design system? I think this is something that is often really overlooked. The design system is not a one time effort. It’s something that constantly needs to be updated and well kept, so how do you contribute to it? How do you make sure things are up to date? That’s a big question that I think content strategy can really help with. Then things like, how do you actually communicate about the design system? How do you onboard people to use it? How do you communicate updates? How do you communicate changes? Both bigger changes, like let’s say you’ve completely changed your iconography, as well as smaller changes, like, okay, we’ve edited some of the documentation here to make it a little bit tighter, easier to use. I think all of those are pretty obvious content design questions, so yeah, I think content is really important part of it.
Larry:
The list you just enumerated there, it’s like, that’s a lot of stuff. As you said, there’s not a content person on most design system teams, and I haven’t seen that many of them, but I can imagine all of the issues that you just described, because everything from documentation to the communication about changes in the documentation, everything in between. One thing that I don’t think I heard you say in much detail, anyway, is so much of what we’re talking about is back office stuff. This is all internal, the end user never sees this. This is all enterprise-level communication about how to do things. The thing that the end user sees is the actual strings of copy and button notices and things like that, that show up in the application. Have you had experience with creating and managing and updating that kind of content?
Nicole:
Yeah. I think string management, of course, is a very big part of a design system. Again, at least according to my experience, also unfortunately something that is often underutilized in design systems, just because as there’s often so many different user cases that it can be really difficult to actually write out all of those strings, especially to make them useful for different devices and different teams. I can definitely say that there’s a lot of tooling solutions that can help with string management to make it easier for writers across an organization to really contribute to the design system, and to make sure that copy strings are updated. I have also worked at, and these were smaller companies, where I did manage this myself where it was, for example, easier to say, okay, these are our standardized error messages, and write out those strings and make them accessible via the design system. But, in my experience, it doesn’t work for bigger product companies that have a lot of different devices and work across a lot of different platforms with a lot of writers and different designers.
Nicole:
What I will say is that I think a good design system does include a lot of basic writing guidance that can really help with string management as well. Things like talking about inclusive language, talking about what’s accessible language, what are accessible terms. Really writing out things like a glossary. These are terms we want to refer to throughout the product, these are terms we want to avoid in our product. Writing out things like, how do we actually help users navigate from one frame to the next? For example, do we like to go to X on a button, or would we rather just write next or continue? To really make those decisions more centralized, when there maybe isn’t tooling available yet for proper string management. I think that’s a big part of the content in the design system as well.
Larry:
There’s a lot of different people who have their hands on that string creation process. It could be anything from an engineer to a designer, to hopefully a content designer. How have you seen the workload around content and design systems break out?
Nicole:
Yeah, I mean, I’ve worked with a couple of design systems now, and without wanting to call anything out specifically, but I think what I’ve seen worked well in the past is when the relationship between the content designer and the engineer is pretty much equal, so that these two parties can really communicate with each other. Engineers usually have a very specific perspective on how they would like strings to look, while for a content designer, sometimes it can be quite difficult to grasp. Like, what does the string even mean? In the beginning when I was working with design systems, I sometimes went into a meeting with an engineer, and I was like, “We just need to update the copy and the string. It’s so obvious, it’s so bad,” and then the engineer was like, “Whoa, whoa, whoa, wait. There is actually all these scenarios and all this context around the string. It’s not as simple as updating it.” Now I’m not actually sure if I’m answering your question. . .
Larry:
Well, no, but you’re raising a super interesting issue, that it’s not just about, I mean, that’s one of the things that comes up all the time in discussions of content design, is you’re not just sprinkling the magic word dust on at the end.
Nicole:
No, exactly.
Larry:
That, it’s ideally best an integrated practice where you’re talking to that engineer and that designer early on to understand, “Oh, okay, that’s what’s going on here. Well, here’s the right words for that.” Is that kind of what you were getting at, that example you just gave with the engineer saying, “Whoa, whoa, whoa, that’s not what that means.”
Nicole:
Exactly. I think this is what makes string management so complex. It’s that, to you as the writer, it maybe just looks obviously like, “Okay, we just need to switch out this preposition in this string that we’re using across the product,” but the engineer may have additional context that makes you understand that, that’s not going to work. It’s going to break some parts of the product. Or, there’s even potential for more complexity when we’re talking about localization and how that’s addressed in the design system. Because, if you change the English string, suddenly it can break in a bunch of different languages.
Nicole:
Yeah, my big take on this is, String management is complicated. There’s a lot of tools that can help with it. I’ve seen it work well when there’s people dedicated to actual tooling for string management. Outside of just, this is something that engineers and content designers and designers just do on the side, there’s people who just essentially look at the technical side of things. How do we manage strings and make it easier to work with complicated scenarios and make those decisions faster? But, yeah, I think a really tight collaboration between writing, engineering, and design is super vital, especially in a design system field.
Larry:
Yeah. Hey, and you’ve mentioned a couple times tooling around string management, and I know that there’s Strings and Ditto and Frontitude, and I think there are other products out there as well in various plugins for Figma and other design tools. Have you worked with any of those, or do you have thoughts about any of those tools?
Nicole:
I mean, there’s so many different tools that I don’t really want to call any tool out as being better than another, because it really depends on how your design system is built. For example, if it’s integrated directly into Figma, you’ll use a completely different system than as if it live on a site, for example, on a website. A lot of those contexts really play into it, as well as how many platforms are you serving with your design system. But, I think if you’re interested in this more technical part of design system work, just type in string management tools into Google, or even YouTube, YouTube has some really great walkthroughs and also some great design systems where you can see in action how their backend works.
Nicole:
That was really what I did when I first started reading into this topic, and I thought it was really helpful. I can also really recommend, if you’re interested in working with design systems, or you may be working with design systems and you want to learn more and you want to see how you can scale your work, reach out to folks that are working with the technical side of the design system, for example, on LinkedIn or on Twitter, because having those conversations can give you so many aha moments, that, that was really helpful for me as well.
Larry:
I’ll just observe that, that’s how this podcast came to be. You posted something on Twitter and we started a conversation, and here we are on a podcast together.
Nicole:
Exactly.
Larry:
Yeah, exactly. Well hey, what about, rather than specific tools, are there categories of tools? I’m thinking, those three I just mentioned are specifically for product string management. There’s also localization tools, which have been around for years that do a lot of string management. Then there’s the good old fashioned spreadsheet and text files. I know a lot of people who still manage strings that way. Are there other categories, or how would you categorize the different ways to, or the different aspects of string management, and not just string management, maybe even process management around design system content?
Nicole:
Yeah. I mean, I definitely think there’s a lot of different categories. I think the most vital one in the companies that I’ve worked with, which again have mostly been bigger product companies, is just multi-platform string management. What I mentioned earlier in the podcast, how do you actually make sense of a string that needs to make sense on Apple Watch, but also on desktop, and also in your car, and also on your speaker? That quickly becomes really complex. I think listeners can imagine how this becomes complex, if you want to standardize a text or just a design.
Nicole:
Really, it’s about a little bit about multi-platform string management, and then what you mentioned, definitely localization. Translation of strings, how do you get people involved? In a lot of companies, unfortunately, I’ve seen that the localization team can be very separate from the design system team, and that can be a huge issue, because technically you would really need to bring in someone from the localization team to really look at how the design system is built, and really ask them, how would you like to use strings, or is there anything we can do to make it easier for you folks to localize all of this? Then, different tools will come up in that conversation.
Larry:
Yeah, that reminds me of this generic challenge that we face across all kinds of content practice, that need to span or bust, or break into silos and get people talking to one another, that I’ve felt what you’re saying about localization being kind of its own thing. Because, I can’t imagine that, managing 20 different languages, just managing your translators and localizers, and all that, that alone is crazy. You can see how they’ve developed their own thing. But, have you seen any success stories where localization teams or localization practices have informed content design stuff?
Nicole:
Yeah. I mean, I can definitely say that where I’m currently working, without wanting to name anything, but this is a big effort we’re currently working on to really work closer with the localization team, make sure we understand their needs, make sure that we make their needs an actual central part of the design system work. Previous companies I’ve worked with that, in my view, have done this quite well, for example, would be, well, do we call the Meta now or do we still say Facebook? They have a . . .
Larry:
People know who you’re talking about, yeah.
Nicole:
They have, in my view, a pretty mature way of working with their design system closely to the localization folks.
Larry:
Interesting, yeah. I want to go back a little bit, too, to the actual content in and around design systems. Because we’ve talked about a lot of different stuff now, like specific string management, about, you mentioned documentation earlier, there’s also, and you mentioned communication earlier. Is there, designs systems are pretty good at getting all of that platform-level stuff, just tokenizing things like colors and font selections and layout stuff and all that. Have you seen any practices or tools that help unify the content part of design systems? Because, just within a design system, those things I just rattled off, it seems like there’s a lot there, and it seems like it would benefit from coordination and alignment. How does that happen now, and I guess maybe more to the point, what would be the optimal way for that to happen?
Nicole:
I think it’s a really interesting question, and it’s a question I ask myself pretty much every day. I’ve tried a couple of different things. I think something that is often overlooked is that no matter how many writers you bring onto your design system team, there will still be engineers writing documentation that will live in the design system. Something that I really like to do is to make sure that I support and coach and train engineers in what good documentation is. That includes, I like to create guides that just help explain like, hey, this is how you make a document readable. This is how you make it scannable. This is how you make sure you include the right amount of context, not too much, not too little. This is how you write headlines. Very basic guidelines like that.
Nicole:
Then, usually when I join a new team, I also offer in the beginning to really, when engineers are writing new documentation or sometimes it’s also designers, to bring me in and I go through their work with them to help them see, okay, these are some low hanging fruit so we can improve the documentation. Then I think it’s also a lot about just clarifying and standardizing the actual documentation part. What do we actually want to include? If we want to include this here, can we include this for components? Or is the documentation going to a look different, for example, if we’re talking about the design system for a different platform?
Nicole:
To really try to standardize and raise all of those questions, like, how do we want documentation to look like? Does it make sense for it to look like that? Why do we want it to look like that? But, then, to also really train the people that are actively working with it in their day to day, to make that happen, because you as the writer will likely not be able to just create it all yourself and oversee it all yourself. That’s less of a tool and more like a way of working that I’ve seen work for me, and people that I’ve worked with appreciate.
Larry:
Yeah, it’s more like evangelism, or something, because there’s few engineers or designers who really want to, or their interest in improving their writing skills is probably pretty far down their professional development to-do list. Have you had good success with that? Do you find that most engineers you’ve worked with or designers are curious and receptive to that, or have you had challenges there?
Nicole:
I would say most of them have been really receptive and happy to get help with this. In my experience, most engineers don’t actually enjoy writing documentation. I think the first try or the first move when a writer joins the design system team is just like, oh, can you just write this documentation for me? But, of course, that doesn’t scale. Based on that and still leading the conversation that way, I felt that engineers have been really open to talking to me about things, seeing how they can do better. They really appreciate some of those guidelines to make it easier to write good documentation. In my experience, it’s gone really well. I mean, I’m sure there’s different personalities, but yeah.
Larry:
Yeah, no, and I can picture you being really good at this. I think that, nowadays, collaboration is such just an innate part of any digital professional skillset that I can see the willingness to collaborate there being pretty strong. Hey, Nicole, I can’t believe it, we’re already coming up close to time. I could talk forever about this stuff, but I do need to wrap up. But, before we do, I just want to make sure, is there anything last, anything that we haven’t brought up yet, or that’s just on your mind about content and design systems that you want to make sure we talk about?
Nicole:
Yeah. I think the one thing I would like to say is don’t be afraid of the design system, and don’t be afraid of working with a design system. I think before I knew much about design systems, the term in itself sounded really scary to me. I was like, “Oh my God, who are these aliens working on the design systems? What does a content designer on a design systems team do?” It felt really scary and I really struggled with understanding what it means to work with a design system, but also the impact the design system can truly have in a big product company. Don’t be afraid, and if you feel like you don’t really understand how to work with it, or how you could potentially contribute to the design system, reach out to people. Most of us are really happy to talk about it.
Nicole:
Most design systems I’ve ever worked with have really struggled with the contribution factor, so, how do we get designers and writers to continuously contribute to the design system so we can keep it up to date? We’ve always been really happy when people are open to learning more about design systems, reaching out to us, maybe even embedding in the team. That’s a big thing I want to give folks along the way, because sometimes I feel like when I talk about design systems with, for example, other UX writers or content designers that don’t work with a design systems team, they get really like, “Okay, this is not my field. This is something very different from what I do.” Out of principle, almost, don’t want to understand, which I understand because it’s a scary thing. Yeah, I don’t know. I think that’s a good thing to give the listeners on their way.
Larry:
No, I really appreciate that. I can validate that too, that I’ve been talking to people about this for about a year now, and every single person is just super helpful, super knowledgeable. No need for fear. Just dive in, start asking questions, and you too can be a content designer on a design systems team.
Nicole:
Yes, exactly.
Larry:
Great. Well thanks. Hey, and one very last thing, Nicole. What’s the best way for people to connect with you, to find out about your podcast, to follow you on social media?
Nicole:
Yeah, I mean, you can connect with me on LinkedIn, Nicole Michaelis. Feel free to send me a connection request or shoot me a message. Just keep in mind, usually takes me a while to respond. I get a lot of messages. Don’t want to brag, it’s actually not just great messages, but sometimes the noise is there. I’m also on Twitter, and it kind of comes and goes in phases. Please only follow me on Twitter if you’re okay with controversial opinions. I try to keep it down, but still, sometimes I wake up at 3:00 AM and I tweet some stuff. Keep that in mind before you follow me there. If you want to follow the Content Rookie podcast, it’s basically everywhere podcasts are, or you can just subscribe to contentrookiepod.com. I’m also always happy to hear thoughts on what kind of episodes you think I should do next. The purpose for the podcast, essentially, is to help people understand more about the world of content, both content design and content marketing.
Larry:
Yep, and it’s a fantastic podcast. I’ve listened to every episode, and I love your style and your approach and your intent in that podcast. I really appreciate that. I can also recommend your Twitter feed. It’s delightfully controversial, I guess is how I’d call it, how I’d label it. Well, thanks so much, Nicole, a super fun conversation.
Nicole:
Thank you so much for having me. This is great. I feel like we could go on and on about this, but maybe it’s good to keep it at this time so people don’t, again, get afraid of design systems.
Larry:
No, it’s a conversation like everything, and we’ll keep it going.
Nicole:
Perfect. All right, thank you so much.
Leave a Reply