My guest today is Michael J. Metts. Michael designs digital products and services, with a focus on the impact of writing on the user’s experience. He and co-author Andy Welfle have written a new book on this subject. In this conversation, Michael and I discuss the relationship between writing and design, and how being more aware of how we use language can make us more effective.

Show notes

Disclosure: I received Michael's book for free as a previous Rosenfeld Media/Two Waves author.

Show notes include Amazon affiliate links. We get a small commission for purchases made through these links.

If you're enjoying the show, please rate or review us in Apple's podcast directory:

This episode's transcript was produced by an AI. If you notice any errors, please get in touch.

Read the full transcript

Jorge: So, Michael, welcome to the show.

Michael: Thanks, it's great to be here.

Jorge: Well, it's great to have you. For folks who don't know you, why don't you tell us about yourself.

Michael: Well, I have spent the better part of my career now designing digital experiences of different kinds. I initially began in that field as a writer, in terms of what people called me, my title and that kind of thing. And now I have titles like designer, but there's been a lot of crossover between those two worlds throughout my career.

Jorge: So, you and your coauthor Andy Welfle have written a book called Writing is Designing, which addresses this subject. How do design and writing relate to each other?

Michael: Yeah, I think It's hard for a lot of people to make that connection because you run into a lot of people who tend to be wired one way or the other or feel like they're more capable in one area than the other. But really, if you think about any sort of experience that you interact with, like a mobile app, that's the one we use as an example right in the beginning of the book. Your mobile app, if you open it up and you start tapping through it, you start looking at it, you start to see words everywhere. You're interacting with language just as much as you're interacting with visual elements like menu items and buttons and all those other things. So, our thesis really is just that you should treat those words as part of the design and that you should apply design techniques and practices to those words and how you get there, and not treat them as something that's inconsequential or after the fact. So, we've done that in our own careers, and we've seen how vital it is to building a good experience, and we just want to share that with others.

Jorge: I think that the word design for a lot of folks evokes visual artifacts like drawings and sketches and stuff like that. And when you say that you apply design techniques, can you tell us a bit more about what that looks like?

Michael: Yeah. So, design, it took me a while in my own career to make that shift from thinking of design as something that was inherently visual. I think the first type of design people interact with usually is graphic design, if you've come across designs of signs and brochures and handouts and different things like that. And you can kind of tell inherently if one is designed well or if it's designed poorly. But you know, the, the thing about it is that the words that make up those artifacts are typically the same, whether it's designed well or designed poorly. So, I think that's why people tend to think of design is like the polish that comes at the end. But the way I think of design, and I think the way a lot of my field thinks about design, is that you design the experience someone has with a thing. And when you frame it that way, then you begin to think of it more broadly, and you begin to think of all the things that impact it. So, it's not just words, it's not just visuals, it's maybe even the business policies that affect how that thing works, or maybe it's the number of steps involved. All those things are critical pieces of the design that you can't even see as the person using it. So that's why, when I talk about design techniques when I'm talking about is thinking of prototyping the language you use and testing it with people to see how they respond. So, a prototype of language can just be some written sentences on a piece of paper that you go and ask people about, you ask them to read through it and ask how they perceive it. Those are all valid ways to design the language we're using rather than just writing it and going forward with it without really thinking about the impact it has or actually getting information about the impact it has on the people who interact with

Jorge: You talked about an example of a mobile app and the words that you see in the screen, and that is one way of encountering language. You also have just talked about a sentence, and that strikes me as a very different way of encountering language. The former is within the realm of what I understand of as information architecture, right? Like this notion that you create these structures of language that allow you to understand and move about an information environment. Are you more of a writer of sentences or a writer of user interfaces?

 Michael: Even in interfaces, there's always a tension between what the experience is trying to do and how people feel about the language you're working in, whether it's English or any other language. Maybe you feel like those error messages should be sentences, right? And maybe you're applying all the same thoughts that you would when coming up with a sentence for an essay or something to the way you write that error message. But the important thing is that you unpack it and think about why you're thinking that way. Think about what's appropriate for that particular use case and be intentional. Like that's what I mean by designing with words. So, a sentence could be part of that information architecture you're describing, and there's nothing wrong with that, but the important thing is unpacking why and being clear about it. This is something Andy and I do for a living every day, and then we wrote a book about it, which was a very different way of writing and a very different way of expressing our ideas than the type of writing we'd done for these digital products. And so I think we saw a lot of things creep in to our writing that we didn't see every day in our work. So, in trying to string all these sentences together into a book, that was a really interesting exercise and it was very, very different. So, the writing definitely is different. You know, you're writing in a digital product, you're writing to help someone move through a situation, your writing started to be invisible. You're not trying to draw attention to yourself, to talk about the merit of your ideas. I mean, those things. So that to me is where the line is, you know, it's more about your intention and about what you're trying to do with it.

