How to Create Great User Documentation with Nancy Hidebrandt

Intro: Hey everybody and welcome to another episode of How I Built It! Today I get to talk to Nancy Hildebrandt about building out a good support system. We talk about the importance of creating good documentation, listening to your customers, and so much more. We even have a bonus episode on Patreon all of that and more, after a word from our sponsors.

Sponsors: This season of How I Built It is brought to you by two fantastic sponsors. The first is Liquid Web. If you’re running a membership site, an eonline course, or even a real estate site on word press, you’ve likely already discovered many hosts that have optimized their platforms for a logged out experience, where they cash everything. Sites on their hardware are great for your sales and landing pages, but struggle when your users start logging in. At that point, your site is as slow as if you were on three dollar hosting. Liquid Web built their managed word press platform optimized for sites that want speed and performance, regardless of whether a customer is logged in or logged out. Trust me on this, I’ve tried it out and it’s fast, seriously fast. Now, with their single site plan, Liquid Web is a no-brainer for anyone whose site is actually part of their business, and not just a site promoting their business. Check out the rest of the features on their platform by visiting them at buildpodcast.net/liquid web. That’s buildpodcast.net/liquid web.

It’s also brought to you by Jilt. Jilt is the easiest way to recover abandoned shopping carts on woo commerce, easy digital downloads and Shopify. Your e-commerce clients could be leaving literally thousands of dollars on the table and here’s why. 70% of all shopping carts are abandoned prior to checkout. Yes, you heard that right, 70% of shoppers never make it to checkout. That’s why you need to introduce your clients to Jilt. Jilt uses proven recovery tactics to rescue that lost revenue. It’s an easy win that let’s you boost your clients revenue by as much as 15% and it only takes 15 minutes of your time to set up. Jilt fully integrates with woo commerce, EDD and Shopify. You can completely customize the recovery emails that Jilt sends, to match your clients branding using it’s powerful dragon drop editor. Or by digging into the HTML and CSS. Even better, Jilt’s fair pricing means your clients pay only for the customers they actually engage. You get to earn a cut of that through Jilt’s partner program. Whether you have clients that process one sale per month or 10,000 sales per month, be the hero and help them supercharge their revenue with Jilt. Check them out at builtpodcast.net/jilt. That’s builtpodcast.net/J-I-L-T.

And now…on with the show!

Joe: Hey everybody, welcome to another episode of How I Built It, the podcast that asks how did you build that? Today my guest is Nancy Hildebrandt. We got connected through the fellows at Beaver Builder, she’s doing some work for them. Nancy, how you are doing today?

Nancy: I’m doing great, thank you, Joe.

Joe: Awesome. Thanks so much for being on the show, I appreciate you coming on. We’re gonna be talking about something that is perhaps a thorn the side of many … Or, a thorn in the side of many developers, which is documentation. Before we get into that, why don’t you tell everybody a little bit about who you are and what you do?

Nancy: I come actually from a technical writing information architect background, and I retired from high tech. I used to work for the Java programming group at Oracle and I retired a couple years ago, and I started something I’d been doing as a hobby since about 1997, which is building websites for very small business people. In the course of doing this I discovered Beaver Builder and that’s the story I’m gonna tell today is how I came to write the knowledge base for Beaver Builder.

Joe: Awesome. You worked for Oracle back when like Java was first created essentially, right? In 1995?

Nancy: I was working for Sun, actually, and then Sun got acquired by Oracle and so, yeah, that’s how I came to work for Oracle.

Joe: Nice. Very nice. That’s pretty great. You have a pretty strong background in the … like a monolith in the tech field.

Nancy: Yeah. Information architecture is really about how … it’s like one step higher than technical writing, so it’s about the best way to structure documentation and then what tools are best for presenting your documentation.

Joe: Absolutely. Do you think that your perspective, working … First of all, in information architecture. Second of all, for a company like Sun has brought a very unique perspective to the WordPress space, which is mostly like open sourced, start up kind of, like a start up-y kind of feel, you know?

