Skill #29: Understanding Your Reader (as a Whole)

What's good everyone? My name is Jacob Moses and welcome to another episode of the Not Boring Tech Grader. In each episode we focus on a different skill that you can learn to enhance your skill set, improve your marketability, diversify your career, and ultimately break the stator type. That technical writing is a boring career. This episode's skill? I'm understanding your reader as a whole. One of the most important skills tech writers can have is the ability to analyze their audience. Researching who is using the product they're documenting, understanding how they use the product, and most important, ensuring their goals are reflected in the documentation. But as tech writers research their audience, digging deep into insights such as demographic and preferred device, tech writers can, in middly, get caught up in the technical side of audience analysis, and dismiss opportunities to understand their reader or user as a whole. That's why in this episode we have Alexander Yantt on the podcast. Occupational therapist turned tech writer advocate, who, as he searched for tech writing opportunities for himself, has reflected on his time in healthcare, to share must have insights for tech writers hoping to better understand their audience. In this episode, Alexander shares that you can understand your readers as a whole, including why empathy is one of the most important aspects of audience analysis, how tech writers can boost their audience analysis skills, and how effective audience analysis can demonstrate your value as a tech writer. And just ahead and step before we get into the episode, there are a few audio issues throughout. I think I was wearing my new coat, which I was an oversized collar and the microphone is rubbing against it now and then. So forgive me, there's not too many, and we'll not wear that coat for future episodes. That's all I can promise. Thanks y'all, enjoy the episode. (Music) Alex, what's going on friend? How are you today? Hey Jacob, I'm doing well, man. How about yourself? I'm doing good, thank you. So excited to be chatting. How's life in Chicago? Absolutely, Chicago life is good. It's just about to snow horribly on Monday, which for early November is kind of mind blowing, but we're taking it as it comes. It's always my best upper body workout to be and totally beats going to the gym for me, so I'll take it in stride. I feel it. Man, it's optional to get a little workout in, make it easy for your neighbors to navigate the neighborhood. Exactly. Sounds like a nice little task. Right on, right on. Well Alex, really excited chat with you today. We have a great skill to discuss, and that is understanding your reader as a whole. And Alex, really excited to talk about the skill with you in particular, because you have a unique background. You're currently working as an occupational therapist, which of course as we'll discuss today, requires a lot of knowing who you're working with beyond, you know, just their demographic or the interest that actually takes understanding who they are as a whole and learning what their goals are. And now you're looking to get into the tech riding game. I've already taken a lot of great steps to do so. So really excited to hear your insights today. In my head, I really envision what you've pitched to me earlier, this marriage between, you know, the occupational therapist or anyone working in healthcare, and how they use empathy and their listening skills to understand who they're working with, and how that translates to tech riding as well. Super excited. Yeah, no, I'm too. Let's do it. To get us started. I know I already hinted a little bit about the work that you do, but I want to start to learn a little bit more about you. Can you tell us a little bit about the work that you've been doing these days? Sure. So I have a little bit of a mixed background, which you know, I'll certainly go into that and then why it's a good combination for healthcare and tech riding. Together, I started out at the University of Wisconsin-Madison Go Badgers. I got to give a shout out to my people over in Madison. Got a journalism background, which I know, you know, there's a lot of journalist strategic communicators or whatnot in the tech riding sphere. So, you know, an avid writer really enjoyed that part of schooling. Unfortunately, I never, they never mentioned technical riding as a journalism student. I think you kind of have to discover it on your own, which so I had I known about that avenue. I probably would have pursued it, frankly, but I was kind of looking for, what do I do with this journalism degree? You know, there's that whole scare about, oh, you know, journalism is potentially on the down and out. There's all these new technologies. What are journalists going to do? So I decided to take my skills in interviewing and, you know, listening and understanding people and took them to, as you mentioned, a healthcare route. I got a Master's in Occupational Therapy over at the University of Illinois, Chicago, because I really want to do that good one-on-one work with people and really be able to understand, you know, what has gone wrong with them, whether it be, you know, physically, mentally, emotionally, and be able to solve problems. Because, you know, in the end, a lot of what I like to do is to be a problem solver and to help people accomplish a task. And I think that that's a pretty common objective, but certainly is a common objective between technical writers and healthcare workers. You know, we're discussing before we start the podcast. I got a lot of love for the work that you're doing. My father's been a physical therapist for over 30 years here in Denton, Texas, working with the geriatric community, and a lot of the ways you describe to work, you know, getting to know people that you're working with, what their goals and priorities are, are sentiments that he shared as well. And he's a damn good listener. And I imagine you are as well, and I know we're talking more about why that scale is so central for the tech writer. So you've been working as an Occupational Therapist. You, of course, already had this interest in writing. You knocked out some journalism university. And now you're at the stage where you're thinking about, or you've committed to entering the process of making a transition into actually working into the tech writing fields. What inspired you to pursue this shifting careers? Certainly. Well, one of them, you know, I won't bug you down with the details. There are some legislative changes that make it a little bit more challenging to be a therapist at this time. There's, you know, Medicare is always changing how therapists are getting paid. And sometimes we think that the payment models are with the best, with the patients, best interests in mind, and sometimes not. This most recent change, let's just say that it's, it thinks of therapists as more ancillary services than primary services. And so between a mixture of not being exactly content with how that system is going and at risk of maybe not having a job in the near future if this trend continues, I kind of went back and said, Hey, what really got me into, you know, Occupational Therapy? What's the whole point of, you know, this endeavor? And also, you know, just thinking about it, I really missed writing. I really missed just the act of sitting down at a computer and plonking something out, you know, I'm not, I, I wanted to help, I wanted to inform, I wanted to understand people's problems, but I said, you know what, maybe this is the right avenue to do it. And I just wish I'd known about it earlier in college. So if any, if any journalism professors hearing this right now, please tell your student technical writing is a very good opportunity to write and to be, you know, paid well and to be in a good environment because I just wish I would have known about it earlier. Quick sidebar therapy, physical therapy, occupational therapy is evidence-based care and should be the priority. I'll say that just real quick and then we'll move on. Absolutely. No, we always use, we use evidence, we use, um, we use the data in order to, um, to back up our findings and back up our claims, you know, just as in, in tech writing, it's all based on facts rather than, um, you know, subjective statements. Yeah, I feel you. Well, Alex, so far in this journey from transitioning into, from healthcare and the technical writing, what associations have you picked up so far between where healthcare professionals, professional shines and where the tech writer shines? I know we've alluded to it for you, whether it's, you know, listening to your user to figure out what their goals are, you know, um, building our own empathy, truly understanding as a whole. What have you observed as you work in different kinds of communities and read different resources about tech writing to find that relationship between the two? Absolutely. So, um, I'll also mention that I have taken some other coursework and like user experience, um, because I kind of want to understand that element of, you know, how products are made and how people respond to various products. And, you know, between that and between my, you know, speaking with other technical writing professionals, um, I kept hearing that word empathy come up over and over again, empathizing with the user, empathizing with somebody who is having that problem and needs to consult the manual or consults, you know, the knowledge base in order to fix something, but probably in a frustrated state, they just want to get it done and they want you to give them the information very clearly and concisely. And I'd never, frankly, I never really thought about empathy like that. I come from a healthcare background where I think of empathy is, oh no, this, you know, traumatic incident happened to you where you have a new diagnosis or, um, something happened to one of your loved ones. Um, so it kind of made me rethink how can I apply this concept of empathy to somebody, you know, who's having trouble with an app or they can't install, um, a product correctly. So that took a little bit of some reshaping, the, the, the question in my mind, but then afterwards, I was able to apply not only the act of listening skills, um, that, you know, we learned in school, uh, where it's really all about, um, focusing directly on the user, asking summary statements to help to make sure that you understood exactly what they said and that you're not misconstruing it. Um, yeah, as well as just, um, being able to figure out, you know, being able to understand that even if somebody doesn't have some, you know, terminal terminal diagnosis or something wrong with them, um, biologically, that there is real suffering when you have to do something and we're all busy, we're all stressed. And we have this biological stress response when we can't figure something out and that it's the tech writer's job to understand that we all have these common stress responses and that we can actually be the ones to give better health to our users by solving the problem and by alleviating that rush of cortisol that comes into our bodies, you know, not to get too medical with it, but that rush of, that rush of stress hormones like, uh, that floods our bodies when we get, you know, anxious or, um, mad about some kind of problem that we're having, um, with whatever we're struggling with, especially if it's a really complicated concept that, you know, a tech writer has created a manual or a resource on. Um, so, yeah, there was a little bit of that, that after that process of being able to, I guess, in my own sense, empathize with how somebody can be suffering in a non-medical context, um, I got a deeper appreciation and then said, you know, I can really make a difference by writing a manual, um, which just, it just gave me a lot of joy and, uh, gave me a lot of, you know, sense of purpose and, and feeling that I'm doing something good for the larger community, which is a really nice feeling. Alex, that is so beautifully put, and I, I picture my own past experiences as a tech writer, you know, perhaps I'm looking through the support tickets, trying to figure out, you know, where my uses are struggling and how I can help, you know, address those struggles in the documentation. And, you know, sometimes we can be quick just to look at the ticket as just, you know, just some copy of someone struggling, not necessarily associated with a person, how they interact with the product. I love how you're taking that next step. Like, yes, I, I acknowledge that you're struggling, but how can we work together through this user journey to make sure that we address this struggle in future documentation? Absolutely, absolutely. If I'm a tech writer, you know, my attitude towards working with a user is just, you know, more surface level stuff, perhaps. Like, I want to figure out, um, what they're trying to achieve, document that, move on to the next piece. What do you think just that surface level interaction is missing when it comes to creating help resources or actually tapping into what the user actually wants to accomplish? Sure. So one thing that I know has been a debate, um, in the technical writing communities, and I guess these are experienced communities as well is, um, you know, user research as a technical writer does, and it probably goes company company as well. It does, you know, an organization have enough funds, have enough time in order for not only, you know, the user research or user experience team to talk with users and understand their pain points, and, um, potentially alleviates, um, said pain points. But the tech writer, do they have enough time to, you know, after doing this documentation, um, bring it to a potential user and say, you know, does this make sense? Can you, can we create a few workflows and can you, um, move through those workflows without getting confused or needing additional help? Um, and again, I know it's on a very case-by-case basis. If you're working in, you know, two or three-week sprints, um, it's like, you have to struggle even just to get the documentation done at the right time. So, you know, thinking about user research on top of that, it's like, oh gosh, that's, that's too much. But I really think that this part of being able to empathize with another person comes down to human-to-human interaction. And while I love, you know, Slack channels, emails as a way to communicate very quickly, um, between, you know, people from, you know, could be thousands of miles away, I don't think there's anything that really replaces that really human element of speaking to someone face-to-face and really picking up on those, like, subtle cues of, you know, somebody, um, you see their face kind of screws up a bit when they're mad, or their body kind of turns in words. You see, you can use a lot of those body cues that are just completely, um, you can't pick up on them, um, if you're using a digital medium. And I think we're, you know, becoming more desensitized to that because we're not doing as much face-to-face interaction. But it's so important for a tech writer to stay, you know, sharp with those subtle cues so that they can really, again, understand the humanity behind their users and also figure out how can I be a source of good for this person. Alex, it reminds me of the very first episode of the not boring tech writer we had. Dr. Chris Lam, he's a professor over at the University of North Texas, my alumni, had him on the podcast to discuss design thinking. So this concept of, you know, it's not for a company, just building a product and then making it public and then responding to how people react. Instead, it's building the product alongside your potential user. And it starts with, you know, a lot of asking questions, you know, so say, I'm trying to take an example. So I wanted to create a new podcast player and I'm talking with the homie Alex and Chicago. I want to figure out, you know, what he loves most about podcast players and why he uses them. And it was this really cool example. Anything could slam. Let us do a little demonstration about how we could practice it within our organizations. But it was really cool to see what the outcome was whenever we're having continual interactions with our users from the start. Do you think there's opportunities for us to adopt something similar when it comes to documentation? Like say, we wait to get feedback from our users once the documentation is already published. Do you think there's opportunities to, you know, maybe not have one-on-one conversations face-to-face. I know we're busy creating a lot of documentation. But do you think there's some low-lift ways that we can incorporate user feedback as we're starting to work on this documentation? I do. And I think that's, you know, as you said, there are a lot of resource constraints. And, you know, it would be the dream to just take an hour out of your day and talk with a bunch of users and say, you know, plop down the manual and say, does this make sense to you? Can you complete these workflows? Not always possible. Not often possible. So rather than do that kind of a system, I think you can try to get the best of both worlds. Potentially, you know, if you create like a small financial incentive and have people come to you for a shorter period of time. So that's, you know, even in just like a, you know, or use, I'm trying to think of the different tools there are now in order to digitally be able to, the digital user research tools that people use in order to track, you know, eye movements, track cursor movements, to figure out, you know, various workflows. And if there's comprehension of those of those workflows, we can use those digital tools so people can remotely be investigating your documentation and using your steps and your words to see if that's, um, will help them accomplish their goals. Uh, I think that's the, the primary point though I'm trying to say is, um, even though we're all busy, we're all stressed, um, by and large, you know, what is the work that we're doing to create the product, to market the product, to create the instructions in order how to use the product, you know, it would be nothing without the end users themselves. They are the ones that, um, that they're, they're the whole reason we're doing all this. They're the one that's, that's paying the bill and they're the ones that are doing this. So why just create something that in your mind is ideal and in your mind solves all the problems, but, um, perhaps looking at that different perspective and understanding the really unique situation that a lot of your users are in, um, can a, just make you a better product and give you better, um, you know, performance, which is, of course, a big business goal, um, but also can kind of take you outside of your own, you know, egocentric minds and help you see other perspective, which is not only you're growing as a human and an empathizer, but you're growing, um, as a, a good business professional. I love that, Alex. And then to continue this theme of, you know, the relationship between the healthcare professional and the tech rider, something that I've seen do really well with my current organization, StrongTowns, that kind of eludes to healthcare is peer to peer support. So at StrongTowns, we recently created a new form called the StrongTowns Community Site and it's an opportunity for, um, what we call members of the StrongTowns movement, um, to help one another with whatever action they want to take to make their community stronger. So for example, um, perhaps following the death of a pedestrian, um, you know, maybe there's a StrongTowns member inspired to start a tactical urbanism project in their neighborhood. And listen, so if you're unfamiliar with that term, tactical urbanism is really just taking whatever you have in your house and doing just a small intervention to slow the traffic in your neighborhood. So for law folk, this is brand new. Of course, they have that shared goal of creating safe streets, but they need to look to others who have done something comparable to be able to get, you know, the resources and the wisdom to take action. And I can totally see how this can maybe translate into tech writing as well, you know, if there's, we have a handful of really star users, um, of our product who, you know, are using it really well, understanding the ins and outs, but also great appetizers. I wanted the tech writer could, you know, help boost their capacity to help other users as they face their own challenges with the documentation. I imagine this really nice two-prong approach where, you know, I can look to the documentation. If I can't find why I need there, I also have the opportunity to work with this great super group of users to get that peer-to-peer support. Is this something that you've experienced as well? Yeah. Yeah, I have seen something like that, um, you know, especially in a lot of the techy blogs and forums. I'll be the first one to say I'm not nearly as skilled in the ins and outs of Unix, Linux, you know, all the, you know, SQL and all the little nitty-gritty. So I certainly have gone to those, those, you know, really techy guys in order to understand, you know, what goes on in a complex problem. And they are, you know, they are some of the most compassionate, helpful people that I've run into. Because it takes a long time to go on to one of those forums to look at all of these user requests to be able to problem solve probably by yourself and then type it out using some of your own valuable time without, you know, any compensation. And so I think another example of reframing empathy, it's not necessarily just, you know, in like a healthcare setting where you are, you know, bandaging somebody's wound or you're taking care of them, calming them down. Even something as simple as responding to somebody's, um, frustrating technical problem on a website or doing it completely without expecting anything in return, which is I think the most, you know, is bordering on altruism, really pure empathy, um, without, you know, any kind of compensation. That is very admirable. And I think that, like you said, there's a lot of early adopters that are huge, um, like poster children of the product that you're using, that they believe in the mission of the company that believe in the vision, they believe in the product. And if you can, you know, reward those people or at least empower them to help out, like you suggested, I think that's a, that's a great idea. Um, you can even give them a distinction of, you know, insert product or insert company here, um, uh, and then put some, you know, very cool title, uh, uh, for them. And they could be, they could be running the show to a certain extent and really being a, um, being a huge help to your technical support team. Um, and, you know, reducing customer calls to your center, saving you money. Essentially, it's one of those very rare win-win situations where you're giving somebody else the power to, um, be part of something bigger, and especially somebody that you've never met before, but it's just like a brand leader of yours, um, and also reduce costs. So it's, it's a great win-win. And I think that's a really powerful, um, it's a really powerful idea that you just brought out there. And I'm fully in support of it. And it reminds me, um, another podcast in the past with Bri Hilmer, she discussed just in time documentation. And, um, with her company SurveyGizmo, they do something really cool to, you know, practice empathy and, of course, to demonstrate the value of the tech writer. So whenever, um, say a support to get comes in Alex, the support person looks at it. I think I'm trying to recall how Bri explained this, um, but listens to be curious after I share this. I'll include in the show notes so you can, you can peep it, but I think she explained it as, you know, the support person looks at this and they ask themselves, is, like, is this generalizable? Like, is this just a fringe question, or is this something that I imagine future users asking as well? And if it's the latter, um, he or she will immediately send it over to Bri, who will just do, um, document it real quickly, especially if it's something simple. You know, like, say, I'm trying to upload a new podcast, um, same having difficulty finding the audio file. You know, we don't need 10 pages of documentation to answer that. Probably just a few paragraphs on the screenshot. So what Bri has pioneered as SurveyGizmo has worked really well is that if it's generalizable, and she can knock it out real quick, she'll immediately document that piece and then send the new kb article right back to that user. So and then she'll comment, comment to some dialogue saying, you know, thank you for this question. Like, we, we agree, there's something that others mentioned with us. Well, you know what, we went ahead and add this to our knowledge base. Thank you so much for contributing knowledge base. And here's the answer for you to upload that podcast. And she said that she's just seeing, um, just the engagement, the community skyrocket from that, and where, where people are willing to reflect to, um, the knowledge base is supposed to call and support. But just such a cool example of, of course, practicing empathy, like, hey, this person probably wants to get this podcast up. I bet they recorded something really dope that they want to share their listeners, but they have trouble finding the MP3 file. So practicing the empathy to understand what they want to accomplish, and then demonstrating the value of the tech writer where that quick turn around, um, really fantastic system that they have in place. Yeah, and I think that I really like that episode. And she, you know, her talking about her system gave me a lot of ideas. Um, and I think she, she brought up, uh, that you can be empathetic as well by, as you said, having a quick turn around time. And that, um, you know, another, we have so many, so many ways to stress us out, right? Um, another, another stressor potentially could be waiting for a ticket response and, you know, sure, times times and one way to reduce, you know, again, empathizing with people's frustration and pain of not getting that instant answer, um, is to a be responsive and be, you know, be thinking one step ahead and that just in time documentation is kind of a combination of those two, where you are anticipating to an extent, you're understanding what, what the big problems are, you're anticipating. And then you are responding quickly. So that means that you really value, um, you know, the user's time and attention rather than just saying, Oh, you know, this is a, this is a priority. We'll get to it eventually. Um, it's, it's showing rather than telling, showing that you really do care and that you want to resolve things quickly. I think that was really cool. Beautiful. Alex, I got a final question for you. So say a tech rat, say a tech rat is listening to this podcast. They've been in the game for a bit now, perhaps they've been a bit jaded about the process, you know, all these support tickets are coming in, perhaps you're feeling overwhelmed and as we can all empathize anytime we feel overwhelmed with work or feedback, we can maybe lose sight of finding that human connection with the people that we're working with. From your experience, both as a health care professional and then the great steps that you've taken to get into the tech writing game, one of a few steps that the tech rat can take today to help you know, rekindle that human connection in their work. I think a lot of it is just kind of, as we've talked about a little bit before, taking a step back and understanding, you know, what, or even thinking about what's the point of all this? Why am I doing the work that I'm doing, you know, um, so kind of reframing your experience? But I think the primary thing that I do when, you know, of course it's, uh, in health care as well, there are lots of people to treat, lots of emotions flying everywhere and you don't have a lot of time and to do it and sometimes your manager's not available, I think when you have all of those stressors that are building up, my favorite thing to do is to just take about anywhere between two to three minutes and just be doing some deep breaths. You hear it all the time, I know that I was one of those people that was like, oh yeah, deep breaths, yeah, yeah, yeah, I breathe all the time without even thinking about it, you know, what's, what's the big impact? Um, and I think especially when you're in that, that anxiety, that go-go-go mentality, you're like, I don't have the time to breathe, I gotta keep going, I don't have the time, um, all I can do now is just keep pushing ahead, uh, and not really be thinking about, you know, my own well-being. But the thing is we can't be good, we can't be good supporters, whether it be in a health, in a healthcare realm or in, you know, a technical writing realm without taking care of ourselves first. And I think if you're pushing too hard, if you're pushing yourself too hard and you are kind of out of that balance, uh, then you're not going to do as good work. And, and, you know, being able to reset yourself, uh, really doesn't take that long. Um, I was member of an organization that, uh, dealt a lot with meditation, mindfulness, um, practices that are, you know, very simple, that again just really involve, um, taking about, taking some time to recollect yourself, focus on the breath, um, let things kind of come and go rather than just attaching to them and let them, really dig into you and frustrate you. And, you know, my meditation practice, uh, has really helped me, um, again, get that better perspective and kind of get out of my own head and my frustrations to let those, let those negative feelings pass. Um, and I know that there's a lot of, a, a big push, especially in, you know, their Salesforce Google, um, these bigger companies to have, um, you know, mindfulness and wellness spaces and classes. So that, um, increases, you know, user product, or, um, employee productivity, um, just as well as, uh, employee feelings towards the company itself. And so I think that's learning, making sure that you're taking care of yourself is, as, as well as you can, um, in order to do the best for people that need taking care of a, you know, AKA your end users, you know, that you're serving. That is the most important way to reconnect with that passion that you have for writing and writing for a very important purpose. And so I'm not saying everybody go out and get a meditation practice, but figure out what works best for you. Um, that's, yeah, that would say that was the, that's the big thing. Beautiful. Thank you for that, Alex. That was lovely. That was a nice reminder for myself as well. I think we're going to hop on the Zabuton pillow after this podcast. I've got a Zabuton pillow outside. I love it. Well, Alex, thank you, friends. You've been an absolute joy in. Um, I know this is a really exciting time in your life. You've been doing fantastic work on occupational therapists trying to get into the tech writing game. I know I speak on behalf of all listeners of this podcast where we're rooting for you, man. I mean, this is a beautiful field. Um, it sounds that you're already in a lot of the right channels to, you know, build that network and join this community. I know you're messing with the right, the docs slack. You're peeping the not boring tech writer, Tom Johnson's, I'd rather be writing. So we are for you, friends. And I've really enjoyed this. You shared some excellent insights and once and not only will help us be better tech writers, but from how you described it, um, just better people overall. We can help our aging parents help our end users. You shared a lot of skills in this help us be better people today. I appreciate that, Alex. I appreciate it too, Jacob. And you're doing great work with strong towns, um, you know, keep that up. And I, I loved hearing what you were, what you're saying, what you're, what you're, what you're doing right now and the mission. And I hope that, you know, gives you lots of happiness and joy. Thank you, man. Well, Alex, where can people holler at you online? When people connect with you, they want to learn more about the, the work you're doing and your journey as a soon to be tech writer. Yeah. So I, I'm primarily on LinkedIn, um, my, my full name is Alexandria Ants. Got to, got to keep it fancy. I got the full name Alexandria, even though it go by Alex. Um, I got a website, um, Alexandria Ant.com. I've got my resume up there, project samples from, from past things I've done. I actually have done a podcast myself, uh, started a health-related nonprofit a while back. So I got lots of, lots of cool samples. People can check out. Um, and I'm also on Twitter, uh, at Alexandria Ants. So, um, give me a holler. I follow back, uh, as long as you're not a bot. And there are no bots in this program. So I will follow back. Beautiful. And listeners will make sure to include all of Alex's social profiles and the show notes below. Alex, thank you, friend. I appreciate everything on a Saturday morning. We will publish this shortly. Absolutely. It's been, uh, it's been a blessing. I appreciate it, man. Yeah. Thanks, Alex. Talk soon. Talk soon. Thanks again, the knowledge I will create is of the wonderful knowledge based software for sponsoring the not boring tech writer podcast. And thanks so much to each of you for listening to this episode. [Music]