Jorge: When you used the mobile app image, the image that it evoked in my mind had to do with things like heading labels and navigation links. But you talked about the error messages. Error messages to me are more prose-like in that you have to give the user a little bit more context of what's going on. Whereas with things like labels, you're peppering words around the thing. You have a little bit less of that kind of sentence structure to play with. And I'm wondering if there's a difference in writing for the one versus the other.

Michael: That's interesting. I think people who have jobs like mine are asked to drift in and out of those spaces without thinking about the boundaries. Because it's interesting that, in your mind, there's a very clear boundary between the two, but one of the challenges as someone who writes for a digital product, you have to figure out how to make it seem like there isn't, you have to make it feel like this is a cohesive experience where all this language works together and fits together. So, obviously there are big differences. Like you may have fewer iterations of that structural stuff, like if you think of the items in a navigation, you may do testing -- you know, there are really specific testing techniques in the world of information architecture, like cards sorts or tree testing to help you figure out what those things should be. And you're not really trying to mess with them a whole lot after that or iterate on them a whole lot, unless you have reason to believe that they're not working that well, or unless there are changes in the organization. So those are like really big structural things. The rest of the language though, it really has to fit into everything else the user's experiencing. So, examples of the types of writing, you have the error message, you have the push notification, you have onboarding messages, you have a little tips and helpful hints that pop up throughout the experience. That's very specific to the mobile app experience. So then if you have something like a voice experience or a chat bot, then you have dialogue that has to accomplish all those things just as text, as language. So, there are definitely different ways to think about it, different techniques you use when you're working with those things. But they do all have to work together. And that to me is the exciting thing about seeing it come together and practicing this type of work, is that you can start to build a whole ecosystem of language within whenever you're working on.

Jorge: How is that ecosystem of language managed?

Michael: I think it's different for everyone, you know, every organization. There's a really encouraging trend in design systems recently. I think design systems originally began as pattern libraries where people would put like their front-end code in a place where it was manageable. And then it became a place where you could talk about design standards and visual specs and things like that. And now the latest trend, which is really cool, is that you're describing patterns that are more structural. So, things like the language we use and how we write for certain situations and how you keep it consistent and how you may have a clear voice for your product that comes across. So to me, that's one of the more common ways I've seen it happen. There's also style guides many companies are using and then adapting style guides to their own means. Those tend to be more at the individual word level, word choice or an abbreviation or things like that. I think this trend of design systems is a really neat one.

Jorge: Are there any tools that you've seen or used to help do that?

Michael: It's an interesting thing, because in websites you have the sort of foregone conclusion is that you have a CMS, right? You have this content management system. Products usually don't, or if they do, it's nothing like their website CMS, which is designed to run an author experience. Okay. So that is interesting. I think it's a space we'll see a lot more, and I think are a few startups and companies that are experimenting with things like that. But honestly, a lot of times when I'm trying to manage content for our product, I will partner with the engineering team and we'll work directly in the code, so they might do some sort of a markup language that makes it easier for me to write and contributing. But that helps us look at like, okay, here's everything that's in the system, and maybe we could just reuse this over again in this situation, or maybe this necessitates a new variation that we haven't thought of before. So, I think it's really an emerging space, which is kind of surprising to me, but at the same time, I guess you're moving so quickly, you're not really thinking about how to control that language. It's easy enough to just put it, to use the code to manage it.

 Jorge: And beyond tools, I'm also wondering what is the role in the organization who has the ultimate responsibility for managing language?

Michael: That's a really interesting question. I know you had Lisa Welchman on your show a while back, and she was talking about how organizations manage the content governance and the types of things they go through. And I think it's interesting because I don't know how many organizations are thinking of governance, in terms of what shows up in a product, in terms of what shows up in an interactive experience. I feel like it's usually thought of in terms of the static web content. So, I think there's a need for that. And I think what makes it complex is that there's no clear owner and there's no clear role. You know, everyone is capable of writing. Like if you have a job working on one of these digital products, chances are you're fairly competent as a writer, or at least you think so. So, if someone asks you, " Hey, can you write this?" You'll do your best and you'll get it out there. And all you need is a word processor. You know, you fire up Microsoft Word and get something down. And that's really different from the way design in the traditional sense is practiced now, where you have a tool that's very difficult to learn and has a lot of quirks to it, and you've invested a lot of time in learning that tool, and you can use that tool as a governance mechanism in itself. You can say, "Well, I'm the one who uses the tool. So, I decided the designs." And I think that's why designers of words have a harder time. In a sense because they're going to have to rely on building relationships and building trust and making a case for why we should use this particular language because it feels so accessible and malleable by just about anyone. If you're a designer with words, you don't have a tool to fall back on and say, "Yeah, this is my complex thing that only I understand that only I can use."