Nancy: Yeah, well Java’s actually open source, so and they operate under a GPL 2 license, so I was familiar with the license already, and so the WordPress model of open source is not new to me. Then, of course, with my tech writers bent, I do tend to evaluate products in terms of how much support I’m gonna get with their documentation.

Joe: Gotcha. Gotcha. My last question about your intro is, do you … I don’t want to lead you to the end that I expect you’re gonna give, but how do you feel the state of documentation is just like in the WordPress space, maybe in the freelance space and the small business space with the tools that you use?

Nancy: Yeah, well I think there are two sides to it. One is that most of the products in the WordPress space are done by fairly small companies who can’t really afford a big documentation effort so the developers tend to write it themselves. Some are more interested in it, some are less interested in it. Some know more about it, some know less. On the other side of the coin, if you know the famous acronym RTFM, Read The Effing Manual.

Nancy: I mean, documentation should be a last resort. If your product were perfectly designed from usability standpoint, you wouldn’t need any documentation. It would just be apparent how to use it. But that’s never the case, so documentation fills in the gaps. And so, when I write documentation, I expect that users will exploit just about every other resource before they’ll finally resort to going and looking for some written help. I would like to talk about the difference between video help and written help. I can do that later in the tips if you like.

Joe: Yeah, that would be great when we talk about building documentation, ’cause I know I do a lot of video work and written work, so I’d love to just talk a little bit about that. But I love what you said there, documentation should be a last resort, right? When you buy a car, it’s not like you read the manual before you drive it off the lot, right? You intuitively know how to drive the car.

Nancy: Exactly. But if it comes time to change that flat tire, you’d better have that manual in your glove box.

Joe: Yup. Absolutely. Very cool. I love that. We’re going to be talking about specifically building the knowledge base for Beaver Builder. You mentioned that you used it for some of your web design projects, but when you actually set out to build the knowledge base, what kind of research did you do as far as what you’re gonna cover? Are you gonna start from the very beginning, or figuring out what are the ping points for users?

Nancy: Right. Beaver Builder already had a knowledge base when I started using Beaver Builder myself as a tool. It was a rather typical knowledge base. Well, it was probably better than most. They probably had about 50 articles. They were written in a WordPress format on their site, probably as custom post type. They were okay, but they were sort of a typical developers eye view of how to write a helpful document. My best analogy to that is I used to have a friend who was a 747 pilot, and he said, “As a pilot, we need to know how to balance the fuel load, because it’s different when we’re taking off, and when we’re cruising, and when we’re landing.” He said, “You go to the Boeing manual and it’s got a chapter on the primary fuel tank, and the secondary fuel tank.” You’re getting all this conceptual knowledge that you really don’t need. All you need to know is what you’re doing at each stage of the flight. It’s similar to that.

Documentation should be task based, so you need to do the most important thing to do is the task analysis. What are your users trying to accomplish with your product? Then what you do is you just write a set of titles for articles that address each task, and there you’ve got your knowledge base. For anything that users would need to know conceptually that they don’t have from that, then you write a few conceptual articles. For example, we have an article on you can’t use Page Builder in Beaver Builder to build archive documents, archive webpages. A lot of our users don’t know what an archive means, and how that’s different in WordPress. They don’t have that much knowledge of WordPress. Then, you need a conceptual article about, okay, what’s an archive, why’s it different in WordPress, that sort of thing.

Joe: Gotcha.

Nancy: But the main focus is on task based documentation, so once you figure out what your users want to do, it becomes very easy to write the articles that they need. If you’re not sure, you can just talk to your support team, or if you’re the support team, you know what kinds of questions your users are asking. How do I do such and such? How do I do such and such? You just address those questions that users have.

Joe: Man, that’s fantastic. I’m gonna reiterate what you just said again, which is documentation should be task based.

Joe: I use the same exact wording in my online courses, right, I say, task based courses. Because like you said, if you have a conceptual course, people aren’t going to necessarily know exactly how to apply that knowledge. They want to know, I need to do X, how do I do X?

