In this episode, I talk with Dennis Dawson, a technical writer with 40 years of experience who creates the sketchnotes for Write the Docs talks. We talk about how humor and visual elements can make documentation more engaging and memorable, the science behind why graphics help information stick in long-term memory, practical tools and techniques for adding visual content to your docs, and why you don't need to consider yourself an artist to create effective illustrations that enhance your documentation.
Dennis and I discuss his unconventional path into technical writing, starting with an English degree and progressing through roles as an editor, typist, secretary, and eventually desktop support in the early days of personal computing. His technical writing career began at startups in the 1980s, where he combined training and documentation work. Throughout his 40-year career, Dennis has consistently advocated for using humor and visual elements in documentation.
Our conversation centers on the science behind why visual content and humor make documentation more effective. Dennis shares how reading Richard Mayer's Multimedia Learning and Barbara Oakley's books on learning validated many of his instinctive approaches. We explore concepts like how visual information sticks in long-term memory more easily than text, the importance of reducing cognitive load through strategic use of graphics, and how breaking up text with visuals gives readers' brains time to process information by switching between focused and diffuse modes of thinking. Dennis also discusses when to use graphics and shares examples like using whimsical robot characters to represent different software components.
We dive into the practical side of creating visual content, including Dennis's collaborative approach of sketching ideas and working with design teams to polish them into professional graphics, and tools like Gimp, Inkscape, Keynote, and Google Slides that make visual creation accessible. Dennis emphasizes that you don't need to consider yourself an artist to create effective illustrations—the key is getting over your reticence and recognizing that drawing is a skill developed through practice, not innate talent. We also discuss his approach to creating educational videos, including using Doc Detective to automate video updates when UIs change. Throughout our conversation, Dennis stresses the importance of using visual humor and plain language to help make documentation digestible and accessible.
About Dennis Dawson:
Like many baby-boomers, Dennis still hasn't decided what he wants to be when he grows up. He's a technical writer with 40 years' experience in technical communications providing documentation, training, and user support; a sketchnotes artist for Write the Docs; a 3-time Distinguished Toastmaster and Past District 57 Governor who's won District Champion titles in Humorous, Tall Tales, and Evaluation contests; a volunteer Santa Claus at San Jose Christmas in the Park; and a volunteer drawing teacher at local elementary schools.
Resources discussed in this episode:
Join the discussion by replying on Bluesky
—
Contact The Not-Boring Tech Writer team:
We love hearing your ideas for episode topics, guests, or general feedback:
Contact Kate Mueller:
Contact Dennis Dawson:
Contact KnowledgeOwl:
In this solo episode, Kate shares an update on her content update progress. She also reflects on Fabrizio Ferri-Benedetti’s interview (S3:E20) and the ways exploring models like his Seven-Action Documentation model have helped her interrogate her own beliefs about tech writing, the benefits of self-knowledge in becoming a better writer, and the ways that maintenance docs work helps her recharge.
I’ve continued my work to update the KnowledgeOwl Support Knowledge Base to align with major navigation and UI changes that we rolled out in December, and I’m finally nearing the light at the end of the tunnel: my initial punchdown list has less than 50 articles remaining! Along the way, I’ve also had to re-update docs I already updated as we rolled out more changes to existing features–ahhh, the life of a tech writer.
In his interview, Fabri mentioned that part of his motivation for creating the Seven-Action Documentation model was a frustration that people were taking frameworks like Diátaxis and just rote-applying them to their documentation. We discovered some very deep common ground: that models and frameworks are useful because they help you, as a writer, surface and interrogate the deeply-held beliefs you have about technical writing. They’re tools for exploration rather than step-by-step guides on what to do. In my case, engaging with the Seven-Action Documentation model helped me realize how strongly I felt about appraisal and troubleshooting as user needs. While I’m not necessarily crafting new content templates to handle this, my site structure has naturally incorporated them, and I’m now exploring the idea of review checklists or user journeys that might help me assure that I’m handling all the user needs in some way.
I’ve also been sick with Covid, which slowed down my velocity for more strategic, creative work and prompted me to return to a lot of maintenance work. Fabri mentioned that maintenance work helps him recharge, and I found the same thing. I often call maintenance work “productive procrastination”, since it’s not usually the single most important thing, but it is something I can do when my energy or focus are low so that I’m still improving my docs every day. Consider this your invitation to spend the next month paying attention to which writing tasks fill or drain your cup, what kinds of energy those tasks demand, and how you can better manage that moving forward.
Resources discussed in this episode:
Join the discussion by replying on Bluesky
—
Contact The Not-Boring Tech Writer team:
We love hearing your ideas for episode topics, guests, or general feedback:
Contact Kate Mueller:
Contact KnowledgeOwl:
In this episode, I talk with Fabrizio Ferri-Benedetti about moving beyond strictly following documentation frameworks to embrace strategic thinking, his Seven-Action Documentation model that prioritizes user needs over content types, and how technical writers can grow and adapt in the AI era while positioning themselves as essential strategic partners.
Fabri and I discuss his background as a cognitive psychology student who transitioned into technical writing through his love of computers and writing. He shares his journey from academia to becoming an editor at Softonic, and eventually to his current role as a principal technical writer at Elastic working on OpenTelemetry documentation. We explore his concept of technical writers as shapeshifters who adapt to different roles and contexts.
The conversation centers around Fabri's Seven-Action Documentation model, which he developed as a more descriptive and user-focused alternative to prescriptive documentation frameworks. Unlike content-type-focused approaches, his model identifies seven key user actions that address real user needs that are often overlooked by traditional frameworks. We discuss how this model encourages writers to think strategically about user needs rather than simply following rigid content templates, and why starting with user needs rather than content types leads to more effective documentation.
We also explore professional growth for technical writers, particularly in the AI era. Fabri emphasizes the importance of meaningful skill growth, advocating for work that demonstrates strategic thinking rather than just high-volume output. He shares his philosophy of embracing AI as a tool while maintaining critical evaluation of its limitations, arguing that technical writers must understand emerging technologies to maintain credibility and influence in organizational decisions about documentation and AI implementation.
About Fabrizio Ferri-Benedetti:
Fabrizio Ferri-Benedetti is a technical writer and documentation engineer with over 15 years of experience. Through his blog Passo.uno, he shares insights on documentation strategy, API design, and the evolving role of writers in the tech industry. When not championing better documentation practices or contributing to open source projects like OpenTelemetry, he explores ways to make technology more accessible.
Resources discussed in this episode:
Join the discussion by replying on Bluesky
—
Contact The Not-Boring Tech Writer team:
We love hearing your ideas for episode topics, guests, or general feedback:
Contact Kate Mueller:
Contact Fabrizio Ferri-Benedetti:
Contact KnowledgeOwl:
In this solo episode, Kate shares an update on her content update progress. She also reflects on Sarah Walker’s interview (S3:E18) and the concepts of Asteya, giving great service, and going the extra mile.
I’ve continued my work to update the KnowledgeOwl Support Knowledge Base to align with major navigation and UI changes that we rolled out in December. I also created about 30 articles for the launch of KnowledgeOwl’s new Owl Analytics feature, taking my total to 618. 🎉
Sarah’s interview gave me a lot to think about, and I spent the bulk of this episode reflecting on some key points from that conversation. First, I focus on the concept of Asteya she shared, in the context of not stealing time and energy from other people. This concept is so central to well-written documentation and is a compelling argument in favor of clear, consistently applied style guidelines. I coined the phrase “Style guide adherence is an anti-theft device” to summarize this idea. Our conversation reminded me so much that creating great documentation is an act of giving great service. I outline the three-step guide to giving great service that KnowledgeOwl uses, which is based on Zingerman’s Guide to Giving Great Service: 1) Find out what your customer wants; 2) Get it for them accurately, politely, and enthusiastically; 3) Go above and beyond, or go the extra mile.
Step one is often the hardest piece of giving great service since people often don’t know how to articulate what they actually want. At KnowledgeOwl, we use Disney’s “What time is the 3 o’clock parade?” example to show our new support and success owls how what someone asks for isn’t necessarily the question they want answered.
Great documentation helps deliver step two by creating the accurate answers your readers need.
Step three ties very nicely back to statements Sarah and I both made—about the idea of crafting a solid experience for others in our documentation, of distilling what they need and making it as streamlined as possible. This discussion builds on the ideas of craft we’ve previously discussed, the idea of care I discussed in Episode 17, and Sarah’s comments about crafting something FOR others. Sharing knowledge is an inherent piece of our humanity and of building human communities. Documentation isn’t merely transactional—it’s also an act of care, a gift of time and knowledge, and a gift of saved time so people can pursue other interests.
Resources discussed in this episode:
Join the discussion by replying on Bluesky
—
Contact The Not-Boring Tech Writer team:
We love hearing your ideas for episode topics, guests, or general feedback:
Contact Kate Mueller:
Contact KnowledgeOwl:
🎓 Our host, Kate Mueller, is teaching a 4-session Information Architecture Master Class that starts on September 16th!
🎧 TNBTW listeners can use the coupon code "NOTBORING" during checkout to save 40% off the list price!
🔗 Read more info and sign up: thenotboringtechwriter.com/learning
—
In this episode, I talk with Sarah Walker, a technical writer and yoga instructor, about how yoga principles like establishing foundations, respecting people’s time, and embracing practice over perfection can transform your approach to technical writing and help you create more mindful, user-centered documentation.
Sarah and I discuss her path into technical writing, which began with yoga instructor training where she discovered how much she enjoyed breaking down complex processes into foundational steps. This experience taught her that effective instruction—whether for yoga poses or technical procedures—requires understanding your audience's needs and building from core principles. We explore how yoga's emphasis on establishing solid foundations directly translates to documentation, where starting with fundamental concepts helps both beginners learn and experienced users refresh their understanding.
We explore the yoga principle of Asteya (non-stealing), particularly how it applies to respecting readers' time and attention. Sarah explains how this philosophy shapes her approach to writing clear, concise documentation that helps users efficiently get to their goals. We discuss practical applications like using consistent style guidelines to reduce cognitive load and being mindful of which content is essential to include in your docs.
Our conversation also covers how yoga's concept of practice over perfection applies to technical writing careers. Sarah shares how documentation evolves alongside products and why embracing this constant change rather than striving for perfect static content leads to better outcomes. We explore the parallels between sequencing yoga poses and sequencing information in documentation, the importance of observing your audience's needs, and how both practices require patience, self-compassion, and continuous learning.
About Sarah Walker:
Sarah's been writing and crafting stories since she was able to put pencil to a Peanuts 3x5 top-spiral memo pad and record her stories in her own scribbly alphabet. Since personal alphabets scribbled on tiny pieces of paper don't pay the rent, she embarked on her career as a professional writer and editor after graduating from St. Edward's University (Austin, TX) in 1998. As an industry editor with Hoover's for roughly seven years, she covered biotech, pharmaceuticals, health care systems, venture capital, investment firms, and other sectors as a member of the Finance and Health Care editorial team. She earned her Austinite bone fides by getting hired by and, 18 months later, laid off by Dell, where she served as a technical editor for the Global Technical Training and Curriculum Team for products and software for consumers as well as small and midsize businesses. Thanks to the Great Recession and other market forces and personal demands, she bounced around a bit from writing and editing features, self-help book summaries, U.S. Pharmacopeia monographs, and other technical-ish content.
She began her technical writing career in earnest at Libre Digital, where she spent much of the second decade of the 21st century documenting procedures for processing various magazine titles as well as a platform for book publishers to distribute their titles to digital marketplaces. After a two-year stint as the managing editor (and lone full-time, non-contract employee) of a local bimonthly magazine targeting affluent residents of "West Austin," at long last (in August 2020), Sarah landed a job that gave her the Technical Writer job title, and she's been writing about the Monetate platform ever since.
Sarah's second career as a yoga instructor (and briefly a Pilates mat instructor) began in 2005, after she completed her 250-hour instructor training with Yoga Yoga (now defunct, just like the college in Santa Fe, NM that she attended for the first two years of her undergrad studies). She taught part-time until 2012, when primary job demands and other responsibilities forced her to give it up.
Resources discussed in this episode:
Join the discussion by replying on Bluesky
—
Contact The Not-Boring Tech Writer team:
We love hearing your ideas for episode topics, guests, or general feedback:
Contact Kate Mueller:
Contact Sarah Walker:
Contact KnowledgeOwl:
🎓 Our host, Kate Mueller, is teaching a 4-session Information Architecture Master Class that starts on September 16th!
🎧 TNBTW listeners can use the coupon code "NOTBORING" during checkout to save 40% off the list price!
🔗 Read more info and sign up: thenotboringtechwriter.com/learning
—
In this solo episode, Kate shares an update on her content update progress. She also reflects on Manny Silva’s interview (S3:E14), Ryan Macklin’s interview (S3:E16), and Liz Argall’s interview (S3:E13) and the importance of learning even when we don’t have explicit reasons to do so.
I’ve continued my work to update the KnowledgeOwl Support Knowledge Base to align with major navigation and UI changes that were rolled out in December. I updated an additional 15 articles since my last episode, taking my total to 565. 🎉This month’s velocity was a lot lower thanks to prepping for, teaching, and attending KnowledgeOwl’s July 2025 Summer Camp workshop series.
While teaching the classes was fun, it also triggered a lot of issues with my chronic illness, so I finished the month quite depleted on every level. This made me think a lot about the ambient and acute stress Ryan and I discussed in relation to empathy advocacy, and about how all documentation makes demands on readers’ cognitive capital. I share five documentation techniques that helped me get use from docs when I was struggling the most cognitively:
I also reflect on how tricky it is to actually accommodate learning as a tech writer if I don’t have a pressing need for it. We learn new tools or domains often since it’s required. We learn new tooling or scripting to make our lives easier or because it’s required. We attend classes, conferences, or certifications. But we often don’t take time on less formal, bigger picture learning. I share how doing research to teach a class on style guides led me to find all kinds of flaws and oversights in my existing style guide. I challenge all of us to carve out 2-4 hours in the next month to dig deep on a best practice or concept we want to learn more about. If you lack the time or discipline and have a professional development budget, you can also consider joining me for the Information Architecture Master Class I’m teaching in partnership with KnowledgeOwl in September and October. Use discount code NOTBORING.
Resources discussed in this episode:
Join the discussion by replying on Bluesky
—
Contact The Not-Boring Tech Writer team:
We love hearing your ideas for episode topics, guests, or general feedback:
Contact Kate Mueller:
Contact KnowledgeOwl:
🎓 Our host, Kate Mueller, is teaching a 4-session Information Architecture Master Class that starts on September 16th!
🎧 TNBTW listeners can use the coupon code "NOTBORING" during checkout to save 40% off the list price!
🔗 Read more info and sign up: thenotboringtechwriter.com/learning
—
Learn how Ryan Macklin's "empathy advocacy" framework helps you design documentation that works for users in all emotional states (e.g. anxious, frustrated, exhausted, and curious/distractible) rather than assuming everyone comes to your docs in a perfect state of clarity.
Ryan and I discuss his unique path into technical writing, starting from his early computer hacking days and role-playing game writing background. Ryan explains how writing and editing tabletop games taught him that documentation is harder than technical writing because it requires creating user interfaces for "disconnected, squishy brains" while making content engaging enough that users won't simply abandon it for alternatives. This experience, combined with his personal journey through therapy and understanding neurodiversity, eventually led him to develop the empathy advocacy framework.
Our conversation centers around Ryan's empathy advocacy concept, which focuses on writing for users who aren’t calm. These users might be in four key cognitive states: anxious, frustrated, exhausted, and curious/distractible. Rather than designing documentation for the "happy path" or optimal users, Ryan advocates for considering people who may be dealing with high ambient stress, acute stress from urgent problems, cognitive depletion, or distractibility. The "stupid users" developers complain about are often just busy, stressed people whose brains aren't optimally processing information.
We explore practical applications of empathy advocacy concepts, including strategic screenshot reduction to minimize cognitive load, restructuring and tightly scoping FAQs to avoid information architecture problems, and understanding that every element in documentation has a "tax" on your user’s mental energy.
The episode also includes practical advice on social capital management, documentation stewardship, and the importance of "failing forward" rather than getting stuck in perfectionism.
About Ryan Macklin:
Ryan splits his cerebral time between tech writing, UXing, coding, and game design. By day, Ryan writes and edits software and hardware requirements. Otherwise, he works on game or tooling projects, light woodworking, and land improvement projects on his homestead in southern Michigan. Warning: Ask him about UX in games, and he may talk your ear off.
Resources discussed in this episode:
Join the discussion by replying on Bluesky
—
Contact The Not-Boring Tech Writer team:
We love hearing your ideas for episode topics, guests, or general feedback:
Contact Kate Mueller:
Contact Ryan Macklin:
Contact KnowledgeOwl:
In this solo episode, Kate shares an update on her content update progress. She also reflects on Nick Graziade’s interview (S3:E12) and Liz Argall’s interview (S3:E13) and the ways these interviews highlight some elements of “good” docs experiences.
I’ve continued my work to update the KnowledgeOwl Support Knowledge Base to align with major navigation and UI changes that were rolled out in December. I updated an additional 43 articles since my last episode, taking my total to 550. 🎉 I’m in the middle of updating our Contextual Help Widget documentation—one of the features I’ve been putting off updating—and I’ve been drafting content for our forthcoming AI Chatbot feature, too.
Nick and I share a tech writer villain origin story of absolutely adoring LEGO documentation, and it’s gotten me curious how many other tech writers also have this early exposure to documentation. And for some reason I’m seeing tech writing everywhere. I share a detailed story of Bont Cycling’s online shoe fit guidance, which I recently used and which has created a fairly positive product experience for me. Good documentation experiences can help create good product experiences.
I also reflect on Liz’s comment that “The best fertilizer is the gardener’s shadow.” She talked about this in the context of just showing up to work on docs, but I extend that metaphor to say showing up working with care. I gave two examples of this. I’ve been struggling with some personal losses, so a lot of my docs work lately has been a blitz of low-hanging docs fruit: a lot of small changes and improvements. None of these updates are substantive, but they’re good iterative improvements and they helped me get back into docs work. I also share a story of building a long-procrastinated-on bench for my entryway, which was more about accepting good rather than great just to get something built. Good docs are dynamic and iterative–they may not be perfect at first, but they’re constantly improving and always striving for a better reader experience.
Resources discussed in this episode:
Join the discussion by replying on Bluesky
—
Contact The Not-Boring Tech Writer team:
We love hearing your ideas for episode topics, guests, or general feedback:
Contact Kate Mueller:
Contact KnowledgeOwl:
In this episode, I'm talking with Manny Silva, a technical writer who created the "Docs as Tests" concept name and the open-source tool Doc Detective. We discuss how to automatically test your documentation for accuracy, why customer reports of broken docs are actually failed tests, and practical ways to implement automated documentation testing regardless of your tech stack.
Manny and I discuss his background as someone who intentionally chose technical writing as a career path, starting with early exposure to computers through his mother's work and developing into roles at Apple, Google, and now Skyflow as Head of Documentation. We explore the core concept behind Docs as Tests—that documentation contains testable assertions about how a product should work, and that customer reports of broken procedures are essentially failed tests that we should catch proactively rather than reactively.
We dive deep into how Manny's strategy works in practice, from the "cupcake to wedding cake" approach of starting small and scaling up. We dig into two different approaches to the technical implementation: creating “detected” tests using Doc Detective, which reads the docs directly and uses them as tests, and creating standalone tests in testing tools like Playwright or Cypress, which you’d create and update independently of the docs. Manny explains how his Doc Detective tool can parse markdown documentation, automatically execute the steps described in procedures, capture screenshots for visual regression testing, and even validate API responses against OpenAPI schemas. We discuss the business case for automated documentation testing, including how it prevents customer frustration, builds trust, reduces support overhead, and can catch bugs before they reach production.
Throughout our conversation, we explore practical implementation strategies, including how to sell the approach to stakeholders, integrate testing into CI/CD pipelines, handle multifactor authentication challenges, and work with QA teams. Manny also shares his philosophy of creating a "zero trust" relationship between docs and product—not out of disrespect, but to ensure everyone stays honest about the behavioral contract that documentation represents. Docs as Tests also encourages technical writers to embrace their unofficial QA role–as writers, we’re often the first to test a new feature or product, and embracing a Docs as Tests mindset can help legitimize and make visible this role.
About Manny Silva:
Technical writer by day, engineer by night, and father everywhere in between, Manny wears many (figurative) hats. He's passionate about intuitive and scalable developer experiences, and he likes diving into the deep end as the 0th user.
Here are a few things that keep him busy:
He's always looking for collaborators on projects, and he loves chatting with folks, so don't hesitate to reach out.
Resources discussed in this episode:
—
Contact The Not-Boring Tech Writer team:
We love hearing your ideas for episode topics, guests, or general feedback:
Join the discussion by replying on Bluesky
Contact Kate Mueller:
Contact Manny Silva:
Contact KnowledgeOwl:
In this episode, I’m talking with Liz Argall, a writer I connected with at Write the Docs Portland 2025. We talk about working on open source projects, developing good qualitative metrics, her work with a permaculture nonprofit in Uganda, and the ways that being interviewed by a technical writer can make hidden expertise shine.
Liz and I presented in the same Lightning Talk session at Write the Docs Portland 2025 and subsequently discovered a shared love for spreadsheet tools, qualitative metrics, and permaculture. We discuss her work on Project Aria, a combination of hardware, software, and data collection geared toward solving the problems that augmented reality will need to address. Liz stresses the point of writing for poorly informed and/or sleep-deprived audiences. We also discuss the importance of qualitative metrics and some of Liz’s favorite qualitative metrics that help capture the story of the documentation, including impact and saving engineers’ and SMEs’ time.
Liz also tells us about her involvement with Ngombor Community Development Alliance, a non-profit focusing on permaculture development in the West Nile region of Uganda. We also discuss how sometimes just showing up for something–including showing up to work on your docs–has far more impact than we realize.
About Liz Argall:
Liz Argall creates empowering documentation and processes; where you need it, when you need it.
She’s a technical writer, program manager, author, and trainer who delivers humanizing, data informed, accessible, and technically complex projects for a range of organizations, from Fortune 500 companies to a community development organization in Uganda.
In a past life, she was a professional artist talent scout and she’s still a professional member of SFWA (now called the Science Fiction and Fantasy Writers Association). She’s a graduate of Clarion Writers Workshop, has been critiqued by multiple New York Times best selling authors, and has critiqued the stories of multiple award winning authors, which is a long way of saying that she likes to give a good portfolio critique!
Resources discussed in this episode:
—
Contact The Not-Boring Tech Writer team:
We love hearing your ideas for episode topics, guests, or general feedback:
Join the discussion by replying on Bluesky
Contact Kate Mueller:
Contact Liz Argall:
Contact KnowledgeOwl:
—
Transcript
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 lovely, not-boring tech writers. This month, we kind of have a little change up. Normally, this would be a solo episode, but in a nod to Write the Docs as well as some personal stuff I have going on, we decided we'd do a bonus interview episode instead of a solo episode, and maybe I'll be really productive before the next solo episode, so you won't know how unproductive I've been in the last month. So with that in mind, welcome to another interview episode. This month's guest is definitely a Write the Docs special. I had never met her before Write the Docs. And lo and behold, we ended up giving a lightning talk in the same lightning talk session, and that led to us kind of connecting socially during the event, which is a very Write the Docs thing, and as a result, she's here on the pod, because I think she's an amazing human being, and she's had a really interesting array of work experience, and we have a shared love for spreadsheets and matrices. So without further ado, I would like to welcome you to the pod, Liz Argall. Liz, welcome to the show.
Liz 1:22
Thank you so much for having me. And I should say, as we discussed before, I'm a big permaculture fan as well. And you know, you gotta follow the seasons, and having a little bit of fallow resting the soil is not unproductive. It's listening to your body and building capacity for other kinds of productivity.
Kate 1:40
So Liz, can you tell me a bit about your tech writer villain origin story? How did you end up getting into this field in the first place?
Liz 1:50
When I was seven years old, there were some contractors working on our house, an extension on our house, and I was fascinated with them. And my dad noticed that I was fascinated, and he said, “You should go interview them and write about it,” because that's the sort of dad I had. In my little notebook I interviewed them about, you know, putting in flooring and stuff like that, and what it was like. And I wrote it down. And because I went and wrote it down, you know, then suddenly we had more of a relationship. I...
In this episode, I'm talking with Nick Graziade, a technical writer and musician who approaches documentation as a creative endeavor. We explore how his early fascination with Lego instructions and synthesizer manuals shaped his philosophy that technical writing doesn't have to be dry or boring, but can be passionate and innovative work that adapts to different audiences and embraces impermanence.
Nick shares his two-part "villain origin story" that led him to technical writing. The first part involves his childhood fascination with Lego instructions, which taught him that visual documentation could guide complex building without narration. The second part comes from his music school experience with synthesizers, where he discovered that the best manuals—like those from Moog—don't just explain how to do something, but also why. This combination of visual clarity and deeper understanding became his template for approaching technical documentation.
We dive deep into the concept of using different "grammars" for different audiences, drawing from Wittgenstein's language games. Nick emphasizes that effective technical communication requires understanding what assumptions you can make about your readers and adapting your language accordingly. We explore how consistency in style and formatting reduces cognitive load for users, and how deliberately breaking those patterns can create powerful contrast for important information like warnings or alerts.
Throughout our conversation, Nick reflects on his philosophy of embracing impermanence in documentation. Rather than being frustrated by constant updates and revisions, he sees the evolving nature of technical writing as aligned with his Buddhist-influenced worldview. We discuss practical approaches to managing documentation workflows, including his use of quarterly revision cycles, just-in-time updates based on development sprints, and how he determines when something is "done enough" to move on to the next priority.
About Nick Graziade:
Nick is a Senior Technical Writer, instructional designer, knowledge management expert, musician, and philosopher from Upstate New York's Capital District.
When not obsessing over the nuances of a web page's navigation sidebar, you can likely find him playing gigs as a professional bassist or practicing Japanese sword arts.
Resources discussed in this episode:
—
Contact The Not-Boring Tech Writer team:
We love hearing your ideas for episode topics, guests, or general feedback:
Join the discussion by replying on Bluesky
Contact Kate Mueller:
Contact Nick Graziade:
Contact KnowledgeOwl:
—
Transcript
Kate Mueller: [00:00: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.
Kate Mueller: [00:00:19] Hello my fellow not-boring tech writers. I'm Kate Mueller and today's guest I'm really excited to have on the show. Today's guest has been a longtime guest blogger for KnowledgeOwl, which is how I first came across his work and knew that he existed. He did a series of blog posts both on single sourcing and then a whole bunch of stuff on grammar. I was like, "This is somebody I feel like I align with on a lot of things." I was very delighted when he said yes and agreed to come on the pod, so I would like to welcome to the not-boring tech writer universe, Nick Graziade. Nick, welcome to the pod.
Nick Graziade: [00:00:54] Thank you for having me.
Kate Mueller: [00:00:55] Thank you for being here. Just to start us off, to give the audience a little bit of knowledge about you, can you tell me what your tech writer villain origin story is?
Nick Graziade: [00:01:06] This one I have to tell you in two parts, because there's a subversive one that snuck into my brain, and another one that emerged later on in life.
Kate Mueller: [00:01:17] A two part villain origin story, you're a complicated villain.
Nick Graziade: [00:01:20] I try to be. I'm a complicated person with simple tastes. The subversion here, the thing that snuck into my psyche, started when I was about 3 or 4 years old. I don't have many memories from that, and I don't have many memories from the 1980s in general, but I was a little toddling one in the 1980s, and I got my first Lego set when I was that age. I remember looking at these instructions and I thought to myself, "Wait a second, I can build something without having to go through the complicated steps of actually narrating how to build this." I see these pictures and they tell me how to build something? That's brilliant, that's amazing. It became this massive dedication to the world of Legos and Lego instructions. I actually saved all my Lego instructions because I was like, "I'm going to build this again someday. I swear to God, I'm going to build it again someday." It never happened, it never honestly happened. But I was enamored by these documents, not really knowing what they were aside from, this is how you make spaceships or castles or what have you.
Kate Mueller: [00:02:35] A fun side fact, I also have a huge Lego background, and I am the person who both saves the instructions and takes them apart and rebuilds them. I do this even as an adult now. I've changed into the architectural series so it feels age appropriate, but I totally do this on a regular basis. I'm wondering how many tech writers have that Lego tie-in.
Nick Graziade: [00:03:02] I feel like a lot of us do. The fact that Lego Digital Designer, which is this software platform they created, they copped it from an independent Lego marketplace called Bricklink, which they acquired and then combined all their digital designer stuff into this massive, wonderful little sandbox that you can play with on your computer. I've definitely sunk way too many hours into that. The ability to copy and paste pieces of Legos was remarkable using this digital tool, because that set me into this whole cycle of creating really wild stuff that I wouldn't be able to create just due to physical limitations of what I own. So that was interesting.
Kate Mueller: [00:03:48] So Lego is p...
In this solo episode, Kate shares an update on her content update progress. She also reflects on Sue Brandt’s interview (S3:E10) and on the Write the Docs Portland 2025 conference.
I’ve continued my work to update the KnowledgeOwl Support Knowledge Base to align with major navigation and UI changes that were rolled out in December. I updated an additional 50 articles since my last episode, taking my total to 507. 🎉Most of the updates this month were in our payment and plan-related documents, which needed to be updated for a new Billing page user interface and to include changes from migrating to a Merchant of Record.
My velocity this month was lower thanks to teaching KnowledgeOwl’s Authoring 101 class and attending the Write the Docs Portland 2025 conference with Chad. Write the Docs is always a deeply inspiring conference for me, and this was my first time attending in person since 2019. This year, I even gave a lightning talk about dogs and docs, too!
Much of the episode is spent reflecting on the six things I most love about Write the Docs, which include its support for first-time attendees and presenters, the flexibility and thoughtfulness of its design, and the amazing community of documentarians who form the backbone of this community. This year’s conference had a fantastic selection of talks and speakers, including several previous and upcoming podcast guests.
Resources discussed in this episode:
—
Contact The Not-Boring Tech Writer team:
We love hearing your ideas for episode topics, guests, or general feedback:
Join the discussion by replying on Bluesky
Contact Kate Mueller:
Contact KnowledgeOwl:
—
Transcript
Kate Mueller: [00:00:05] 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.
Kate Mueller: [00:00:20] Hello lovely, not-boring tech writers. I'm Kate Mueller, and this is one of our solo episodes where I share things I'm thinking about or working on. I'm recording this episode in mid-May, right after attending Write the Docs Portland. First, my docs project progress update. Since my last episode, I've updated another 50 articles, taking my grand total to 507. This month's velocity was a bit slower since I spent time prepping for and teaching KnowledgeOwl's 'Authoring 101' class, and of course, attending Write the Docs. My big achievement for the month was a massive update to our pricing and plan related documentation. I removed a lot of detailed pricing info to default to our marketing website, and I also rewrote pretty much every existing pricing related doc we had. Most of these docs hadn't been substantively updated in the last five years. And in that time, KnowledgeOwl has been transitioning most subscribers to a merchant of record. We also recently released a total rewrite to the in-app billing page. Nearly everything here needed major content updates. And, just to make it more fun, since most of these docs were written by someone else long before our current style guide, they also needed to be updated to align with our current style and tone.
Kate Mueller: [00:01:45] This was one of those, "I thought this wasn't going to be a very big deal, and then it ended up being a lot more work than I thought". Have you sensed a trend? I think I'm just optimistic in thinking about docs work. Anyway, I did some major reorganization and was able to get a content review from Anne, our lead billing owl. She caught a number of small inconsistencies, as well as a few fun style and grammar suggestions. So not only are these docs much more up to date, but I also have far more confidence that they're consistent with our billing related support tickets. Normally, I like to reflect on our most recent guest episode during these solo episodes, and Sue Brandt's episode was full of good job hunting nuggets and tips, but I'm not sure there's as much for me to reflect on here other than to say, "Yes". Many of the things I like to do while job hunting are actually reasonably good ideas, but I did appreciate her constant reminder to ensure that all materials accurately reflect your skills as a writer. Having a resume and cover letter with sound structure and well-written content that doesn't get too stuck in the weeds while highlighting the things most relevant to both a first round recruiter and a final round hiring manager. I also found it encouraging that there are still hiring managers out there for whom demonstrated skills in writing and the ability to learn, combined with a depth of enthusiasm, far outweigh experience with specific tools or tech stacks.
Kate Mueller: [00:03:19] The main thing I want to talk about in this episode is Write the Docs Portland, which Chad and I both just got back from. If you've been listening to this year's episodes, you've probably noticed the theme that Write the Docs comes up a lot. Either as a way I've met people or as a recommended resource from some of the guests. It's an excellent community, very supportive, and the conferences have been an important part of my journey as a documentarian and tech writer. A little background there, I attended my first conference in person in 2019, and it was the first time I realized that there were a lot of people who did work that I do. Work that I hadn't always felt sure how to describe, let alone felt like I was a part of a community around it. And that sense of community was really important to me. I presented virtually at the Portland 2022 conference. I gave a talk called 'Beating the Virginia Blues: Thru-Hiking Strategies...
In this episode, I’m talking with Sue Brandt, a former Director of Documentation who’d hired around 60 people when we recorded the episode. We discuss practical strategies for technical writing job applications, what hiring managers are really looking for in resumes and interviews, and how to stand out in today’s competitive job market.
Sue and I discuss various aspects of the tech writing job application process, including resumes, cover letters, and interviews. Sue, who has hired around 60 people throughout her career, emphasizes that enthusiasm is often a key differentiator for candidates.
Throughout the episode, Sue shares practical tips based on her experience managing tech writing teams of up to 30 people, including ways to stand out as an applicant, how to handle situations where you may not have the exact technical skills in a job description but can demonstrate transferable skills and a willingness to learn, resume and portfolio best practices, how to honestly address gaps in employment, and more. The episode concludes with a discussion of career transitions and the importance of being open to learning new things.
About Sue Brandt
Sue was educated as a biologist, did postdoc research into marine microorganisms, and named 13 new species! She moved a little closer to the tech field when she worked with computer scientists on a bioinformatics project and found herself in the role of "translator" between computer scientists and biologists. Her tech writing career unofficially started when someone looked over her shoulder when she was job searching and said "You could do that.” Sue worked as a Technical Writer at a UK startup for 3 years, then moved to Denmark and worked at Microsoft for 13 years as a Programming Writer and then Developer Documentation Manager. She was always adamant that she didn't want to be a manager, but she was persuaded to try it and found out she loved it! She became Director of Documentation at Sitecore and managed 30 writers, editors, and developers working on 10 different products in 6 countries.
—
Contact The Not-Boring Tech Writer team:
We love hearing your ideas for episode topics, guests, or general feedback:
Join the discussion by replying on Bluesky
Contact Kate Mueller:
Contact Sue Brandt:
Contact KnowledgeOwl:
—
Transcript
Kate Mueller: [00:00:03] 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.
Kate Mueller: [00:00:18] Hello my lovely fellow not-boring tech writers. I'm Kate Mueller and today's guest, I have to say, also has a storied past. I love interviewing people who got into tech writing by accident after they did something else. And today's guest definitely qualifies as that. She was educated as a biologist and did post-doc research, and then slowly moved into bioinformatics before ending up in tech writing, and then also ended up being a people manager at some point in there. Lots of unexpected twists and turns, and you know how much I love a good, not boring, 'twisty and turny' story. I'm very excited to welcome to the pod today, Sue Brandt. Sue, welcome!
Sue Brandt: [00:01:00] Hi! Thanks very much, it's great to be here. I'm looking forward to the talk.
Kate Mueller: [00:01:04] So excited to have you. For our listeners, I just spoiled a little of it I think, but can you give us your tech writer villain origin story? How did you get into tech writing in the beginning?
Sue Brandt: [00:01:16] I'm wondering, is there anyone who actually planned to be in tech writing from early on? It seems like everyone just falls into it by strange and wonderful means. I've heard all sorts of stories. My story is that I was looking for a new role. I was doing post-doc research and I enjoyed it, but it was really stressful to have to keep applying for new grants and not knowing if you still had a job in a few months. I had no idea what I wanted to do instead. I was looking at everything within about a 40 kilometer radius from my home. Someone was looking over my shoulder and pointed to something and said, you could do that.
Kate Mueller: [00:01:50] The infamous tech writer "oh, you could do that". Lo and behold, you could do that and you did.
Sue Brandt: [00:01:55] I was super lucky because the hiring manager was somebody who took a chance on me. I was writing about how you use software to program hardware, and I didn't know anything about software or hardware or tech writing, but somehow she twigged that I might be good at this and gave me a chance. So as I say, I was super lucky.
Kate Mueller: [00:02:18] This makes me really love that we're trying to talk about how you get hired today, because it's funny how those little moments of somebody maybe taking a chance on you ended up into something that worked as a career. I have a similar thing about getting into software in general. I was teaching college level writing for a while, I got burnt out on it, and I took this temp job at a call center. As a result of that, I ended up teaching myself database design and architecture, which led me more into the technical realm and ultimately led me into tech writing, among other things. But it was just a complete accident. It was just like, I don't know what to do right now so I'm going to take this totally random job that I'm not totally sure I'm good at, but I'm just going to do it for a while. Then it gradually built into something completely unexpected. Along the way, I've definitely had a couple managers who were like, you don't seem exactly qualified for this, but I believe you could do it. In your case, you're not currently working as a tech writer, so I'm going to tweak a couple of the questions that I normally ask folks. For everyone listening, you will recognize that these are slightly different from normal. One of the questions I do typically ask, is 'tech writer' the best role title to use for this? We've had some folks who prefer documentarians. We have some folks who align more with software or product documentation. I specifically wanted you on here because I was like, I need somebody who's actually managed other people, who has been through the hiring process, who can speak to some of this a bit. Does 'tech writer' play well on the resume front, on the highlighting skill front? Are there phrases or words people should be using that ar...
In this solo episode, Kate shares an update on her content update progress. She also reflects on Marcia Riefer Johnston’s interview (S3:E8) and on the idea of docs stewardship as opposed to docs ownership.
📣 Special announcement: The Not-Boring Tech Writer team (Kate and Chad) will be at Write the Docs Portland in May. Thanks to KnowledgeOwl's sponsorship, they’ll be wearing KnowledgeOwl and The Not-Boring Tech Writer t-shirts and giving out The Not-Boring Tech Writer stickers. If you're attending WTD Portland this year, please say hi to Kate and Chad, let them know what you think of the show, and swing by the conference swag table to grab some free stickers so you can flaunt your not-boring tech writer status with the world!
_____________________________________________
I’ve continued my work to update the KnowledgeOwl Support Knowledge Base to align with major navigation and UI changes that were rolled out in December. I updated an additional 91 articles since my last episode, taking my total to 457. 🎉 I also reorganized another three Features subcategories, taking me to the milestone of having updated half those categories using content type-inspired information architecture. I also relocated 12 mice from my basement.
Marcia’s episode prompted a lot of reflection for me. Her infectious, unbridled enthusiasm for this work—from learning new tools to new domains— reminded me of all the reasons I love the craft of technical writing, and how thankful I am that for the last year I’ve largely “only” been doing technical writing. I also appreciated Marcia’s exhortations to share what you know because you never know what great things will come from sharing your knowledge. Too often, we don’t share what we know because we don’t think we know “enough” (whatever that is). But sharing knowledge is a gift to others.
Thanks to a conversation with a friend, I’ve started to come around to the idea of docs stewardship rather than docs ownership. “Stewardship” comes from the Old English words for house and guard. Stewards originally managed estates for medieval lords. I extend this into the world of documentation (doesn’t “Guardian of the Docs” sound like an awesome way to describe what we do? Maybe a swag idea, too, non?). Most modern definitions of stewardship include the idea of “careful and responsible management of something entrusted to one’s care” (source), though they may also add sustainability, ethical use, or “a duty to protect and maintain assets which might be natural, financial, or informational” (source). Marcia’s observation that a lot of a tech writer’s job involves project and process management aligns with this approach, I believe. I explore some other ways I like this docs stewardship model and then draw a comparison between tech writers and gardeners.
Resources discussed in this episode:
—
Contact The Not-Boring Tech Writer team:
We love hearing your ideas for episode topics, guests, or general feedback:
Join the discussion by replying on Bluesky
Contact Kate Mueller:
Contact KnowledgeOwl:
—
Transcript
Kate Mueller: [00:00:05] 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.
Kate Mueller: [00:00:21] Hello, lovely not-boring tech writers. I'm Kate Mueller, and this is one of our solo episodes where I share things I'm thinking about or working on. I'm recording this episode at the beginning of April, right after Trump announced many new tariffs and before the NCAA March Madness championship. First, my progress update. Since my last episode, I've updated 91 more articles, taking my grand total to 457. I've also reorganized another three feature subcategories. This was a big milestone, since it means I've now reorganized half of the feature subcategories using these content type perspectives. I still have a long way to go on my article updates, but the content hierarchy changes feel like they're adding a lot of clarity. Although I kind of regret combining all of this into one project in terms of velocity, it's also meant that I'm updating the content itself and the way it's organized all at the same time, so each feature subcategory feels fairly done by the time I've made those changes. Well, as much as any documentation is ever done. Also, if you wanted a mouse infestation update, I relocated a total of 12 mice. 12 as in a whole dozen. I was astonished, maybe a little mortified. Since then, I've implemented my preventive measures. Knock on wood, I haven't heard any scratching in the walls since.
Kate Mueller: [00:01:55] I hope you enjoyed the episode with Marcia as much as I did. I've been reflecting on a lot of things since that interview. The first is that right now, for the first time in my career, I'm mostly only being a tech writer. I'm sure that sounds odd to some of you, but I entered the tech writing world sideways through support and product. Tech writing has been a part of my roles for a long time, but it's rarely been in my job title. I've usually done support or training or software testing or product management alongside writing documentation. Most often, tech writing wasn't something I could dedicate consistent hours to. I had to sneak...
📣 Special announcement: The Not-Boring Tech Writer team (Kate and Chad) will be at Write the Docs Portland in May. Thanks to KnowledgeOwl's sponsorship, they’ll be wearing KnowledgeOwl and The Not-Boring Tech Writer t-shirts and giving out The Not-Boring Tech Writer stickers. If you're attending WTD Portland this year, please say hi to Kate and Chad, let them know what you think of the show, and swing by the conference swag table to grab some free stickers so you can flaunt your not-boring tech writer status with the world!
_____________________________________________
Marcia and I discuss how tech writing has evolved in the last 40 years as the tooling and field have evolved—from literally cutting and taping printed instructions together to using sophisticated content management systems and modular content. She shares the user feedback from her first set of technical instructions for using a remote control set-top box at Magnavox, highlighting how important user feedback is to help determine what needs to be documented.
Throughout our conversation, we explore practical grammar techniques that have helped both Marcia and me strengthen our writing, such as restructuring sentences to center the reader rather than the tool. We also discuss how adding “by zombies” is a great way to suss out if you’re using passive voice (e.g. “This podcast is being listened to by zombies.”) and the strengths and weaknesses of the be verbs (am, is, are, was, were, be, being, etc.).
We also talk about the value of sharing what you know, and how putting that knowledge out into the world can reap unexpected benefits. And we talk about the fact that the division between “creative ”writing and “technical” writing feels like a false binary: all acts of language are creative, and technical writing shares a lot of overlap with forms like poetry.
We close by discussing how technical writers manage feedback from reviewers and explore how a significant percentage of technical writing involves project management skills such as managing conversations and helping everyone align on what the documentation should do.
For both of us, handling contradictory feedback from reviewers usually involves having a larger conversation about what the problems or issues were, rather than only focusing on solutions. We theorize that part of the value tech writers bring is our ability to identify less-than-desirable user experiences and to not just take suggested edits as gospel but to question and explore the need for those edits.
About Marcia Riefer Johnston
Marcia’s loved tech writing from the time she first heard the words technical and writer together. These days she brings technical and writer together as a consultant for Baxter International. In 2013, she fulfilled a dream by writing her book Word Up! How to Write Powerful Sentences and Paragraphs (And Everything You Build from Them). Two years later, her pocket-sized collection came out: You Can Say That Again: 750 Redundant Phrases to Think Twice About. Occasionally she posts on her own blog at Writing.Rocks. She lives in Portland, Oregon, where she makes things with scrumptious yarn, does New York Times crossword puzzles with her husband (especially the Thursday and Sunday puzzles), and lures in family and friends to play Wingspan and other games.
Resources discussed in this episode:
—
Contact The Not-Boring Tech Writer team:
We love hearing your ideas for episode topics, guests, or general feedback:
Join the discussion by replying on Bluesky
Contact Kate Mueller:
Contact Marcia Riefer Johnston:
Contact KnowledgeOwl:
—
Transcript
Kate Mueller: [00:00:05] 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 comm...
In this solo episode, Kate shares an update on her content update progress, muses about the similarities between mice infestations and docs projects, and reflects more on Kenzie Woodbridge’s interview (S3:E6) and how we choose what we work on.
Since Episode 5, I’ve continued my work to update the KnowledgeOwl Support Knowledge Base to align with major navigation and UI changes from December. I’ve now updated roughly 400 pages and reorganized a total of five Features subcategories (one more since Episode 5).
Most of note this month: I overhauled our Search documentation. This work was necessary due to new search settings and major changes to the search configuration pages. It was also the first feature documentation I wrote at KnowledgeOwl in 2018, and I’ve mostly tried to make minor tweaks to it instead of massively updating it. Thanks to some very positive feedback on the content type-inspired reorganization I’ve been doing elsewhere, I was able to make some much better content organization and substance changes.
I’m also battling a mouse infestation in my rented house, and I spent some time in this episode comparing that process to working on documentation projects.
This leads me into ruminating on the ways we can try to make the world a better, more inclusive place. I’ve been including a lot of Kenzie’s suggestions in my style guide content updates in this audit:
I like the idea that, as content creators, content accessibility is well within our area even if we don’t feel qualified as experts in it. These accessibility areas are also solid best practices for content, information scent, wayfinding, and search engine optimization. I encourage you to try these or other small, iterative improvements that will make your docs a better place to be in the next month.
Resources discussed in this episode:
—
Contact The Not-Boring Tech Writer team:
We love hearing your ideas for episode topics, guests, or general feedback:
Join the discussion by replying on Bluesky
Contact Kate Mueller:
Contact KnowledgeOwl:
—
Transcript
Kate Mueller: [00:00: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.
Kate Mueller: [00:00:24] Hello fellow not-boring tech writers! I'm Kate Mueller, and this is one of our solo episodes where I share things I'm thinking about or working on. I'm recording this episode at the beginning of March, eagerly awaiting the daylight savings time shift. I'm going to start this episode with a quick story. I promise it does relate to documentation eventually, but it begins like this: my house has mice. I've suspected this since last spring when I found an acorn stash and some plant pots I had in the basement. We rent our house and I have to go outside and around the house to get into the basement, so I don't go down there a lot. In the winter, I go about once a month to check our heating fuel levels, and I store the plant pots and patio chairs down there in the fall and bring them out in the spring. Otherwise, I don't really go down there for months at a time. After I found this acorn stash, I had some suspicions, but I didn't have a lot of evidence that these were mice. They could have been chipmunks, I don't know. Or that they were actually living in the house. I was living in this lovely state of blissful ignorance until about two weeks ago when I was taking a bath and I heard a mouse scratching around in the wall right behind my head.
Kate Mueller: [00:01:41] As a good tenant, I contacted my landlord who wanted to use glue traps to get rid of them. I have some major issues with glue traps, so for the last week or so I've been baiting live traps with really tasty things and then relocating the mice I trap to a local nature preserve. At the time of this recording, I have now relocated six mice. You might be asking yourself, Kate, why on earth are you bringing up mice on a podcast about tech writing? I do say that these solo episodes are about things I'm thinking about, and I'm definitely thinking a lot about the mice, but where is the relevance? I'm bringing it up because it's a lot like docs updates, kind of. The problem started out feeling somewhat small and not worth prioritizing, and then suddenly it wasn't small and needed to be prioritized immediately. Once I started working on it, I chose a solution that was a good solution, but ended up being way more work than I originally thought I'd signed up for. As I've gotten into it, the problem I thought I was solving is far more widespread than I initially thought it was. So not only am I doing more work because of the solution I picked, but I'm also doing more work because the problem turns out to be much bigger than I thought.
Kate Mueller: [00:03:02] The good news is, because I'm already kind of in the thick of it and working on it and in mousetrap mode, I don't feel as overwhelmed by the larger scope of it. I'm also paying attention to what seems to work better and iterating on that so my processes are becoming streamlined. If, wait let's be optimistic, when I get to a place where the scratching and the wall totally stops, I will then put in some preventive measures to try to avoid having this happen aga...
In this episode, I’m talking with Kenzie Woodbridge, a documentarian and self-taught accessibility advocate. We talk about how feeling “not expert enough” is no reason to skip content accessibility, four ways you can make your content more accessible right now, and ways you can serve as an accessibility advocate as you review content and work with contributors.
—
Kenzie and I discuss why content accessibility is something we all need to think about as we create content. You don’t have to be an expert to improve your content’s accessibility. We discuss four areas you can focus on right now:
We also discuss some dos and don’ts with alt text, providing feedback to content contributors who aren’t following accessibility guidelines, tools or processes to help identify accessibility bugaboos in your content, and so much more. Check out the resource list below to sponge a ton of useful resources from Kenzie, too.
About Kenzie Woodbridge
Kenzie works at the British Columbia Institute of Technology (BCIT) in British Columbia, Canada, as a Tech Writer, Trainer, and Knowledge Strategist, and is currently a co-chair of BCIT's Accessibility Committee. They have spoken about documentation and other topics at multiple technical conferences, including Write the Docs (their favourite). Kenzie is also a parent, a tuba player, chronically ill, a crafting dilettante, a gamer, and all around nerd who wrote their Master's thesis about prosocial community in multiplayer Minecraft.
Kenzie is awesome and you totally want to have them as your friend (offer of friendship void where local laws do not permit, not guaranteed in all circumstances, skill-testing questions required).
Resources discussed in this episode:
—
Contact The Not-Boring Tech Writer team:
We love hearing your ideas for episode topics, guests, or general feedback:
Join the discussion by replying on Bluesky
Contact Kate Mueller:
Contact Kenzie Woodbridge:
Contact KnowledgeOwl:
—
Transcript
Kate Mueller: [00:00:01] 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.
Kate Mueller: [00:00:18] Hi, I'm Kate Mueller and this week I'm so excited to welcome to the pod, Kenzie Woodbridge, whom I met, I want to say, back in 2018 at Write the Docs Portland, probably at the QWERTY event there. I was so excited to be able to get Kenzie on the show, because they are probably one of the best advocates, in my experience, in the Write the Docs community for accessibility. So Kenzie, welcome to the show!
Kenzie Woodbridge: [00:00:45] Thank you very much, that is incredibly flattering.
Kate Mueller: [00:00:49] Kenzie, to start off, for our listeners who don't know you, can you tell me a little bit about your, I call it, tech writer villain origin story? How did you ever connect with this community in the first place?
Kenzie Woodbridge: [00:01:02] I fell into tech writing sideways, which in my experience, in talking to lots of other folks, is very common. We're a person who is doing another job, but then it turns out we're also that one person in the office who has that natural push inside of you to write things down. Or people keep asking you questions. You're like, what if I wrote it down in a document and gave it to you? Then you could do it without asking me. It turns out that now you just asked me where the document is. It's a slight improvement in the process.
Kate Mueller: [00:01:39] It's a faster answer.
Kenzie Woodbridge: [00:01:40] It's a faster answer, exactly. When I was 6 or 7, what I said is I wanted to be a writer and a teacher. I was in my mid 30s when I suddenly realized I succeeded. I am a writer and a teacher. I work at the British Columbia Institute of Technology, which is a polytechnic institution...
In this solo episode, Kate shares an update on working with content types, muses about the idea of a Documentation Hierarchy of Needs, and reflects more on Janine Chan’s interview (S3:E4) and how we talk to ourselves about being tech writers.
—
I may have overcommitted myself in Episode 3. I have been incorporating content type work into my massive content audit, but after working on four of the nineteen Features subcategories, I realized it was taking too much time and I had to refocus on my main task of updating content to match our UI and navigation releases. However, I like the information architecture decisions this has helped me make and the clarity it’s bringing to the docs themselves and how I organize them, so it’s a project I intend to continue.
Making these kinds of priority decisions is something we all have to tackle all the time. But the content type work got me thinking: I’ve used an intuitive content type sense for a long time. I suspect I’m also using an intuitive decision-making framework for prioritizing my docs work. What would an explicit framework for that look like? In talking this over with a colleague, I realized I wanted a Documentation Hierarchy of Needs. I discovered that MongoDB created exactly this for their documentation overhaul once upon a time and wrote this blog post about it. I briefly run through their Hierarchy of Needs and how my decision to temporarily deprioritize content types might fit within it.
I also reflect more on Janine Chan’s episode (S3:E4) and her point about reframing the way we talk to ourselves from “I’m not technical enough” to “I don’t know how to do this… yet.” And I share my own suggestion for handling that narrative problem.
Resources discussed in this episode:
—
Contact The Not-Boring Tech Writer team:
We love hearing your ideas for episode topics, guests, or general feedback:
Join the discussion by replying on Bluesky
.
Contact Kate Mueller:
Contact KnowledgeOwl:
—
Transcript
Kate Mueller: [00:00:02] 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.
Kate Mueller: [00:00:18] Hello fellow not-boring tech writers! I'm Kate Mueller, and this is one of our solo episodes where I share things I'm thinking about or working on. I'm recording this episode at the very beginning of February, soon after the Society for Technical Communication's announcement of its bankruptcy and closure. While I was never involved with STC, I know many writers who were, and I suspect that loss will feel like a gaping hole in our community for some time. Let's all be a little bit kinder to each other, shall we? First up, what I'm working on. In my last solo episode, I talked about content types and how I was planning to use a massive content update for navigation and UI changes as a time to start more intentionally applying content type templates to my docs. I recorded that episode about six weeks ago, and I promised I'd give you updates along the way, so here's my update. I'm not going to sugarcoat it, while I've made a good amount of progress on my massive content update, I haven't focused on the content type work the way I thought I would. Of the 19 feature subcategories in the support knowledge base, I updated four of them using some of those principles.
Kate Mueller: [00:01:31] On the plus side, I like the updates to those four subcategories. A couple of them were much older features, and the docs had become a bit unruly, and thinking about content types and user purpose and experience helped me begin the process of finally getting them into shape. That focus on user purpose helped me with some information architecture decisions, and I'm creating a consistent but mildly variable format that, so far, feels like a definite improvement. I also realized that this is time consuming work. I was overly optimistic about how large my existing project was, and how much time the extra work would take. Let's be real, I was making an already large project even larger, and each minute that I spent working on that was a minute I didn't spend updating other docs to have accurate navigation steps or UI wording changes. I've basically hit pause on the content type project for now, but my big takeaways from it are that I do like it and I'd like to keep doing it, I just don't think now is the best time. I need to get through this big project first. As Janine and I talked about last episode, I'm basically setting aside my perfectionism and focusing on improving my docs right now in the ways that feel reasonable right now. Even though I know I want to do more, I'm choosing to focus on changes that are already a solid improvement for my readers. No big deal, just trying to practice the advice I dole out all the time.
Kate Mueller: [00:03:10] Reflecting on all of that has also prompted me to think more explicitly about how I prioritize work in my documentation. Since the support KB is largely product support documentation, I view these docs as an extension of our product, and I want the experience to feel as intuitive and helpful as our product does. Having a disconnect between what the product navigation and UI look like, and what the docs say, has caused me a fair amount of stress. I'm basically deprioritizing the content type work until I feel the docs align more closely with the product. I'll still make some changes along the way, but it won't be the dedicated project I'd envisioned. What it's made me realize is that I'd like to define what our priorities in the docs are, to help provide a decision-making framework for myself or others moving forward, when big projects like this hit. That feels like it would remove some ambient stress and provide some guidance without being too strict or pedantic. I want something that's fairly loose, but also clear. A general framework, if you will. When I was talking about this with Marybeth, I realized that what I want is our documentation's hierarchy of needs. Maslow's Hierarchy of Needs, written in 1943...
In this episode, I’m talking with Janine Chan, a technical writer and Write the Docs community moderator. We talk about how feeling “not technical enough” is as much about attitude and approach as it is about knowledge and ways you can bridge the gap to a more technical future.
Janine and I discuss the fact that there’s no defined/established set of skills or training to become a technical writer. This lovely flexibility can also lead to a lot of imposter syndrome or feeling like you’re “not technical enough.” But through continuous lifelong learning, changing your attitude or the story you tell yourself, asking for help, and letting go of perfectionism, you can transition to a more empowered, technical version of yourself.
Along the way we discuss the wonders of indoor plumbing, the fact that growing up to a be a tech writer isn’t typically on kids’ radar, our tendency to get curious when we’re frustrated about something, the importance of trying to answer a question before you seek help, how to be generous in requesting help, how generally awesome and generous with knowledge people are, how the experience of knowing little makes us more empathetic writers, and so so much more.
About Janine Chan
Janine is a technical writer based in Calgary, Canada. When she's not writing software documentation or shoehorning sociolinguistics into conversations, she's usually either outside, or hunkered down trying to make room in her lap for both a knitting project and her cat. (She recognizes that "not-boring" is a relative term.) You can find her on LinkedIn and the Write the Docs Slack, where her inboxes are always open for more tech writing chats! She promises she won't write in third person like she is now.
Resources discussed in this episode:
—
Contact The Not-Boring Tech Writer team:
We love hearing your ideas for episode topics, guests, or general feedback:
Contact Kate Mueller:
Contact Janine:
Contact KnowledgeOwl:
Join the discussion by replying on Bluesky
.
—
Transcript
Kate Mueller: [00:00:05] 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. Hi, I'm Kate Mueller. In today's episode, I talk with Janine Chan, a senior technical writer and a Write the Docs community moderator. We talk about that feeling of not being technical enough and ways to level up your technical skills so you can flip the narrative to, 'I'm a technical writer who just hasn't learned how to do this yet'. Hello my not-boring tech writers. I am so excited this week to be joined by a writer that I met kind of by happenstance. I gave a talk at one of the virtual Write the Docs Portlands a few years ago on Beating the Virginia Blues, and this woman happened to be my moderator for that session and ended up being amazing. She handled the other person who was doing Q and As audio networking with total aplomb. I can say she is both great under pressure and also not boring and a delightful human to boot. So I would like to welcome to the pod Janine Chan. Janine, welcome.
Janine Chan: [00:01:20] Hi, Kate. Thank you so much for such a kind intro. Oh man, all those AV issues. I guess I must have blocked them out.
Kate Mueller: [00:01:27] You've repressed them. It's fine.
Janine Chan: [00:01:29] Yeah, that's exactly what happens. And what a great talk it was. To be introduced to you by virtue of amazing athletic feats and also technical writing. Who could ask for more?
Kate Mueller: [00:01:42] There are two areas that have way more overlap than the average person probably thinks, because the number of people who messaged me after who were like, I've been a thru-hiker, or I'm thinking about being a thru-hiker, or I just really loved your talk. Apparently the Venn diagram of not-boring tech writers, and also people who enjoy doing outside things is pretty strong. There's a huge overlap there.
Janine Chan: [00:02:05] I love it. I love hiking, but I do love showering and getting in my own bed that night. So different sense of scale there.
Kate Mueller: [00:02:16] I will say, I never got used to not showering. Ever.
Janine Chan: [00:02:20] I always wonder, and it's a weird question, but I always wonder.
Kate Mueller: [00:02:24] Yeah, I never got used to that, ever. It is, for me, one of my favorite things about not thru-hiking is getting to shower on a daily basis if I want. However often I want, there's hot water there. It's great. I can be clean. It's awesome.
Janine Chan: [00:02:39] Indoor plumbing, what a gorgeous thing.
Kate Mueller: [00:02:41] One of the best things in modern civilization.
Janine Chan: [00:02:42] Welcome to the Indoor Plumbing Fan Podcast.
Kate Mueller: [00:02:45] Forget tech writing, we're just going to talk about the wonders of indoor plumbing for the day because it's pretty darn great.
Janine Chan: [00:02:51] It's pretty great.
Kate Mueller: [00:02:52] Janine, you are a moderator of the Write the Docs slack community among other things. So you are deeply involved in a portion of the tech writing community. Can you tell us a bit about, I call it, your tech writer villain origin story? How did you get into the field of tech writing in the first place?
Janine Chan: [00:03:12] I love it. It makes it sound so much more interesting than it could have otherwise. You know what? Tech writing is one of those careers that nobody knows about when they're young. I feel like nobody is really, oh, I wanted to be a tech writer ever since I was a kid. I would like to meet that kid. It would be fascinating to spend time with them. Everybody I know fell into it. For me, I was doing an English degree because that's what I enjoyed. I had no idea what I wanted to do with it. I had strangers telling me to marry rich.
Kate Mueller: [00:03:47] Did you get the 'marry rich or go into teaching'? I feel like those are the two paths people tell English majors to pick.
Janine Chan: [00:03:54] Yeah, or sometimes they'd be like, do you want to go into law? And I went, no thank you. No, I couldn't, I could never. I'd make a terrible lawyer. I was just doing it because I enjoyed it. Then one day I was at my boyfriend at the time's parents’ place, and I think his dad was trying to just make conversation over dinner. He said, what do you want to do? I said, I have no idea. He said, well I'm a technical writ...
My current in-flight projects include updating nearly all of our documentation to reflect major changes to our user interface, which includes changes to screenshots, navigation options, and section/subsection labels. I’m also working on my long slog to convert all our screenshots from .png to .webp format. As I make all of those updates, I’m bringing our content into line with our current style guide (the first time I’ve used an explicit style guide in the KnowledgeOwl Support Knowledge Base).
I recently finished teaching my first Knowledge Management Master Class with KnowledgeOwl. This was mostly a success, though it was a sharp learning curve for me and I’m already full of ideas on what to do differently next time. It also humbled me since it made me view my own docs through the lens of all the best practices I was suggesting people employ–and realizing how often my docs fell short.
For me, the most fascinating takeaway was really digging into the concept of concept types or information typing. I’ve never done this as an explicit, intentional exercise. After researching various approaches, I’m sold on the underlying concept. My plan is to create some templates for each major content type, using The Good Docs Project’s templates as a starting point). I’m then going to use those templates as I update content in our Features category to test and refine the templates before gradually applying them to the entire knowledge base. I’ll be using tags to track my progress and identify the content type for each page, too. In Episode 5, I’ll report back on how I’m doing in my endeavors!
Resources discussed in this episode:
—
Contact The Not-Boring Tech Writer team:
We love hearing your ideas for episode topics, guests, or general feedback:
Contact Kate Mueller:
Contact KnowledgeOwl:
—
Transcript
Kate Mueller: [00:00: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 fellow not-boring tech writers. I'm Kate Mueller, and this is one of our solo episodes where I share things I'm thinking about or working on, or both. I'm recording this episode in early December, right after Assad's ouster and the murder of the UnitedHealthCare CEO, just for some context. So first up, what am I working on? I'm in the midst of making a lot of updates to the KnowledgeOwl support knowledge base. KnowledgeOwl has released a lot of UI changes in the last couple of months, which of course I got behind on, so now I'm working to get our screenshots and text updated from those changes, while knowing that there are more changes coming in the next few months too. This has been a lot of changes. We changed our whole color palette, we changed a lot of the user interface key elements, we also just rolled out a totally different left hand navigation so I've got my work cut out for me. But it's a good exercise because it's prompted me to really evaluate how useful a lot of those screenshots are and whether we actually need them. In particular, there are a lot of older articles where I used screenshots of code as a final example for some of our step by step documentation, and I'm gradually replacing those screenshots with formatted code blocks just to reduce the screenshot maintenance burden.
Kate Mueller: [00:01:41] I've also been updating screenshots. We're moving away from PNG format and into WebP format, just to try to keep our file sizes a bit smaller and maybe give our SEO a tiny bit of boost. That change came out of me writing our 'image best practice guide' for customers and actually researching image best practices. So that's been a fun change. And last but not least, after years of having a fairly vague style guide, or no style guide, I've written a clear one. So as I make all of these updates, I'm bringing the text into alignment with the new style guide. All of that has already been in flight for a few months. I also recently finished leading a Knowledge Management masterclass with KnowledgeOwl. And as the old saying goes, the best way to learn something is to teach it to others. So I'm thinking a lot about things like content types, information architecture, information scent and findability and good metrics for success. Teaching the class was really humbling to say the least. It's kind of impossible for me to teach a class on this stuff without feeling mildly embarrassed at all the ways my own docs don't follow the best practices I'm talking about. And to be honest, this was the first time I've really had the time and space to sit down and critically view my documentation through some of these lenses, these big pictures.
Kate Mueller: [00:03:12] I'm usually so busy trying to keep things up to date that I don't really take that step back to look at the big picture. And now that I have, I'm overflowing with ideas on how to improve my docs. So many ideas, and I've had to really sit down and evaluate and try to pick just one to focus on. So top of mind for me today is one of those ideas, content types. The masterclass really made me research and discuss content types, and I find that I keep thinking about them and thinking about how I haven't been intentionally or consistently using them to structure our content. I mean, clearly our docs have survived this long without me doing that, but I've been thinking about ways to make it easier for more members of our team to contribute to the support KB. The style guide standardization has been a big piece of that, but I believe content types with templates are the next step. They would make it much easier to onboard another writer, or to ask other owls to update docs in my absence.
Kate Mueller: [00:04:15] For those of you familiar with content types, I'm thinking mostly about the common information types used in frameworks like Dita. The content, task and reference. Or the four types that Diataxis uses, explanation, how to guide, reference and tutorial. And for those of you who've never heard of content types, I'l...