Jorge: So, I'm wondering how you... Like, I would like to hear an example of how you go about designing with words. Like what are the tools that you're using? What is the process? How do you put it in front of people? How do you test it?

Michael: So let’s walk through an example. So going back to the example of an error message that I talked to at the beginning, if you were asked to write an error message, you could take the scenario that someone gave to you and say, "Well, here's my best effort at what that error message should be." There's actually a story about this in the book. Someone named Lauren Lucchese, she's a design manager here in Chicago. She talks about the first time that she was asked to dive into writing some error messages for a login screen. And she was given this spreadsheet of 50 error codes and told to write something general that would work for most of the situations, if not all of them. And she started this project just trying to respond to the need that was given to her and trying to make her best effort to write the right error message. But there were a lot of different things in that spreadsheet. There were things like a code for when the user of the account, when records showed that that person was deceased, for example, or when there was a notice of fraudulent activity on their account. So, there could be all sorts of reasons that this person can't get into their account, and some of those merited some unique handling. So, while she started to just write, she realized that that wouldn't meet the needs of the users. And in fact, when some of those initial flows were tested with users, they saw that it wasn't working that well. So, what she did was she started asking questions about these different scenarios and how it would be resolved on the business side. So, for example, if there's fraudulent activity, they could give a phone number that would go directly to the fraud department, then this person could get the help they needed quickly and they wouldn't have to go through a phone tree because they already had identified the person's problem via that error code. So that's an example of how Lauren was able to identify unique needs by asking questions, by being curious. And that's applying... that's an example of applying the design mindset to this. And then when you think of testing, like the tools that you're using for this, a lot of times it's just a text editor. I use a plain text editor for my first passes when I'm designing an interface like this. We're having a conversation as a team about a new feature we want to build out, I'll offer to share my screen and start writing just in big text what we think that feature would be or what we think it will say. And getting it in front of people tends to get some really good reactions that are helpful for the team to process that. It's sort of akin to what you might get by sketching on a piece of paper what the interface might look like. Doing that same thing for the words you write, treating them not as precious, but as something to just to get out there and try to express, is a really practical way to apply design to writing. So, put three options out there that are wildly different, and see where they take you and see what conversations the team has about them. And then beyond that, I use paper a lot for testing. Testing can be pretty complex when you're dealing with a visual interface, but I find there's a lot of value in abstracting the words from an interface and testing them on the run and seeing how people respond to them. So, you can give enough of a setup that people understand the scenario that they'd be facing and then get their reaction. So, one of the methods we talk about in the book was popularized by GOV.UK, they call it the highlighter method. They print off the content just by itself outside of any sort of screen and then they ask people to highlight in green the things that work especially well, and they highlight in red the things that don't work as well. Then they're able to ask follow-up questions about why. You know, why is that working very well? Why is that? Maybe it's confusing, you know. Maybe people didn't understand the language, maybe there was jargon involved. And so that's how you actually make a case for your design decisions using words, by getting it in front of people and getting data from your users.

Otherwise, you're just going to have a lot of discussions back and forth with decision-makers and say, "Well, I think it should be this way." And they say, "I think it should be this way." Again, that's kind of the. beauty of what a design practice brings to writing: you can start to think about it more objectively and apply some rigor to it that you wouldn't be able to if you just kept writing the way you normally do.

Jorge: I can see how that is a more designerly approach to writing. I want to come back to the text editor. You said that that's a tool that you use to do this, and I'm wondering if you have a favorite text editor, and if so, why?

Michael: Yeah. I've tried a lot of them. I guess it's like a hobby when you're a writer, you're just downloading text editors constantly. The one that I use as a scratch pad at work is called IA Writer, and I just like it because it gets out of the way pretty easily. You can get the type nice and big for when you're sharing your screen, and that one, it's just simple. And of course, writing the book, I used a different one: I used Ulysses for just because it was easier to organize things. And that's what I use when I'm writing on my own, just to get things down and in an organized way. So, it does nice things there. But IA writer as my favorite just scratch pad with the team, I'm sharing my screen, kind of a text editor.

Jorge: Can you talk a little bit more about how you choose one versus the other? When you say scratch pad, does that imply that it's for shorter-form texts?

Michael: Yeah, I mean like there's no organization, right? You're just opening individual documents, so it's easy to just open one and then they're automatically saved to a certain folder on my computer so I can just open it, open a new document, and I know it's there, saved to the cloud as soon as I open it. So that's a nice thing about it. And then there's just the simplicity. I think a big trend in those texts editors is that they're like a distraction-free environment. And that's what I look for as well. I don't want anything but the words on the screen when we're looking at it. In full screen in IA Writer, that's all you can see. It does support Markdown as well, which I'm a big fan of. I use that all the time to give hierarchy to the things that I'm working on. That's a nice thing too you can borrow from the design world because you know, there's this idea of hierarchy. How do we apply that to language as well? And that translates pretty well to Markdown.