Joe: I’m guessing, I don’t have any data to back this up, but I’m guessing that the sort of conceptual learning is a function of how we’ve been taught for years, right, in the classroom.

Joe: The flipped classroom is a thing now, but even when I was going through school in the ’90’s, it was here is a concept. Here’s how it works, now here’s homework on that concept.

Nancy: Yes, exactly. Yes, the manual is dead. There are no more manuals and users want to get in and get out, so even within a task based topic, they need to be able to scan that topic and get just the information they need.

Joe: Right. Absolutely. Which is probably why YouTube tutorials on how to do home improvement is so popular, right?

Nancy: Yes. Yes.

Joe: Yeah. Man. That’s fantastic. It’s so cool to hear you say that, too, because it’s … as an educator, I found that to be really important and I’m glad that it’s starting to be integrated to formal documentation, right? Like real documentation.

Nancy: Yes. By the way, documentation has a bad name from a long history of bad documentation. And so, the documentation people, the tech writers have been looking for other words for documentation for a long time. Online help also has a bad name, ’cause online help has been very poor in the past, so they’ve tried user assistance, and now Beaver Builder’s got a knowledge base. No matter what you call it, people will use it as a last resort. You can pick the term you want. I’ll be talking about documentation just to differentiate written help from video help, and other kinds of help. But it doesn’t imply a manual. It just implies something that’s written down.

Joe: Right. Right. Yeah. That makes sense. It’s so funny that you mentioned names. When I was in IT at the University of Scranton, I worked in an area that was like level three kind of support. I was a programmer, but our first line of support was the technology support center, which had just been rebranded from the help desk. They rebranded probably because help desk got a bad name, a bad rap. I remember I referred to the as the help desk one time, and one of the managers there got really mad at me. He’s like, “We’re not the help desk.” I’m like, “Oh, so you don’t help people?” It’s just funny that to hear that …

Nancy: Yes, yes.

Joe: Certain terms come with a little bit of baggage.

Nancy: You’re right.

Joe: The question I usually ask after this revolves around talking to other people, kind of like in a mastermind setting. In your case, you mentioned talking to support folks and customers, and things like that. But how helpful do you find those conversations with people when you’re building documentation?

Nancy: Extremely helpful. One of the wonderful things about documentation these days is we used to write documentation in a black hole. We’d imagine the customer, we might do a couple of user studies, but we’d imagine a customer and then we’d write for that imaginary customer. Then we’d never get any feedback about it. But now with social media, I mean, Beaver Builder’s Facebook page has over 10,000 members at the moment, so I get immediate feedback on what I write. I can say, “Hey, I put this new article out there. What do you think?” They tell me. Or they say, “I searched for this in the knowledge base, but I couldn’t find it.” I say, “Well, what did you search on?” Then I can add that search term and so on. That kind of immediate feedback where I can keep tweaking and fine tuning the documentation is invaluable.

Joe: Man, that’s … Again, that’s another great point. ‘Cause, I mean, people building software today probably don’t have a really good perspective on what it was like doing things like cut off from the actual user, right? The people that you were aiming to help.

Nancy: Yes.

Joe: But when I was in grad school, we talked about user stories and we would invent these users, but they were still just inventions, right? We never got to the point of talking to actual users.

Nancy: Exactly, because that’s time consuming and costly.

Joe: Yeah.

Nancy: Then, I also interact with the support team a lot at beaver builder. They’re great because they come, they’re very interactive, and they come to me and say, “Hey, I’m getting a lot of requests for this particular problem. How about if we write something about this and I can just point them to it in the knowledge base?” That’s when documentation really starts to make you money. When you start being able to reduce your support cost because people are saving time by pointing people to the appropriate article in the knowledge base, then you’re really saving something.

