Latest / The Not-Boring Tech Writer / Empathy advocacy: Designing docs for all emotional states with Ryan Macklin

Transcript

Empathy advocacy: Designing docs for all emotional states with Ryan Macklin · The Not-Boring Tech Writer

• Kate 0:04 Welcome to The Not Boring Tech Writer, a podcast sponsored by KnowledgeOwl. Together, we explore topics and hear from other writers to help inspire us, deepen our skills, and foster our distinctly not boring tech writing community. Hello, my fellow not boring tech writers. It's time for another guest episode, and today I am so excited to welcome to the podcast a guest who introduced me to the phrase 'empathy advocacy', and whom I feel deeply aligned with on so many tech writer things, and I'm delighted, also, that he agreed to come on the pod. So please welcome to the podcast, Ryan Macklin. Thank you so much for being here. Ryan 0:46 Absolutely. It's a pleasure and a delight, not just one, but both, to get to hang out and chat with you on this. Kate 0:53 Thank you so much. Ryan and I first crossed paths, I think, several years ago at one of the virtual Write the Docs events, and have kind of stayed in touch, continued to share ideas back and forth, and recently reconnected at Write the Docs Portland. We have a really long Write the Docs narrative history between the two of us. But Ryan, there's also a whole lot about you I don't know, so this is a great introduction for everyone. Can you tell me a little bit about your tech writer villain origin story? How did you get into this crazy field? Ryan 1:27 I started off as a six or eight year old computer hacker. My grandfather taught me basics on an old Trash 80, and so, pretty much like throughout my early childhood, I was just this nerd who was working on cobbled together machines learning stuff. I went to computer science for school, and so my whole life seemed like it was going to be very technical, but not necessarily communication oriented, but due to a random creative writing class I took in high school. That's when, like, the world kind of opened up, and I got invited to another special creative writing class for seniors, and that kind of got me into publishing my own work. I was also a role playing gamer, so I got into writing for role playing games and stuff like that, which was this amazing sort of eye opening world at first, exciting because I was young and got to do what I loved, and didn't realize we were being exploited for very low amounts of money. Then I became an editor on role playing games where I knew I was being exploited for low amounts of money but needed a job. I ended up, at that point, leaving software development just kind of I felt like I saw the writing on the wall, because I'm a third generation software developer, and I watched my grandfather and my uncle start to lose work opportunities as they got older. So I wanted to make sure that I didn't have other things that I could do. So I got into editing. And the thing about role playing games, is that's a form of technical editing and creative editing and a nice combo. I turned that into an actual tech writing career. I've used samples of books that I wrote or edited, actually, as my samples for getting my first tech writing job. Kate 3:28 I love that. Ryan 3:29 And not just that other, like some other things too, that were more technical. But the way that I position that is that role playing, game writing, or editing book production is harder than technical writing because it incorporates things about technical writing and then some technical writing. The reason that sometimes technical writers can get shafted on the job is that we are not necessarily seen as the product, but it is not possible to not see a tabletop game, if the text is not the product. If the text is not engaging or is confusing or, I mean, again, not just confusing, which can happen, but even just not engaging, not inspiring, all those other sorts of emotional qualities, the product can just be dropped for a different game. It's not like you need to use this product for work, unless you are stuck with the docs. So this was documentation on hard mode and having to also document for that's essentially either, no matter how you go, you are documenting for what's essentially software running on hardware which is a bunch of disconnected, squishy brains. That's the hardware that role playing games run on and that a lot of other tabletop games run on. So that's just inconsistent. So your book or whatnot, it's also the user interface that you're doing. You have to design it with that kind of lens as well. And so all of these other things are, like, Yeah, this is actually much harder than technical writing, which is not to say technical writing isn't hard, but if you have, I have fewer challenges than I did when I was back in role playing games. Kate 5:10 It's a smaller number of parameters, at least like you're not dealing with the entire range of human brain complexity. You're mostly dealing with software products which, no matter how complicated they are, it's sort of a finite level of parameters, right? Ryan 5:27 And you're dealing with user interfaces that are typically somewhat more solidified than what I have to deal with because I but that's where it came from. I brought those sorts of understandings of things, along with, like, my own journey in cpsd therapy and neurodiversity and stuff like that. Basically, I didn't necessarily stumble into technical writing, because I knew at a certain point in my role playing game career that I would like to make more than barely minimum wage in the city of Seattle, just barely health insurance. So I knew I wanted to get back into tech as a technical writer, but I was really surprised at how many things I was able to bring that aren't traditionally a part of technical writing, bring that to bear and to translate that into stuff that literally ended up eventually naming empathy advocacy, for lack of a better term for this kind of concept, because user advocacy was taken and is overloaded anyway. Kate 6:35 But even in the sort of RPG background, it's a really interesting story because it very much centers reader experience in that so it actually does make sense as a narrative arc. I did not know that about you, though, Ryan, that's fantastic. Also a good lesson to those of you trying to break into tech writing, that there are a whole bunch of fields where you have deeply amazing skill sets that do translate really well if you are willing to take a step back and really compare apples to oranges and realize that they're all fruit and that some of the same stuff you do with one kind of fruit you can do with another kind of fruit. Ryan 7:14 I have never heard of extensions of apples to oranges, but they're both kind of, so I hope you're cool with the concept of theft, because I'm stealing. Speaker 1 7:21 That's fine. You just told me you're stealing it, therefore, go forth, steal. Ryan 7:26 I have permission. Now, it's a little less flat, but I'll still do it. Speaker 1 7:30 That's a bit about your background, getting into the field. What is your current role? What are you up to right now? Ryan 7:36 I'm a tech writer focusing on really specific requirements documentation. So it ends up being very specific language and pacing structures and stuff like that. Other companies have to adhere to using our product. I write some softer stuff as well, but my main deal is basically maintaining around 750 pages of very highly specified, not just specific specifications with all sorts of implications that happen. If someone says, Oh, hey, I want to introduce myself, I want to casually use this word. I actually have to search to see if this word has a definition that you're not aware of. And so I end up having to basically be the- So in some cases, custodian, some cases like Information Architect, for this, for just an ongoing, like many years long product that keeps being updated. That's my main job. And it sounded at first like, it would not be like, it'd be just sort of like it, and technically, it's just a part of my job. But it sounded like it would be like, Oh, sometimes things come in and you have to update them. And it turned out that the amount of information management that happens with a position like this, where you have to make sure that what goes out does not have any sort of cascading blowback on something, on some other part of that 700 page doc set ends up being actually a lot of time, a lot of energy. Kate 9:13 Oh sure. Ryan 9:14 It's actually, at times, kind of exhausting because of the amount of stuff I have to have in my head at any one time to know where to look for things. Even if it's not even just, 'what do you know', It's just remembering, okay, if this happens, where do I even need to look to see if there's a conflict or anything like that? So my main deal is I am like the caretaker. And I guess the word that comes to mind is nursemaid for these docs at times. Kate 9:45 I recently did a solo episode on the concept of Doc stewardship, and I feel like maybe you fall into that category as well, but nursemaid has a whole set of connotations that I'm kind of enjoying, so maybe I'll stick with that. Ryan 9:59 I've always found that to be a big part of technical writing. Your ability to wield rapport, to gain social capital, to know when to spend that social capital, all of those things are explicit in my mind. Whenever I ask something of somebody, I sort of go through the mental thing of like, Okay, do I have social capital where I can just ask this? Do I have to promise something in return? Do I have to, you know how, like, this is important, but this might not be their form of importance, even though this can block publication. How do I make it important to them, and then, how do I get them to want to be on board with me in the future and not dread when I message them. So, yeah, bedside manner is a thing that I have to deal with, and as a neurodiverse person, as a thing that I also struggle with, is why it has to be very intentional. Kate 10:55 Yeah, that makes sense there. I mean, there are so many folks that we have to interact with to create documentation, update documentation, validate documentation, and the writing is- we had Marcia Riefer Johnston on a few months ago, and she talked about how writing was actually the minority of the time, really, that a huge portion of your time is figuring out who you need to talk to, getting the right people to provide information, getting feedback from the right people to make sure that what you're putting out is accurate and that you've interpreted all that correctly. And that's a lot of project management, but it's also a lot of personality management, and there's a lot of pitfalls that you can fall into if you aren't thinking about the social context you're operating within as you're trying to work on that documentation. Ryan 11:48 And because of that, my notes often, when I'm tracking tickets or things like that, get really meticulous. I talk about who I talk to when I talk to them, the decision that came from it, any sort of pending questions. I make sure that when there is sort of a problem or decision log or something like that, that it's somewhere actually in writing, in every time, not just for the cya aspect, but the future me really loves it when the past me remembers to write something down. Something that I've talked with my therapist about at some point is I want to form a better relationship with future me. So I'm trying to do things that I know I would appreciate. And he's like, that idea of a relationship with you in the future you is a great concept. Kate 12:34 It's fantastic. I talk a lot. My team thinks that I'm the most gung ho on documentation ever, and I certainly am. I believe very strongly in the power of good documentation, but a huge driver for that is also that I have a terrible memory at this point in my life, and so I have turned to documenting things, conversations I had, decisions that I made, whatever, so that three years from now, when the Swiss cheese that is my brain can't remember anything about that, I can look at documentation that former me wrote and go, Oh, that's right, this is how I solve that problem, or why I chose to solve the problem this way, or who I consulted when we made decisions about x. It really is an act of service to your future self. It's great customer service. Ryan 13:24 I have another thing that I also find, like notes, which is, When did I say this? Because time blindness can be a thing, like, even to the thing of trying to remember if my partner asked me to do something, I have to try to consciously remember, oh, I need to write, immediately make a calendar entry on there so that I don't forget, and then B, I can note down, also when I agreed to the thing and when I said that I would do it, or something like that, so that I understand that, oh, this is actually going to take me a bit. I need to make sure the time blindness doesn't sneak up on me. So, the wind aspect creates a temporal point that you can concretely;a temporal point that you kind of latch on to as well. Kate 14:06 There's some good mental mapping happening there. Maybe one last final intro question, I've been using the label 'tech writer' through a lot of this. I know in the Write the Docs community, a lot of people use documentarian. Is there a particular title or role or label that you feel most drawn to, out of all of those? Ryan 14:26 I say I like the term content strategist, but it has different connotations, and it's the sort of thing that works in some realms better than in other ones. In some realms, a tech writer is actually going to be seen as some more authoritative or then content strategist or content designer can kind of maybe feel more Project managerry, even though they're the same thing. It's just a different label. I like that as sometimes a way to say that I am not just a writer. And in fact, as brought up, writing is- less than 50% of what I do is writing for users. I do lots of writing, just some of that is writing notes or writing justifications, or occasionally writing white papers on why we're about to make a terrible decision. That way, when we make the terrible decision, I can go back and say, here's everything that just happened, aligned with my predictions. So could we not do this? Now I almost never. I've written so many analyses of, based on X, Y and Z, the thing you're proposing is going to have these particular things. It's going to cost this much time. I don't think that there's the benefit that you hope there is, and I'm willing to be wrong. I'm absolutely willing to be proven wrong. I've accepted that even if I really disagree with a decision, that I'll say, Okay, well, why don't we experiment with it for six months instead of saying, No. I'm like, let's prove me right or wrong, and then lots of time where I'll end up being like, well, just go into, here's five pages on why the decision you made with sort of half an hour's thought sounds like a great idea, and turns out to have terrible implications. There's a lot of writing, just not as much user writing as you would think. Kate 16:26 I think the distinction there really is the idea of incorporating the element of strategy into the title. Because sometimes people view tech writers as almost like order takers, like, I just want to order this round of documentation on x, and then we're just supposed to magically create it, and that's all we do. But in reality, most of us are doing way bigger picture stuff than that, or want to be doing way bigger picture stuff than that, and finding ways to incorporate that broader, strategic approach is fantastic. Whether you can do that with a label, whether you can do that just through the work that you choose to do. Ryan 17:01 There is a drawback, though, to content strategy as a term I would say, which is that, because you lose this sort of the technical part of it is that there are possibly one of the other things that I do at my job is I write tooling for stuff like I'll do like Python or sort of other bits of tools. And so I think as a content strategist, I would probably not be seen as tapping onto that, but as sort of like a technical writer it's really just about perception. It's nothing about who I am as a person and whatever title I give, it's about what that title feels like, it communicates to people. And so this is a position where being a technical writer allows me to really leverage the technical part of that term, while unfortunately having to deal with the pitfalls of the writer part of that term. Kate 17:51 Thank you for all of that context. We've both mentioned empathy advocacy, and I'd like to get you to talk about what that is, but also maybe a little bit of villain origin about how you came to put those two words together. Ryan 18:06 It started by trying to find ways to communicate to people who were technical but not necessarily user sympathetic. The reasons for decisions that I was making, or questions I was asking, or things like that, where I'd ask questions, where I would get those various engineers or whatnot, being like, why are you asking me this? Or what does it even matter? Or explaining to some of our UX people the implications of well, if you do this looks nice, but here's the things that we will have to do to explain it to users, and what sort of implications that will have on their processing of both the UI and the interface, or the things like that. And then, as I got more involved at my first big, real tech writing job into being able to drive some of the product decisions be like, Hey, if you do this will happen. I had to make justifications for it, and so I used the describing essentially different mental states of users, particularly those in distress at some point, basically, some sort of dysregulated state, or basically optimal states, and explain why these users will struggle. Started pressing upon like, I'm not writing for optimal users. I'm not writing for the good case, the happy path. Kate 19:40 I've worked in the software world for a while on the product side and on the writing side, I've done support, and there's often in a lot of the conversations, it is often that what gets centered is like a perfectly calm, rational user. And I'm not sure I would ever describe myself as being perfectly calm and rational, but I definitely wouldn't describe myself that way now that I live with a chronic illness. So each day that I use a tool, I am bringing a whole bunch of stuff outside of that tool into my usage of it. Some days I've got low, what I call ambient stress and low acute stress. So I might be having a really good energy day and a good brain day, and I'm coming in to explore something that has no sense of urgency and no deadline associated with it. Other days, I might be coming in where I'm feeling like I'm really struggling to think coherently, my memory's not working so well, and I'm rushing into something because something is broken and I have to fix it really quickly. So I have high ambient stress that I just entered my day with, but also high acute stress from whatever this particular thing I just had just exploded that I have to fix is. My engagement with the tool and with the documentation, with support, people, whomever or whatever I'm engaging with as an extension of the product is very different on the day where I'm super stressed than it is on the day where I'm not. And to assume that everybody is coming in with no stress just seems completely unrealistic to me. People might be triggered. They might have all kinds of stuff going on. Particularly in the reality we currently live in, there's a high likelihood that somebody's coming in. Half their team just got laid off, and suddenly they're having to learn how to use your tool, or whatever that might be. And what I love about the way that you've defined and presented empathy advocacy is that it is making us aware of all of that, and then trying to provide some strategies to say, Okay, now that you are aware of that, try to be intentional in how you are structuring your documentation, and how you're structuring the language that you're using and the visual assets you might be using, because you are recognizing that people are not coming here in a perfect state, and that like the quote-on-quote stupid users that a lot of devs or engineers will complain about are actually probably like 90% of your users, and it's not that they're stupid, it's that they're busy and they're stressed, and something in their brain is just not like letting them perfectly absorb exactly the way your brain worked when you designed the thing, and so it encourages this level of centering humanity rather than centering the technology that I find really refreshing and really useful. Ryan 22:46 And to build on what you just said, like the acute stress concept, like, I also think about two different vectors of acute stress. There's direct acute stress, acute stress from the thing you're dealing with, and then there's outside acute stress, like just getting a text from your partner that they want to divorce is definitely gonna to is while you were dealing with some payroll software is gonna change how you're looking at that payroll software, even if you were in a neutral mindset. I've been growing to like that over calm because calm is a loaded term, and people don't think it is. But I could go on a rant about that. I could go on a rant actually, about how logical is actually an emotional state, because it's a series of different emotional states that can be contradictory, but that's a rant. Those both can lead to issues with the software. And while one is something that you can maybe more directly mitigate, because you understand that these may come up, the other one you can't, but there are things, strategies you can do to at least, again, blunt the issue. And it's not that we're supposed to take responsibility for how people feel, but at least to do what we can to help. I see that as also a way to be friends with our customer service folks, because our customer service folks are going to be dealing with particularly distressed people for whatever reason there, and there's a talk I have that I gave called So You Want to Play Toxic Tennis or something like that, which is taking the ideas of empty advocacy and focusing them specifically about customer support issues rather than communication, rather than about documentation. Some of that actually comes from couples counseling, which, as a side note, I loved, like saying I was getting into couples counseling with my current partner, discovered how much of it was actually paying somebody to be a translator. For us, it's like, oh, this is what you mean by this. What I mean by this is, let's learn to speak the other's language and create a shared language, that is, stuff like that. So it's actually interesting to find that it wasn't just translation, but to find out how much it was, Oh, here's a misunderstanding that a third person can actually identify why, where the root of that misunderstanding comes from. So that's sort of the same. A lot of those principles really, actually apply to the in a one sided way, to being a better customer service agent who can understand why people are comfortable where they are, especially really angry people coming to you with a lot of like anger energy and say, well, here are reasons why they're going to be that way. It is not your job or your responsibility to accept their actions. If their actions are crap, that is not on you. That is on them, but if you at least understand where they're coming from, then when they're as long as they're not being complete, I don't know if you swear on this podcast- Kate 22:46 Go ahead. Ryan 23:55 The complete term I use for these people are absolute stick fucks. As long as they're not being that, then you know, you can abuse like, Oh, hey, I know you're angry. You're not taking it out on me, but you got that energy, so I will. Or if you do take it out on me, maybe you roll back for a moment. So, Hey, I apologize. Cool. I know where you're coming from. I can kind of adapt what I'm trying to explain to you, knowing that you're in a prime state. But if somebody is, of course, being an absolute stick fuck, then you'd be like, Okay, you actually need a timeout. As a customer, you need a timeout. I don't actually need to support you while you are doing this, because one, you're projecting energy onto me, which is going to make my day harder and my moment harder with you. And then two, you're going to be less receptive to what I am trying to help you with. So we're helping neither of us here with that, but so with that sort of frame is like, Okay, here's why people are the way they are, in a broad sense. Ryan 23:55 And actually, this is maybe a good point for us to take a quick break and then we can come back and dig a little bit more into that. Does that work for you? Ryan 24:21 Absolutely. I have a dry mouth, so let me fix that. Kate 26:42 Then we will be right back. This episode is sponsored by KnowledgeOwl, your team's next knowledge based solution. You don't have to be a technical wizard to use KnowledgeOwl. Our intuitive, robust features empower teammates of all feathers to spend more time on content and less time on administration. Learn more and sign up for a free 30 day trial at knowledgeowl.com and we are back with more with Ryan Macklin. So Ryan, before the break, we were talking a little bit about continued practical applications of this. Ryan 27:13 Aside from the accessibility issues regarding it, there can be subtle issues with just a sense of, Well, this is a really long scroll bar on this page. I was looking for a quick answer, like the sort of prompting somebody who is already prime for, say, a frustration response or are mentally exhausted, which is actually another state that is really important to account for. We'll sort of have to deal with that either seeing how much information they have to sort through, or the amount of visual processing they have to do for something that actually might be a very quick explanation. So for that, I tell people, okay, reduce the screenshots. If you can remove a screenshot and instead of having three screenshots, have one grounding screenshot to set people. Here's where you need to be. if it looks like this, you're at the right starting point, or you're at the right midpoint, or whatever, and then say, from there, do these four things, and then you're good, or do these four things. And now this modal will pop up, or something like that. So reducing screenshots, it makes it feel as though the directions are shorter, and so that will give people maybe more of a sense of they're not feeling confident than at least seeing that they don't have as much work to do there. If they're exhausted, they're having a lot of problems generating that neurochemical energy in order to actually process stuff, because the civilization part of your brain, it's expensive to do that. I mean, one of the reasons that we take so long to gestate and become like even just like young adults and stuff like that, and why we need so much care as infants versus like other mammals, is how big our brain is and how much energy it takes to run it. And so if you're feeling depleted, a lot of that's part of the empathy advocacy is considering that aspect of it. If you're feeling depleted, your ability to process complex or lengthy information is shot, even if you want to, it's not there. So for that reason, it's another reason to reduce the amount of screenshots, to either accommodate for people who are already sort of in that more exhausted state, or to at least reduce the amount of taxing you do so that after they have read your stuff, they are not then doing your stuff while becoming more exhausted over time, or even just to save them, in general, from whatever next. To deal with has nothing to do with your product being exhausted. But it is understanding that everything you put in has a tax. Kate 30:50 I like thinking of it that way. I mean, you mentioned social capital earlier, but there's also this sort of cognitive capital that you're asking people to either bank or use when they're interacting with your materials, right? And for the same reason that we don't necessarily want to have this massive wall of text, I think sometimes writers take the approach of, well, I don't want a wall of text, so let me add some screenshots, so it'll break up the text itself. But as you point out, that is going to create a really long scroll bar, and it's going to make a process that might actually only be like seven steps feel like it's 30 because of the amount of scrolling. And you talk about this in, I think the seven docs, techniques rooted in empathy, talk, right? And one of the points you made, I think you can correct me if I'm wrong, is that, you know, using it as like a grounding thing, as you mentioned already, using it as a validation that if you've gotten to the right point, and I like that, use of screenshots becomes more like how you would use, like an admonition or a call out at that point to be like, Oh, I'm going to draw attention to this important thing. Ryan 32:02 Absolutely. Kate 32:03 So there's an important checkpoint here. If you've gotten here safely, the rest of the steps are going to make easy sense. Let me give you the one screenshot to help you ground yourself on that point. Because if you're really off base here, the last four steps are not going to make any sense. I really appreciate it; that concept of 'I don't need a screenshot for every step, but I need a screenshot to help mark that you're in the right place'. It's like when you see the sign a mile before you get to an exit on the highway, that's reminding you that the exit's there, and you're like, oh yes, that is the exit I need. I remember this now, and you can guide yourself the rest of the way. Signposting, that's the word I was looking for. Ryan 32:46 Yeah, absolutely. There are other reasons to reduce screenshots again, like accessibility, their maintainability, the people. But I found actually, maintainability is an argument that doesn't get people on board, because at least I have found in my experience of the case, not saying that is like the case across the board. Kate 33:10 Can I get you to talk about FAQs? I hate FAQs. Just to let me preface this by saying I loathe FAQs with just about every fiber of my being. However, I do feel like it's come up in a couple of your talks, and I'd love to have you to drop some FAQ wisdom on us here. Ryan 33:31 So what I say is FAQs are where information goes to die, and the reason is because there's so many bad things about FAQs. When I do the sort of the visual storytelling aspect of this that I've done in the seven docs talk and other talks too, I demonstrate it by showing that an FAQ is a desk I know. And initially the desk might have a couple things on there. You can easily search and find it, but the desk becomes messier and messier and messier over time. It becomes a place where you might see someone say, Hey, if you want to go to check out our FAQ, but when I see FAQ, I don't necessarily feel like I know I'm going to get the answer. I'm looking for it. Just tells me that you give me a grab bag of stuff, I'll search for it and hope that maybe I can get the answer that's in there, but it doesn't necessarily communicate to me what I'm going to get out of it. And so I say, there are reasons for the concepts of FAQs that are good, and reasons for the concept FAQs that are not good. And the not good tends to be people just have something that they need to, like, vomit onto a page. You get this a lot. When customer service folks run documentation, they'll do a lot of that because they want to get something out there somewhere. But they are also constantly dealing with people. So the most expedient way for them to do that, and the most cognitively efficient way for them to do that, since their primary job of dealing with people is pretty taxing, is to vomit an FAQ tag at the end of an FAQ or something like that. Speaker 1 35:13 Because you don't have to think about information architecture. Ryan 35:16 Exactly. Kate 35:17 You're not heavily having to think about titles and cross references and everything else you can at least just like, know, I don't want this to sound offensive, I don't mean it offensive, but it is sort of like, I'm going to brain dump onto the page. So I know that content is somewhere out there in the world. It is referenceable, and which is a great first step. But if that's the entirety of your process, you're going to have this freaking smorgasbord of unrelated questions and answers that are kind of a nightmare for somebody to have to wade through. Speaking of the endless scroll bar, and that's, again, not the experience you want people to have, particularly people who are already activated or triggered in some way, they're already feeling overwhelmed by whatever their current reality is. They don't also need to be overwhelmed trying to find the answer to a question. Ryan 36:11 Since some people try to solve the FAQ, got out of control by turning into like, like zippy, collapsible tech stuff, which is absolute garbage for garbage people, because if you're trying to Control F to find something, you might have been able to find it in a search bar or something like that, and it loads the page, but now you can't find the thing that you were looking for on the page. So, that's not actually- collapsible text is generally terrible for that reason. That's how some people try to get around the big FAQ. And again, like a customer service person might not necessarily be versed in information architecture, or may not actually even have the permission to do, maybe they only have permission to throw stuff on an FAQ. They might not be able to do it, even if they understand the implications. But what I say instead is that if you are trying to, if you there is a good reason for an FAQ kind of concept, which is to collect related information together that may not be like instead of having them all as separate pages or whatnot. And so if, instead, I like to do it, like troubleshooting X concept, like troubleshooting your internet connection, for instance, and it might have some information there. And like troubleshooting this other thing, or like stuff like that, allows you to then have that kind of concept of, hey, it is the concept of, like, FAQ ish stuff. Here's a collection of things. Hopefully you still do some good information architecture and breakout or whatever you need to do. But then the title of the page itself tells you what your what it's, what the sort of the promise of that page is like. Kate 38:00 It's not the intensely vague FAQs or frequently asked questions. It is troubleshooting your internet connection or whatever that's going to provide both to the reader but also to anybody who's adding content. There is a set of guardrails to be like, 'this all relates to this topic'. And then I can still use that same general format, but I'm at least giving you this really nice, huge flag about what this content is actually related to, so that if you happen on this page, you actually know whether the question that you want to ask might be contained here or not. Ryan 38:40 And with a large FAQ, there's a big Doc, you may not even realize that you're creating multiple sources of truth, the same thing that are contradictory. There's other aspects to the unmanaged text vomit that are there, but it's the joke that I hate, that this particular, technically correct, is the best kind of correct. And my verbal knives will come out when someone says, 'Oh no, let me, I will tell you about how wrong you are right now'. And I experienced this while driving from Pennsylvania back to Michigan, where I live, the other weekend. I actually dealt with that on the road. But that's a separate thing where it's the same sort of thing of technique. These are technically published and technically published are the worst kind of published. And so, genuinely published, properly published, published with some sort of thought, if what you need to do to get it out in the first place is this and you have mechanisms that help redirect or whatnot, when it's refactored or whatever, fine, but try to properly publish rather than just technically publish and feel like you've accomplished what you need to accomplish. But yeah, so that's an aspect there. We really talked, I think, more about sort of understanding people who are looking for answers. This brings me another thought. FAQs bring up another framing of this. So at this point I have like four buckets of cognitive states that create different sorts of challenges, which is the anxious, the frustrated, the exhausted, sort of briefly touched on that one. The other one is also curious. It doesn't sound like that. Sounds like, what is that? Why is that a problem? Well, the curious person is actually somebody who is looking to satiate something in their brain that is just looking for information, whatnot. It's the reason that people go on to Wikipedia or TV Tropes, rabbit holes. Kate 40:50 I want to go down the rabbit hole. I will go deeply down that on certain things and certain things only. Ryan 40:55 Yes, absolutely. FAQ can be distracting if it has other random stuff in there, because curiosity is actually in the way of saying distractible or if you have unfocused material, unfocused messaging and things like that, anything that might give people the wrong off ramp when you don't intend them to, that can make it so that by the time they get back to the material that they're actually looking for there, there can be more like cognitive expense that they've already incurred. There can be maybe some framing in their head from other stuff that they have read that is actually misleading them and interpreting information so to be able to make sure that you are directing people to the right place isn't just about dealing with frustrated users who are just becoming more and more frustrated as their issues not being addressed, or anxious users who are sort of that's building on their exhausted users who just run out of cognitive energy as they're trying to sift through your stuff and just stop. But it's also for distractible users who are vulnerable to being led astray by unfocused material. And sometimes it's distractible in a way that isn't like, distractible isn't just like, Oh, I'm kind of like, somewhat bored and looking around, but it could be I have five things in my head right now as the problems I have to solve, this is the one I actually need to solve, but suddenly I see a different answer to a different problem I need to solve. And now that has become more pressing in my brain, even if it's not more pressing situationally, and so I am currently following my brain impulse to chase that down, even if that is not what I should be chasing down right now. Kate 42:50 And so we should not be waving shiny things in front of you to distract you from the task that you originally set out to complete? Ryan 42:58 Or understand that you might be at times and make that an intentional decision, or understand that's the trade off to something else, which, I mean, that's the thing. You can't necessarily avoid that entirely, but that is a bit if you can reduce the times where you're unnecessarily doing it, like with unfocused FAQs, then fantastic. Kate 43:21 So I feel like that also ties into the adage of, if you're using call outs, use them sparingly and with great purpose. Because the more of them you use, either the more distracting they become, or the more people tune them out and because they're overwhelmed by the volume of them, it's like the two sides of that same coin. It seems like. Ryan 43:42 If everything is bold, nothing is bold. Kate 43:45 And this is a perfect segue into some of the closing questions I like to ask, the first of which is, are there resources that you would like to share with everybody? And we are going to link to a bunch of the talks that we've referenced, but you also have, you have a website, I think, on empathy advocacy kind of? Ryan 44:04 So by the time this comes out, because I haven't really worked on this space for, not really actively or so for about a couple years now, like after I got laid off as part of the big waves of various layoffs in 2023, the wind kind of got taken out of my sails a little bit. And there's a lot of like, oh, I need to find a job, and stuff like this and because of that, and because some of what I was relying on was really crude explanations in neuroscience, as opposed to really taking my time to refine it and learn more about it. It paused a lot of that. I have a site, empathyadvocacy.org, for this sort of thing, so that by the time this comes out, I at least want to refresh it enough so that it can be a mailing list, so that people, like you can see stuff that I'm talking about occasionally. I share something there and maybe build it out into something sort of more substantial, but this is a place where I want to put that stuff there, so that'll be one. I don't know what that looks like right now, because, again, I've had to actually do the work. And as I mentioned, I have a lot of exhaustion from my day job. So that's about a lot of mental energy there, and my own site, which has the same sort of situation is macklin.cc where I have stuff, or would be having stuff by the time this comes out. And then, hypothetically, I'm on LinkedIn. Sometimes I remember to check it on occasion, and probably should get better at that. But I say that like I've said that for the last two years of, oh, I should probably get better. Kate 45:45 At this refrain in my life, but I understand, Ryan 45:47 Yeah, but I'm not as online as I used to be. So I used to be on all the socials, and now I'm just kind of very sporadic on it. But those would be the couple places to go for that. And I'll make sure that the details are there. Kate 45:48 Please send that to me or put it up there somewhere. Ryan 45:59 I'll definitely put it up there. I'll send it to you sooner so you can use it, but I'll make sure that's up there. So those would be where to go, yeah, if they have accord and macklin.cc. Kate 46:14 To close a little bit, Ryan, just to change gears a little bit, what is a great piece of advice that you've been given. It does not have to have anything to do with anything that we just talked about. I would just like to sponge amazing advice from other people. Ryan 46:29 I'd say one I've gotten recently was if I'm trying to chase down something from a stakeholder, to file an independent ticket and assign it to them, if they're not responding or they're really slow, if I'm trying to chase down a stakeholder who's not being communicative, they're busy and overwhelmed. Everyone's getting laid off. So you know that we're all overwhelmed. It's either they're overwhelmed or that person's laid off, and now I'm having to track down a new person who has no idea whatever, for whatever reason if they're not being communicative to me, or they're taking a long time to get back, is to actually, like, file a ticket and assign it to them and be like, hang on. This is no longer just like, hey, I'm sending you a quick chat message or an email, or I'm tagging you on a PR or something like, no, like, I'm actually making this now a thing that is now in your queue, and people will see it's in your queue and like addressing it, or you show your lack of addressing it, or whatnot. So doing that is actually something that is recent, oh, I can do that. I don't have to just rely on tagging people or things like that. If I can escalate that to an independent ticket to try to get something okay. That's kind of an interesting tool in my arsenal for when I am trying to get information from someone on a publication like blocker. Kate 46:29 It's interesting, I have kind of a similar process within KnowledgeOwl. We use Asana as a project management tool, and I get asked a lot of questions in our company. Slack for things, and if it's something I can't answer on the spot, I think my team is so sick of this, but I'm like, give me a task in Asana for it, because it's going to take more. Because for me, that is a little bit of work that is actual formal work for me to craft a response or provide feedback on the thing, and I will forget to do it if it's not in the same place that the rest of my formal work gets tracked. So maybe some people view that as a passive aggressive thing, but I actually prefer it, because it's like, oh, now I have a clear set of a list of what's expected of me, what I need to provide feedback on, to give to others. I like the visibility of that. I like the transparency of it. I would prefer that to you pinging me privately and then me feeling bad and forgetting about it for two weeks. And you may be thinking that I am intentionally ignoring you when actually I just forgot we had that conversation. Ryan 49:04 Yeah, absolutely. And I do something similar, where if something gets to a point like, Okay, I need you to make this a ticket for me. And that's partly also my way of saying once it's there, I have a way of recording all of my responses, all like, but like I have to create the paper trail that is going to be better as a paper trail than whatever other thing that we're doing. Suddenly, I get the sense of, even the paper trail isn't necessarily a cya. It's more like, now my boss has visibility in this thing. That's sort of a stronger visibility than just being yet another tag on, on a PR for something which I might get the email for, but that can be littered with other conversations on that particular PR or whatever. So I'll do the same thing. Kate 49:53 That sort of knowledge sharing or knowledge review is still work, and I'm totally fine classifying it as formal work, and being like, I am asking you to do formal work here. Ryan 50:05 It's also really great as a tool for turning it into 'this is now outside the scope of what we're talking about'. Or there's like, scope creep, or I really want to do the thing you're asking. We cannot fit it in this particular time cycle. Please make this a ticket. Or it will get or I will unintentionally ignore it, or sometimes I'll make it a ticket for myself, but I try to put that onto the person who's racing a thing so they can give them a chance to put whatever other individual context in it, puts their name on the thing, as opposed to my name on the origin, or stuff like that. So let's say that's one of them, is to actually create that. It feels like it's an escalation at times to say, Well, I'm now making this a ticket because it kind of is, because it's not as informal or whatnot, but it's like, because the actual work is my responsibility, I have a ticket for making this doc thing happen. It did not realize, oh, I can make basically other tickets that I then tied at this ticket to somebody else for getting information. Kate 51:08 It doesn't have to feel like an escalation. I mean, I've trained the KnowledgeOwl team fairly well. So now very often, when some of the more recent hires ask me a question, they will say, can you answer this now, or should I give you an Asana task for it? And I'm like, I have trained you like you don't have a problem putting stuff on my to do list. That's great. That's exactly what I want for myself. It is not an escalation. You're not making me feel bad. You're actually making me feel less stressed, because I now have a clear understanding of what you need from me. Ryan 51:41 This happens with subject matter experts who have a lot of other things to do and dealing with the tech writer who's trying to publish their work is low on their mental set of priorities, even if objectively speaking, it's like, Hey, you're trying to publish this in time for all of these other things. And I am saying you can't publish it. This actually is, this is a priority for your project, even if it's not a priority for you. So it can feel like an escalation for some of them, which then gets the social capital, which gets into wording things, which gets into all sorts of other stuff, but realizing. That's why I didn't do the tickets before that sort of thing. Mentally, this is going to feel like an escalation for some of these people, particularly the people who are really bad about getting back to me, and that's going to be social capital. There's a lot of things there, but being actually explicitly told by my boss, if this happens, make those tickets. Do something like that. Show the paper trail, create it and sort of create that visibility. Stuff like that's been useful. I feel like I want to give something, though, that isn't so process oriented. I guess too there's a concept in the indie role playing gaming sphere, at least from a long ass time called Fail Forward. It's also kind of improv concept and stuff, and in the realm of tech writing, I've embraced that saying, like, Okay, if there's some sort of decision that's being made that I think is going to cause problems down the road, sometimes I just have to accept doing it and letting the failure happen and documenting it and document instead of holding it up until we get the perfect solution that I'm trying to go for is for us to risk fail and fail forward and to go ahead, be okay failing, failing sort of publicly or whatnot, learning from it and moving on. That satisfies some people's need to publish now, while also accounting for risk management and documenting your hypothesis and then seeing if it's true or not, but the idea is: be okayfailing forward, instead of just getting soft locked in your head about stuff. And after getting laid off back in 2023 I was so soft locked for a long time that it was hard to get back in that fail forward thing. It's an intentional thing to think about, to have to do. It is at least for me. So it's advice that I have to repeat to myself, and that's what is one of the things. I learned from my time in role playing games that was just a principle in games of like, if your character fails, cool, make it cool and fail forward. Don't just be flat about it. I extend those two words into something different in real life than in the narrative world. Kate 54:42 Which brings us a really nice full circle back to how we started this episode. So thank you, Ryan. You tied that up in a nice little bow for me. I love it. Ryan 54:52 Excellent. I didn't intend to do that, but weirdly, that's actually a thing that I frequently end up doing anyway. Kate 54:59 Well, thank you, my friend, this has been an absolute delight. I'm so thankful we got to have this chat, and I'm also really excited to share a lot of these resources with the broader community, because I think these are the kinds of conversations that are especially important in our field right now, things that we think about that AI doesn't think about. Ryan 55:21 Yeah, I am not opening up another can of worms on the podcast right now. We had a good ending point, but I'm shaking my fist at not AI specifically, but at the culture. Kate 55:34 the decisions being made around AI. Maybe leave it at that. These are the kinds of things that we as human beings, as tech writers, bring to the table and ways that we can offer perspective and strategy that is way different from anything you're gonna get from an automated process. And the more we can center that and continue to provide that expertise, I think the better the world will be, and the less stressful the docs experiences will be and that's great. Ryan 56:02 And because at this point, we can't escape a world with AI doing things. It gives us lenses, frameworks, abilities, whatnot, to use that stuff that's generated by AI to validate it, to interpret it, to reinterpret it, things like that. So I'm not a person who doesn't use AI, at least within the realm of technical writing. But this gets into well, when you use it, don't stop thinking about the human aspect. Or am I not your boss? You do what you want. Kate 56:45 Well, thank you, Ryan, for all of your wisdom and insight today. Kate 56:54 The Not Boring Tech Writer is co-produced by our podcast head of operations, Chad Timblin, and me. Post production is handled by the lovely humans at Astronomic Audio with editing by Dillon, transcription by Madi and general post production support by Been and Alex. Our theme song is by Brightside Studio. Our artwork is by Bill Netherlands. You can order The Not Boring Tech Writer T shirts, stickers, mugs and other merch from the merch tab on thenotboringtechwriter.com. You can check out KnowledgeOwl's products at knowledgeowl.com, and if you want to work with me on Docs, knowledge management, coaching or revamping an existing knowledge base, go to knowledgewithsass.com that's knowledge with sass.com. Until next time, I'm Kate Mueller and you are The Not Boring Tech Writer.