Jorge: Can you speak more, for folks who may not be familiar with Markdown? Can you tell us the elevator pitch for Markdown?

Michael: Sure. Yeah. I mean, I don't know if anyone needs to be burdened with it, but... the reason I like it is because you can really easily apply some formatting without going overboard. You know? So, like, if you think of the Word document that you may have received from a coworker with all sorts of different colors and fun fonts, that's not the type of formatting I looked for. Markdown, you just put for example, a pound sign in front of a line of text, and that is your largest heading. So, if you put two pound signs, then it's one size smaller, and you can use that to break it up. In this section, you can do italics, you can do underlying, you can do bolding. But it's really minimal formatting that you can easily remove. So that's what I like about it.

Jorge: When you were talking about creating variations that you would put in front of people, you used the phrase, "abstracting the words from the interface." And I'm wondering about the relationship between this designerly way of writing and typography; the actual rendering of the letterforms and words when people encounter them. So, a resignation letter reads very differently if it's set in Times New Roman than if it's set in Comic Sans, right?

Michael: Yeah. Yeah. I mean, I think that applies to like the importance of... I don't know, sometimes I worry people hear me talking about how writing is designing, and they think like, "Oh, well you don't care about the visual side of things." That couldn't be further from the truth. I think that the best design happens when someone whose core skill is language teams up with someone who's core skill is visual design and they work together to build an experience. If you could find both those skills in one person, that's incredible as well, but that's really difficult to do. But I think that's a reason why you have to be in partnership with people. Again, like visual design is another part that dramatically affects the experience people are going to have. So, when you're abstracting from the interface, you've gotta be careful with that. You're not saying this is the final ruling on how this should be. What it does give you is, it gives users a chance to interact with the or language without being burdened by the usability issues of a form, for example. So, you can get information that you know is about the language itself. So that's what's really powerful. You don't want to use it in isolation. You don't want to over rely on a technique like that. my question is, how often do teams actually try that, right? Like how often do they actually get the message in front of people by itself so that they can understand how people in processing it?

 Jorge: So, I have one final question for you, just to try to make it actionable for folks who might not be designers using writing as their day-to-day work. All of us have to communicate using language. And I was wondering if you have any tools, tips, techniques to help folks be better writers.

Michael: Yeah. So, I think you could still think of writing as designing, even if you're never making it an interface. And what I mean by that is when you write something, when you write an email to a friend, take a step back before you send it. This is common and advice that, that seasoned writers will give people all the time. Take a step back, read it out loud to yourself. Think about the effect it will have on that, that person. And try to put yourself in the place of the reader as often as possible. That's, that's such a good exercise. Think about the effect that the words you have written will have on the audience. And, you can even test it too. That's another neat thing you see it happening where people will be like, they'll come up to you with something like, can you read this? Does this doesn't make sense? Apply those types of thinking to your everyday writing. And, and don't be afraid to get those other perspectives involved. I think what's beneficial about design especially, is this idea of being clear about what you want to learn. So, when you show that to someone else, don't come at it trying to answer, "Is this any good?" You know, like come at it with, "I want to see how this person perceives the way I wrote the greeting." Or, "I want to learn more about what they think I was trying to get across here." And make sure that you're really clear about that at every step of the way. I think it's very rare that we take a step back in our own lives and try to look at what we're trying to accomplish with the little things we write every day. Even something as simple as like an instant message to someone on Slack. I see frequently people complaining on Twitter about coworkers who just say, "Hi!" on Slack or Teams or whatever, and then wait 10 minutes for the person to respond before saying whatever they needed. So, there's this emerging idea of having some IM etiquette and saying what you want along with your greeting so that you're not wasting people's time and aren't breaking their concentration, all those things. So, you can do that just by being intentional and being thoughtful and not being so reactionary, right? Like the reason people type "Hi" and just hit send and then go away is because it's really easy. But what would happen if you started to think about the people on the other end more whenever you're writing. I think that's the, that's the direction we want to move in.

Jorge: Fantastic, that is great advice. Thank you. The book is available now for preorder, right? It's Writing is Designing.

Michael: Yeah.

Jorge: It's available in the Rosenfeld Media website. Where can folks follow up with you other than by buying the book?

Michael: Well, they could follow on Twitter, LinkedIn -- I'll accept connections from people in the field. And I also have Instagram, if you're interested in photography. That's how I began this journey. I think that that side of me is a lot more fun than the writing sides. But yeah, any of those venues. I'm also trying to write a little bit more. The book got me interested in writing outside of work. So, you can follow my blog at And I write there just a lot about the methods that I use to help teams work together effectively, how I help people understand my work, and those kinds of things.

Jorge: Well, great. I will include all of those in the show notes. Michael, thank you so much for being on the show.

Michael: Thanks for having me. It's been great.