Joe: Yeah, that’s a fantastic point. You’re essentially support for support, right? When I talk to the guys that give WP, they talked about how important their support team was for getting insight in the customers, not just for the help aspect of it, but for the new features aspect of it. But what you said is, pardon the pun, right on the money. You’re creating a knowledge base so that support people don’t need to spend an hour researching a topic for somebody. Right? They can just say, “Oh, this article does that.”

Nancy: And they don’t have to keep writing the same answer over and over. The more you write it, the more you tend to abbreviate it, and then you’re leaving out steps that people might need to know. Then you’ve got the back and forth, well I didn’t understand what you said about this. This way, they just say, “Oh, okay. Here’s your problem, here’s the article on it. Go do it.” Done.

Joe: Man, that’s great. I wanna talk about that in just a minute ’cause the kind of psychology of support, I feel like it’s never come across my desk, or come across this podcast, but you’re right. If you do a task over, and over, and over again, you’re probably gonna take shortcuts here and there where you feel you can make them, but when it comes to support, it’s not just you doing it over and over again. It’s somebody that’s seeing that problem for the first time, so you shouldn’t take those shortcuts. I mean, going back to the classroom, that’s why your math teacher would teach you the long way and then the short way, right?

Nancy: Yes.

Joe: They wouldn’t just teach you the short way.

Nancy: Right. That’s the beauty of the task based articles that they’re short, they’re very specific, and hopefully support can use them and just as a pointer.

Joe: Yeah. And as you said, a good knowledge base, good documentation will end up saving you money. Especially if you have a support team where you need to … you wanna handle as many support requests as possible without cutting corners.

Nancy: Yes. No, I mean, I do have some tips later on if we have time when we get to it about if you’re very small and you can’t really afford documentation, what you can do.

Joe: Oh, man. I love that. Well, let’s move on to the title question then, and then we can get into the tips because that sounds amazing. And it sounds like it’ll be really great for this audience in particular.

Nancy: Sure.

Joe: But let’s talk about, how did you build the knowledge base at Beaver Builder? I think we hinted at this a little bit from a conceptual point of view, but the actually creating the documentation, what was that like?

Nancy: Right. The way we got into it is, I saw a message from the Beaver Builder team on Facebook saying that they were hoping to beef up their knowledge base. And so, I wrote them what’s called a pain letter, or I said okay, here’s what’s wrong with your knowledge base and here’s how I can make it better. Here are my credentials to prove that I know what I’m talking about. They went for that. I wrote them a detailed project proposal where I told them exactly how I was gonna make it better. Then, they liked that, so I wrote a project plan that was a phased project plan, so that, I think it was three phases. So that, knowing that companies, small companies don’t have a lot of money to invest in documentation, I wanted something that at the end of each phase, if they felt that was sufficient, they could stop and they would have something that was working.

At the end of phase one, I said, “Okay, here’s your initial, what we agreed on. Do you want to continue?” And they said yes, so we just … Now, we’re just continuing on, happy with each other at this point. But that was the way it was planned and how I got into it. And so, it just so happened that at that point, I mean, they were so ready to have a new knowledge base. And so, we talked about tools, and they had been trying to beef up the search on their current side, and they realized that they were just starting with this new tool for support called Help Scout. A lot of you are probably familiar with that. Help Scout has an integrated docs knowledge base where it makes it very easy for support to find the topics, and integrate the links into their support tickets.

It also gives you an infrastructure because it has the whole setup for writing individual articles and then categorizing those into categories and corrections, and then it has related articles area where you can put in related links to other topics. If you change the titles of the topics or whatever, all those links automatically adjust. That part, and it has killer search, so that part, that aspect of it was really nice.

Joe: Wow. That sounds like a fantastic tool. We’ll dig into that in a minute, but I love that you sent them a pain letter. Which basically, I mean, it tells them, right, I understand your problem and I also know how I can fix your problem, right?

Nancy: Exactly. This is a technique that I learned from job hunting, but it applies very well in other situations like freelancing.

