Kate sounds off on docs hierarchy of needs and how we talk to ourselves

📣 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!_____________________________________________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:KnowledgeOwl Support KB, Features categoryMongoDB blog post: Applying Maslow’s Hierarchy of Needs to DocumentationTNBTW Episode 3 and Episode 4—Contact The Not-Boring Tech Writer team:We love hearing your ideas for episode topics, guests, or general feedback:Email: [email protected] the discussion by replying on Bluesky Contact Kate Mueller: LinkedInknowledgewithsass.comContact KnowledgeOwl:KnowledgeOwl.com—TranscriptKate 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...