Joe: Yeah, absolutely. Man, that’s fantastic. Then, Help Scout … The husband mentioned on the show quite a bit, I’ve never actually used it. I probably will start using it this year as I grow my student base, but the integrated docs, right? You mentioned earlier that Beaver Builder had a bunch of articles, essentially WordPress posts, right? Like blog posts …

Nancy: Correct.

Joe: … that served as the knowledge base.

Nancy: Yeah.

Joe: Then you just mentioned a whole bunch of incredible tools in Help Scout for integrated documentation. How helpful has that been to the support team?

Nancy: Well, you’d have to ask the support team, but it seems like it’s very helpful and I love … We all interact on Slack ’cause we’re all remote workers, and I love the interaction that I have with support where we talk a lot about problems they’re having. I monitor the support channel to see what problems they’re having, and can write topics based on some of the questions that they’re asking the developers and so on. That’s a huge help. It seems, I mean, given that support will actually approach me and say, “Could we have an article on such and such?”, makes me think that they are using these articles and do find it helpful.

Joe: Yeah. That’s fantastic. Then, the other thing that I have written in the notes here is you can also see the number of visits to each page.

Nancy: Yes. Yes.

Joe: What pages are the most popular.

Nancy: Yeah, so that’s another built in feature of the Help Scout knowledge base is they have metrics so you can see … I can tell you that when the first month we started, which I think was about a year and a half ago, with the new knowledge base, we had 400 visits that month. We’re now having around 59,000 visits per month. I can see there’s an average of two pages per visit, and I can see which pages are the most popular. I can see which search terms failed to help me beef up the search. I can add key words that will improve the search for those fail terms and so on. That aspect of it is also very helpful for tuning up the knowledge base.

Joe: Fantastic. You noticed that it’s about two pages per visit, or per visitor.

Nancy: Yes.

Joe: Do you find that a lot of people end up going to, let’s say, page A and then page B because they were looking for page B first, but ended up on page A somehow? Does that make sense?

Nancy: Yes. That information is actually not available to me, so I don’t know the reason why they looked at two pages, but I do know that the results lists is 91% browsing and only about 9% search, which is interesting because we do have this very good search, but as the knowledge base gets bigger and bigger, it does get harder to search. One thing that Help Scout, it would be really helpful if they had filters on the search where you could narrow it down to certain collections, or certain categories and so on. You can’t do that right now. It may be that search is just getting difficult and people are choosing to browse instead.

Joe: Yeah, yeah. Perhaps they’re just like, I kind of think I know what I’m looking for, so I’m gonna click around.

Nancy: Yeah. Yeah.

Joe: I mean, that’s my behavior, too. As much as I know how to manipulate searches from advanced operators and stuff like that, I still choose to do the old browse, like click and browse.

Nancy: Oh, interesting.

Joe: Yeah.

Nancy: I spent the first year trying to improve the search figure, and it just didn’t change, so now I’m trying to improve the browsing experience.

Joe: Nice. Nice. Well, we’ll look forward to that. We have about 10 minutes left, and so there’s two questions I usually ask, right? Has the product gone through transformations, what are your plans for the future? Perhaps we can combine that into a short answer and then get to the fun trade secrets question, ’cause you do have a lot here from our conversations.

Nancy: Yeah.

Joe: Sound good?

Nancy: Yeah, just to answer your question very quickly, I follow Beaver. Beaver Builder has a strong product plan now and in the future, and I just follow their releases, and as you can see, I follow the metrics for the knowledge base. I try to tune it up that way and follow support, and follow the Facebook crowd.

Joe: Nice. Very nice. Now, we will get to the … I should say, my favorite question, which is do you have any trade secrets for us? You have a lot.

Nancy: Okay. First of all, I know that a lot of people like video tutorials and a lot of people say … I’ve seen a lot of people say on Facebook, I don’t read written documentation, I want video. I will just say about that, that my own philosophy, we did a survey when I was in the Java programming group. We did a survey among the developer crowd, the Java developer crowd of do you prefer video tutorials to written tutorials? Or when do you prefer one over the other? The information that we got back, and it seems so right that this is how this came to be sort of my belief is that they like video tutorials for introductory stuff. How do I get started?

They really, it really helps you get started. But once they’re intermediate users, it’s kind of a waste of time for them to sit through a whole video because they’re locked into that timing in the video. What they really want is just get in and get out with the information that they need. What I like to try to do is to have video tutorials cover the basic topics as well as documentation, so whichever people prefer. Some people don’t like videos, some people will only watch videos. Have both for the most basic topics of getting started. Then keep the written docs for the more advanced topics.

Joe: Gotcha. That’s really interesting. Do you think at the intermediate level, shorter or indexed videos might be helpful? We’ll have an advanced video that we break down into timestamps or something like that, so that they can read and jump to that point.

Nancy: That’s possible, but one of the problems with video is that you … If your product changes, if your UI changes, you then have to redo a video and that’s costly. Videos are much more costly than written documentation. The other thing is, and I have this point later is, there’s an 80/20 rule in documentation where you focus more on early beginner users, beginner to intermediate. For more advanced users, they’re gonna find the answers that they need doing Google searches in forums, and also like for example, Beaver Builder has a very large and enthusiastic community of people who love to produce videos on various, specific topics. Whatever our knowledge base doesn’t cover, you can often find it elsewhere with a video search. But those people are not necessarily trained in doing very well thought out, well structured basic documentation. That’s really, I think, where our strengths should be.

Joe: Gotcha. To the same point, you can’t exactly skim three minutes of a video, right? If it’s three minutes, you have to …

Nancy: Exactly.

Joe: Right. On that same … you mentioned have the video, have the written documentation. I’ve seen this before. I’ve thought that I could do this before, but it ended up making more work for myself, have the video, get the transcript, and make the transcript the written documentation. I thought that that would totally work for me, but it didn’t work for me because my conversational cadence in a video is very different from something I would write out formally and instructions that I would want people to follow. Do you find that that’s the same, it’s the kind of the same?

Nancy: That’s very interesting. What you often see with untrained writers is they tell the … they might tell you how to do something, but they tell it like it’s a story rather than as like a numbered procedure. You tend to see a lot of phrases like, “Now you’re gonna wanna go ahead and do this.” Or, “Now you’re gonna want to do that. Oh, by the way, you should’ve set this up to be such and such before you started.” If you’re trying to scan quickly a procedure to figure out what you need to do, that’s not very helpful. If you have numbered procedures, first of all, it kind of forces you to put things in a time order. Any prerequisites … Know if you ever have to say, “Oh, by the way …”, it means you’ve got it ordered wrong. With numbered procedures, with people who are more advanced and they can skip a lot of steps, they just say, “I know how to do that, I know how to do that, I know how to do that.” And they can get to the meat of the, what they’re trying to do very quickly.

Joe: Nice. Nice. Very nice. That makes sense. I love that. Cool, so we’ve talked about videos and written documentations. What other kind of trade secrets do you have for us? What’s the next thing that you wanted to mention?

Nancy: I’d say, we touched on this a little but if you’re going to write the documentation yourself, then best thing you can do is to do that task analysis where you’re figuring out what your users want to do with your product. Then just take each of those questions that you figured out and write a title for that. There’s your knowledge base. Just write every title that you wrote for a question becomes a topic, and that topic is task based, and it should be either procedural steps or it should be a code sample if you’re writing for developers. One of the two. Don’t tell it like a story. Then, if there are any concepts that you, in the process of writing that, any concepts that you think need to be explained before your viewers can understand what you’re talking about, then you add a conceptual, either a short conceptual background at the beginning of the topic, or a longer conceptual topic.

That’s your basic doc set. If you’re going to hire someone to do this, first of all, it’s hard to hire a writer and just expect that they’re gonna take this information architecture overview of your documentation. I think the best question to ask them is if they didn’t come to you with a pain letter, ask them what’s wrong with the current documentation and what would you propose doing to fix it? How would you do that? If they can’t really come up with an answer, or you can’t really find a person like that, then I think the fall back would be you do the task analysis and come up with the questions and then you give them to the writer and say here are the topics you should write about. Then the writer can do a better job just filling in the content for each topic.

Joe: Gotcha. Yeah, that makes sense. You don’t expect somebody on day one of a job to be able to do that job perfectly either so you wanna make sure that they have the right domain knowledge, the right background knowledge to properly teach. ‘Cause that’s essentially what you’re doing in documentation, right, you’re teaching people how to use your product.

Nancy: Right. Since you have an education background, and a training background, do you have any tips for documentation? I mean, you’ve had a lot of experience with documentation too, I’m sure.

Joe: Yeah. Flipping the script. Yeah, so I think the thing that I say the most is it really comes down to empathy for the user, which is something I think a lot of developers have a hard time with, based on my personal experience. That empathy comes from the things that you talked about, right? Like talking to the users, talking to the support team. Doing a task analysis because all of those things will help you understand where the user’s head is at. Then if you do that, when you write your documentation, you write your tutorials or you do your videos, you’re not gonna … you’re going to use the right language, right?

I see a lot of people say, well, just click posts, add new. Using the word just, or obviously, or things like that kind of put down the user, right? They wouldn’t be watching your video or reading your documentation if it was easy to them. My tips are more from kind of a feeling standpoint, right? You wanna make sure that you’re making the user feel comfortable. But everything that you said is so important in getting to that point because I know a lot of people say, “Oh, it’s easy. Just do this.” If you’re explaining the task to somebody, then it wasn’t easy to them.

Nancy: Yeah, that’s a really good point. Yeah, I like that.

Joe: Aside from that, my process for writing documentation in videos is I will do something, and then I will write down exactly what I’m doing. Usually what I end up doing for my video tutorials is I’ll go through a task, I’ll write down the steps, and then I’ll undo it all so I can record the video tutorial.

Nancy: Oh, interesting.

Joe: Yeah.

Nancy: Yeah, that’s a good technique. Yeah, I like that.

Joe: It’s a lot of work, but like you said, making videos is pretty costly. Right? Like if I was doing written documentation I could take a screenshot before each step. With a video, it’s a little bit different ’cause you gotta do the task and then undo it.

Nancy: Yeah.

Joe: Cool.

Nancy: I guess my final thought is I’ve seen cases where documentation makes a difference between whether people buy a product or not. I don’t think that necessarily is … I mean, the deciding factor for the majority of people. But I do think it becomes very important in keeping your customers. If you have good support and good documentation, that’s what’s going to keep them loyal.

Joe: That is great. That is a good point to end on. I do have a few things left here though, so maybe we’ll do … I’ll end the episode here, and Nancy, if you have the time, I’d love to keep recording and we can release that as like a bonus part if that sounds good to you.

Nancy: Sure. Yeah, sure.

Joe: Cool. Well, Nancy, thank you so much for your time. I really appreciate it.

Nancy: It was totally my pleasure.

Outro: What a great conversation with Nancy. I strongly encourage everyone to think about documentation and support – we’ve mentioned this on other shows, but good support docs means a better time for your support team!

And Thanks again to our sponsors – make sure to check out Liquid Web for managed WordPress hosting. I use them on all of my important sites – they are that good! They are at buildpodcast.net/liquid. They’ll give you 50% off your first 2 months just for being a listener! If you want to save your clients (or yourself) money through recovering abandoned carts, check out jilt. They are over at buildpodcast.net/jilt.

For all of the show notes, head over to streamlined.fm/77/. If you like the show, head over to Apple Podcasts and leaving us a rating and review. It helps people discover us! Finally, last week I published my brand-new Patreon page. It offers a lot better rewards, and great goals, and I’m really doubling down on it. So if you like the show and what to support it directly, head over to patreon.com/howibuiltit/. You can support the show for as little as $1/month.

And until next week, get out there and build something.