295 – Website documentation and support

295 – Website documentation and support

‘WordPress Business Bootcamp’ with Nathan Wrigley and David Waumsley

These shows notes are best read in conjunction with the podcast audio.


GoDaddy Pro

Welcome to another in the Business Bootcamp series where we relearn everything we know about building WordPress sites, and running a web design business from start to finish.

We are on Season 4 which is a short season looking at training clients.

Today we are talking about website documentation and support.


We are taking contrasting approaches to getting our new businesses running and our first client’s site built. She is a new lawyer with no previous site.

Nathan:
Going Traditional with fixed pricing. He has presented a proposal and a contract. Set some expectation on the plan with has a deadline.


WP Builds Black Friday Deals Page

David:
Agile. MVP constant interactions based on user behaviour data.

Episode 2. Website documentation and support

Traditional vs Agile

Traditional has an end product. Many use the analogy of a car. Mostly to justify a care plan, but they are essentially handing over the keys to the owner.

Is it up to agencies to provide a manual?

To what extent is support offered. (For those not offering a care plan and those who don’t want one).

Is it like a car where the owner can take it to any mechanic or dealer?

Agile is an evolutionary approach. As long as tech and user behaviour continues to change, the project is ongoing. The 2nd value of agile is ‘working software over comprehensive documentation’.

So over to Nathan for the rest of this episode!

Document problems

There’s never a shortage of new tools for documentations.

We’ve discussed some related to contracts and onboarding and touched on client training.

We have not talked about:

  • Having a knowledge base (there’s software and WP themes and plugins for it).
  • The new stuff that allows us to create editable “how do” videos.
  • The brilliant https://tango.launchnotes.io/ chrome extension that allows you to build a “how to” document or post. You go through the process (like you might for video) and it puts in the click here stuff in screenshots this explains the steps.

Do clients expect docs? Is the need for them a sign of our failure with UI?

I have played with most things, but ultimately have started to focus on adapting to the uniqueness of each client.

I don’t have enough clients to justify updating a Knowledge Base. We have one that my wife still uses to remember how to do certain tasks like migrate a site for me.

It started very early on when books like “Built to sell” had an influence on me. But I soon realised I am not in it for the money. The business dies with me.

David

I really don’t think that they do. I set up a Knowledge Base and added some articles and noticed that there were zero hits on those pages. Sometimes we think clients care more than they really do.

Nathan

Support problems

This is probably about managing expectations. Individual clients and their jobs are different and so is how their businesses will change.

Over the years, I have read a few articles where the key issue clients have is with the aftercare. That is, not being around to fix or change stuff often years down the line.

Contracts can protect us from liability, but will not change this perspective.

Mostly it is on the client for not thinking about this, but as we know, they don’t. We probably should for them. Good aftercare sounds like a good opportunity us.

Have you groaned when a client comes back about changing a site you built, felt a sense of dread? They want to undo the good done or just long to do something new?

I think this feeling has been a large part of the desire to go agile for me.

David

What are we supporting?

Most clients get that design fashions change and know when they need to have different content and functionality, but what about other changes on the dynamic web?

  • Legislation (GDPR Accessibility).
  • Changes in tech (software company dieing or changing, improvement in code).
  • SEO (Google like to give us a new challenge regularly).
  • New research on usability (new, just in – folk hate auto-play video background – Apple nearly killed or scroll hacking or sliders etc.).

These seem the things clients do need support with, but don’t know they do.

of course, I think mostly the solution is to get projects agile and data driven to business aims. These topics are always on the table then. We are not waiting for them to get bored of their website look.

David

Please leave a comment...

Nathan Wrigley

Nathan Wrigley

Nathan writes posts and creates audio about WordPress on WP Builds. He can also be found in the WP Builds Facebook group.

The WP Builds podcast is brought to you this week by…

GoDaddy Pro

The home of Managed WordPress hosting that includes free domain, SSL, and 24/7 support. Bundle that with the Hub by GoDaddy Pro to unlock more free benefits to manage multiple sites in one place, invoice clients, and get 30% off new purchases! Find out more at go.me/wpbuilds.

AND

The WP Builds Deals Page

It’s like Black Friday, but every day of the year! Searchable, filterable list of WordPress products, with exclusive pricing for WP Builds listeners!

Check out the deals now…

We thanks them for their support of WP Builds.

Transcript (if available)

These transcripts are created using software, so apologies if there are errors in them.

Read Full Transcript

[00:00:00] Nathan Wrigley: Welcome to the WP Builds podcast, bringing you the latest news from the worth rest community. Now welcome your hosts, David Waumsley, and Nathan Wrigley.

Hello there, and welcome to the WP Builds podcast. You've reached episode number 295. Entitled website, documentation and support. It was published on Thursday, the 15th of September, 2020. My name's Nathan Wrigley. And just before I'm joined by my good friend, David Wamsley, a few bits of short housekeeping.

If you like WP Builds, we really would appreciate you sharing it, share it in whichever way you feel. Our Twitter handle is at WP Builds. It's also very nice. If we get people logging into their podcast player of choice and reviewing us over. Apple podcast seems to do the trick very nicely. Give us a review.

We'd really appreciate that. But also just head over to the website and find our subscribe page. WP Builds.com/subscribe over there. You'll be able to find all of the different ways, different channels that we've got for communicating. You'll be able to sign up to our email lists to be notified when we create new content.

We also have our fantastic deals. Page WP Builds.com/deals. I keep saying it's a bit like black Friday, but every single day of the week, 365 days of the year, there's tons of coupon codes for plugins, themes, blocks, all sorts of WordPress stuff. WP Builds.com/deals. Go there, search and filter to your heart's content.

And finally, we're trying out an experiment for those people who are a bit fed up with social media. You're a bit fed up with Twitter. You're a bit fed up with Facebook. We've installed a free open source piece of software called master on it, mimics Twitter broadly, and it's at WP Builds.social. Yes, that's a URL WP Builds.social head over there and join in the well, to be honest, very quiet, really quiet feed of information. Maybe that's just the kind of thing that you need. One more WP Builds.social.

The WP Builds podcast was brought to you today by GoDaddy Pro. GoDaddy Pro the home of managed WordPress hosting, that includes free domain SSL and 24 7 support. Bundle that with The Hub by GoDaddy Pro to unlock more free benefits to manage multiple sites in one place, invoice clients and get 30% off new purchases. You can find out more by visiting go.me/WPBuilds. I'll say that once more, go don't me forward slash WPBuilds. And we sincerely thank GoDaddy Pro for their ongoing support of the WP Builds podcast.

Okay on the podcast today, it's me and David Wamsley having a chat we're in episode number two, series four of our WordPress business boot camp series.

And in this scenario, we're imagining that we've built the site and we're now handing it over to the client. And we're asking ourselves the question, what amount of website, documentation, and or support do we need to provide? Now? You've probably got your own way of doing it. Maybe you provide care plans.

Maybe you provide paper based documentation. Or perhaps videos or perhaps you go into people's offices and do it that way. There's all sorts of different ways. And David and I discussed that at length today, I say at length, this is probably the shortest episode we've ever done. Enjoy.

[00:03:46] David Waumsley: Welcome to another in the business boot camp series, where we relearn everything we know about building WebPress sites and running a web design business from start to finish we're on season four, which is a short season looking at training clients.

And today we're talking about website documentation and support, which is we're really eeking this one out Aren. We Nathan.

[00:04:08] Nathan Wrigley: Yeah, I think this is gonna be probably one of the shortest episodes we've ever done. We normally aim there's this target of about 30 minutes or something, and I think this one's gonna be significantly shorter.

So there you go. You get some of your day back, David. Yeah.

[00:04:22] David Waumsley: Let's skip over the bit, cuz we'll start actually talking about this. Just contrasting our different approaches. I think when it comes to this. So we don't need to recap on what we're doing. We'll talk about agile and traditional and you are representing the traditional model and I'm representing agile.

This kind. Yeah. Approach to project management. There you go. Yeah. Yeah. So as I see it, correct me if I'm wrong, the traditional has an end product. So many are using the analogy of a car often to justify a care plan. But essentially we are handing over the keys to the owner. So the question for.

Traditional people is it up to you then to provide the manual that goes with this? Do you know what

[00:05:06] Nathan Wrigley: it's interesting because if the analogy of the car follows through then absolutely. Yes, because you have this expectation that a product comes with a manual. That's just the way it is.

You take anything out of a box. and it totally comes with a manual. However, I feel like the setup that I got was so much more cottage industry than that, that it really didn't come with a manual. I tried various different things, which felt like a manual. Manual's probably the wrong word.

We could maybe use terms like knowledge base and things like that. Yeah. But it really never got looked at which. Which is curious, but then I thought to myself, when was the last time I opened a box for a new product and it was quite recently. And then I thought did I look at the manual? And the answer in more or less every case that I can think of is no.

So I'm not convinced that we need to do this, whether or not you wish to do it is a different question, but yeah, I don't know if it's a requirement. What

[00:06:06] David Waumsley: made you set one up in the first place?

[00:06:09] Nathan Wrigley: Oh, honestly it was because of just the idea that I ought to set one up. Yeah. I thought to myself, it's a product I'm selling a product, there's an end date.

And I just, I dunno, probably on the grapevine somewhere heard that other people were doing it. So I began to create a knowledge base where I would demonstrate how the, the WordPress admin worked and typical things like. but then I was, it was very clear to me that nobody and I literally mean nobody was looking at it.

So just to be clear, I wasn't creating and printing off a paper bound version of a manual. This was a, it was a knowledge base online. I can't remember what software I used to be honest. Now it, it wasn't WordPress. I was using something else. And and I could see in the analytics that not a single person had opened it, which.

Tells us something, or at least tells us something about the clients that I was using yeah. That was

[00:07:04] David Waumsley: working with. Yeah. I've tried all sorts of forms of documentation and I don't think anybody's ever been interested, but I've shifted to this agile, an evolutionary approach where we're just saying the web is dynamic human behavior changes, SEO changes, everything, technology changes.

So what's the point in. Create an end product. We just keep constantly adapting to it. So we get something out as some minimal viable product and agile in its I mean it's has a manifesto that goes with it, some core values and the second value of agile is working software over comprehensive documentation and interest.

Yeah. And I think it's where to some degree, whether you decide that you want to manage your projects agile wise, I think you end up coming to the conclusion that is right, because obviously that came out of the developer side of things where a lot of the things that they were, making were custom and complex and they needed.

At documenting all of the time, but you know what? They realized that there was just too much time doing that. And it was just out of date so quickly that it was a pointless task. So the concentration then is to just keep focusing on the software itself. rather the documentation for

[00:08:26] Nathan Wrigley: it. This is a really interesting point, isn't it?

Because all of the stuff that I'm getting out of my boxes, where I'm saying I'm ignoring the manual, that object is not going to change. It's, let's say it's a TV or a microphone or a computer monitor or whatever it might be. That object is the same tomorrow as it was yesterday.

And so the manual kind of does serve a purpose, but also I don't really have any relationship with the company that makes it, perhaps I do, if I need to, explore the warranty, if something goes wrong. Yeah. But I don't really have any relationship, whereas building a website's totally different.

There's always going to have been some kind of relationship because you've, obviously, it doesn't matter whether you've done it with agile or you've done it with the waterfall, the traditional way. At some point, people have communicated and you've established that, okay, this is the person of the company.

I'm the web developer, and we're gonna work through this process. So it's not the same at all. And yeah. And the fact, as you said that things are constantly in flux honestly, think about just WordPress itself, that one year to the next broadly speaking it's similar, but it doesn't stand still.

The features and the functions and the way it works and the different assortment of plugins and the way they'll be updated. It really isn't the same. So I feel in a way the documentation process, the creation of it is gonna be a noose around your neck because. You're gonna have to keep amending that, or at least you are, if you want it to be up to date, you're gonna have to keep amending that as, and when things are changed, and if a client comes back to you and says, actually we want a, I dunno, a booking system to be embedded in there now.

And you find a plugin. Are you expected to make documentation about that now for that one client? How does it all fit together? Yeah, I'm not sure it's the best use of anybody's.

[00:10:16] David Waumsley: Yeah. And I think even WordPress describes its whole development as agile itself. I think it used that terminology.

I think if you want to go the traditional waterfall, what you are selling is the end product, which is the, mostly the, whether it's working at that time. But mostly the deliverable design that. Given, which is where we started off in the earlier way, but it just gets more complex when you move into content management systems, which are ever changing.

And. Just by nature, agile, we can't really document that we could only, and there's not much to document when it comes to our design. I guess we could do, we could say there's your brand colors. and there's your typography. Yeah.

[00:11:00] Nathan Wrigley: Yeah. What's interesting as well, is that, for the example of the TV, there's a real finite amount of options there, I can.

Obviously, it's gonna tell me how to plug it in and it's gonna tell me how to fire it up and how I can adjust the contrast and the brightness, but really there's a very small amount of things that can be done. Whereas you feel that in WordPress with a typical arrangement, let's say three or four plugins on top there's probably.

Literally hundreds of different things that could be done, fields that could be filled out settings that could be amended. And so the weight of things that you could get bogged down in, do I need to explain what every field does? Do I need to explain what every option is for?

And I think probably on balance, the answer is, like I said, that's just a bit too much of a waste of time. Have

[00:11:53] David Waumsley: you Played around with other things. Oh, you tried to do a knowledge base, but there's always tools. Aren't there out there all the time. And I know you've played with some of the same ones I have.

So you reminded me of the name of one of them that came out. It was an app Sumo deal flee. Was it called? Yeah.

[00:12:11] Nathan Wrigley: So this was a tool which purported to make videos. And the idea would be that as you progressed during the course of making the video, you could click and it would add little, numbers onto the video so that you could see exactly what the steps were.

I, I played with all these kind of things. And in the end, I just thought it wasn't really worth worthwhile. Just dropped that kind of thing fairly quickly, but then you introduced me to one just now, which you'll well, I dunno if you're happy with it. It's called tango. Is that. Yeah,

[00:12:46] David Waumsley: it's a Chrome extension and it's I actually, I've just sent you a link.

I dunno if you've seen it in your messenger which is an example of me using it, but it's a fabulous Chrome extension. It's a free service, although there's a premium add-on of course, but what it does is once you've installed that you can go through things as you might do on video, on your screen and go and click on certain buttons.

And it does all the work for you. So it zooms into where the button is and says, click here for you. And it's like instant documentation. You might have to fill in some extra details, but it is sensible to say, to put into words and zoom in, into the right place, what you are doing. And it stores it on their server, or you can download it, put it on your

[00:13:32] Nathan Wrigley: post.

I've just clicked on that link. And I see what the promise is now, cuz I wasn't. I got it. Yeah. But I think this is quite a nice implementation. Let's say for example, that we do decide that we want to make some documentation. This really does look like a pretty swift way of doing it because rather than having to screenshot things and then open up some kind of image editing software to add arrows and add.

Add things like boxes around the bit of the UI that you want to draw attention to. This just does all of that. So it's numbered things, so it's obvious you've got step 1, 2, 3, 4, right through to six in the case that you've shared with me, but then it's added little circles around the bit that you intended for people to look at.

Yeah. Okay. That's interest. I, yeah, it's probably still won't use it, but I do think this is the best implementation that I've seen of such a thing.

[00:14:27] David Waumsley: There's certainly an I, it's not documentation, really what we're talking about today, but it is useful. I think if you were building and you needed to explain, but if, even if they do we'll move on to that support.

If somebody comes to you, how do I do this? They want to write a blog post, which is what I'm showing in that example at gave you, it just tells 'em, go and log in here, click on this, go to this. Yeah save here and it's quite a nice, that is the best thing did we mention in the last chat we had video user manuals?

[00:14:59] Nathan Wrigley: No, I don't think we did. I think we skirted around that, but maybe we did. I can't remember, but video user manuals I don't even know if that still exists. Do you know ?

[00:15:09] David Waumsley: Yeah, it does actually. It's not own, it's not, it used to be a Troy Dean thing and I know it's. Sold since then. So it's still around. It's still updating and there is another, I think there's I forgot what it's called 1 0 1 based.

Oh yeah.

[00:15:22] Nathan Wrigley: WP 1 0 1. That's right. Yeah. Yeah. And so this is a pre-made suite of videos just to orientate somebody around WordPress. I think that's quite useful, but in your case and my case. It's not gonna cover all the bases, is it's just gonna cover the WordPress bases because I don't know. I could be really under promoting what both of those products actually have in their video range, but I'm guessing that they don't have all of the different scenarios, do they have the generate blocks options covered and are they updating it every, six weeks and so on?

Or do they cover Elementor or beaver builder or oxygen or whatever it is, and if not, and you are using those tools. In a sense you are providing a bunch of videos, which people can watch and setting that expectation, but maybe the tools that they actually need to interact with are not in that video suite.

Yeah, I don't know. Yeah. I think it really

[00:16:18] David Waumsley: shows you how WordPress has changed in that time. Because I, with video user manuals, they did. Beaver builder was very popular with the type of person who might have a client at that time. And they did a whole course with it and they updated it again later. It's been stuck now there for ages, but of course, since we've seen other page builders grow big, particularly Elementor, I.

Obviously they've worked out that this is unsustainable to have a whole course within what you're providing there for all these different page builders, which are constantly changing all the time. So yeah, I think they stuck with what they do, the core WordPress stuff. And I thought it was a really useful thing to be able to say, look, you've got this.

This is because we're sending you WordPress. Here you are. Here's a training course on WordPress. There's your sort of. But I must admit, I don't think there is a single client of mine. That's used it. Yeah.

[00:17:10] Nathan Wrigley: So here's another thing as well. Think about it this way. If you, if the intention of documentation is to not have the client beating on your door, asking for trivial things that really, they ought to be able to do themselves.

Okay. That's one thing and I can get that. And it, obviously, if you are being PED by clients who are asking you those trivial questions and you are. Finding yourself consumed by that and wasting tons of time. Yeah. Maybe there's some scope for that there. I never really found that with my clients.

They just didn't present me with that problem. I didn't feel I was being pestered. And generally speaking, when they got in touch with me because they couldn't do something, usually it was because they'd forgotten how to do something, actually, they'd misremembered how to log into the site or where the options were to, I don't know, amend a portion of a page or something like that.

I always saw that as a nice opportu. To be in touch with them. Yeah, because for me it, when we spoke last time, I like to create little short minute, one minute videos, really short to the point, answer the question, send it off in an email with a link. And you're done for me. That was a nice confirmation that I was still part of their setup.

If you know what I mean, it was nice to have that point of contact because it didn't take me long. Consign that task to the beginning of the morning or the end of the day or whatever, it might be just quickly get it fired off, give them the answer and you've become the, to go to person again. And so those little connections periodically, I think, are really valuable in keeping your position as the web guy for them.

[00:18:44] David Waumsley: Yeah, I think that's a real key point. I think probably what we've learned from maybe when we started to now is that the documentation is the nature of the web. Doesn't really mean that we can do that. And we're probably best then focusing on the ongoing relationship, which leads us to the other bit of this chat, which is the support side.

What do we offer let's shall we make an assumption here that this is somebody who's not on a care plan and. Didn't want one. Yeah. Okay. How far do we extend our support when it comes to the thing that we've sold them? Shall

[00:19:19] Nathan Wrigley: I just say what I did? Do and yeah, and then you could drop in and I don't, I have no idea if this is the best way, there's probably a more intelligent way of doing it, but essentially I would.

obviously with the waterfall, the traditional approach, I've got a moment in time when it really is finished and the bill has been paid. And at that point you are severing any future work. You've gotta you've got to justify yourself again after that and new proposals and so on, but I always offered a round of amendments.

Prior to saying it's finished. So there was that bit that, that offered a level of support. And I would typically say two rounds of amendments, but maybe sometimes three. And once those round of amendments had gone through and everybody was happy that would close that down and we'd say it was finished.

It's, the website is live and then I would usually give 30 or 60 days, something like that. Where they could basically come. And I would attempt to fix anything which went wrong because I recognized that it was entirely possible in those first 60 days that they would blunder and make errors.

And usually that never got made use of the client. Never used though that 60 day period, it wasn't like a cooling off period. It literally is. If we screw anything up, give it back to Nathan, Nathan will fix it and that's fine. But then once that 60, 30 days period was over, that really was. If you needed anything doing from that point, it was either a new contract, new proposal, or it was an hourly thing.

It, makes no sense for a one hour job to be, to have a proposal attached to it. So I'd just say, look, it'll be an hour. Here's my right. Shall I go for it? Okay. I'll put it in the roster. So that's what I did. Yeah. What about you?

[00:21:03] David Waumsley: No, it's pretty straightforward. And yeah, that was it really.

It would be charging 'em for ongoing jobs, cuz I had completed them before and in some ways not much has changed really because even with this kind of agile, they're just buying as you go. So they would it's we end up in the same position anyway after the, but I guess in my case in some ways I think it.

I've moved to the agile cause it's to help me deal with the other thing, cuz my big issue with support is there is the support that the client knows that they need and there's the support that they don't know they need. All the things that change on the web that will impact them as owners of a website, the legislation, GDPR accessibility changes in technology, how that's aging improvements on code SEO.

It's new changes from Google on performance and things like that. All of that stuff is stuff that they wouldn't possibly know about. That's. Yeah. and and I think this is why I've been a little keen to have this kind of agile philosophy going from the beginning is to get the idea from the off that we'll never finish you a product.

It'll always be an ongoing thing cuz the web is dynamic and that way it leaves it open for me to say, yeah.

[00:22:19] Nathan Wrigley: I've gotta say, I really do that aspect because when things like, so let's say for example, I'd built, I don't know, 50 sites or something like that. And they were all built in HTML and various CMSs and so on.

And then. You remember when responsiveness became a thing? Yeah. Yeah. I then had to essentially approach them through a CRM. Yeah. And say, did you know, this was happening? And it felt like I needed to reach out and say, look, you really do need to be mindful of this. And it almost felt like I'd gone to them a bit with a begging bowl, look can we have a.

Get a meeting in the book so that I can explain why this is important and so on and so forth. Whereas your approach would just mean that conversation was ongoing, cuz you're always in each other's messenger and in each other's email. And I didn't really convert too well on those things.

Most people just said, no, forget it. When we do the redesign in a few years time, then we'll take care of it. So that really never worked. I think, you

[00:23:19] David Waumsley: know, also I needed it for myself. Cuz have you experienced this where you've just when a client comes back to you cuz they think they want something doing on their site.

If you not I still do this sort of internal groaning because in my mind I feel like I've finished with that job. Yes. And it's done. Yes. And they've come back to me and for some reason I just don't feel, I want to get back into it. Yeah. And

[00:23:43] Nathan Wrigley: also the fact that you've forgotten how you did. Yeah.

You've no idea where that bit of CSS did up or something like that. And just thinking, yeah, I know this is a spaghetti. I'm gonna have to reintroduce myself. Yes. I feel that pain. I get that. Yeah. You just want to go for the new shiny jobs. Yeah, exactly.

[00:24:03] David Waumsley: That's the thing. And that's the problem as well.

I think, where I've realized it might be just better to keep this sort of small, ongoing relationship with the number of people that I can manage with the hope that's gonna keep running rather than, done, 200 sites or something. And then when. They all come back randomly as stuff I'm I don't feel disconnected because I think it's just in our nature.

Isn't it to say when you finish a job and you said it's done in your mind. Yeah. And it almost feels like going back on yourself yeah. In life.

[00:24:33] Nathan Wrigley: Yeah. Here's a bit of a moral dilemma then. So given everything that we've said do you mention. Supporting documentation or do you just not say anything and hope that they don't ask for it?

Because I'm guessing that if you said to any of your clients, this is especially true in my case where we're just doing the traditional approach. If you said to them, would you like a manual explaining how your website works? I think more or less, all of them are gonna. Yeah. Okay. I'll take that.

Whereas if you don't mention it, then I wonder how many of them would come and say, look, can we have some supporting documentation please? So you, I don't know. It's a bit of a quandary. That one. Yeah.

[00:25:19] David Waumsley: Definitely the latter. I just leave it entirely out. But I obviously, you just reminded me of something he's related.

That was what Charles. I think it was a video by the Norman Nielson group, the accessibility UX people. Yep. And they were just making this very point about when they're trying to find out about what users want. They did want the set of research where it's asking them what's important. And basically everything was asked was important to them.

Every, everything about a website was important. But when they did it a different way around you realize that, things like the visual design wasn't important to them actually in the case that they were dealing with, the security side was more important to them than the look of the site.

[00:26:02] Nathan Wrigley: Yeah. Maybe interesting. Maybe what we just need is a quick start guide. because that's if I buy a product and I've got the full blown manual and I've got the quick start guide I'm more likely to look at the quick 10 minute, quick start guide with some pictures. So maybe that's where we should go.

Just something really quick and generic. Here's how to log in. Here's how to update a post. There you go. Thank you. Bye. Think about the I dunno if you use Ikea products, but Ikea really have got the sort of quick start guide down to a T there's no words. It's just, here's some images.

There's four pages now your furniture's built and it's very quick. It's low key. You have to apply a bit of thought and yeah. Yeah. So there you go. I've opened up a new category. Do we need quick start guides? Prob probably not.

[00:26:54] David Waumsley: probably not. I, I. We're at the end. Aren't

[00:26:57] Nathan Wrigley: we really?

Yeah, it is like we said, it was gonna be a short one. So the takeaway from that is don't create documentation unless they ask for it. yeah, I think that's

[00:27:08] David Waumsley: it. We're done. Yeah. Next time we'll be talking about, this is a big thing for me, cuz I've encountered it a lot, which is dealing with the. If you have an long ongoing relationship dealing with changes in staff and new management.

[00:27:22] Nathan Wrigley: Yeah. Yeah. Okay. This has bit me quite a few times, so there'll be lots to say there. Yeah. All right. We'll see you in a couple of weeks. Okay,

[00:27:28] David Waumsley: though. Cheers. Bye.

[00:27:29] Nathan Wrigley: I hope that you enjoyed that. Always a pleasure chatting to my good friend, David Wamsley. And it may be that you do things entirely differently.

Perhaps you are outraged by what we talked about. Perhaps you are in agreement with us either way. If you've got any website support or documentation, thoughts, please head over to WP Builds.com and search for episode number 295. Leave us a comment. There we'd be most appreciative.

The WP Builds podcast is brought to you today by GoDaddy Pro. GoDaddy Pro the home of managed WordPress hosting, that includes free domain, SSL and 24 7 support. Bundle that with The Hub by GoDaddy Pro to unlock more free benefits to manage multiple sites in one place, invoice clients and get 30% off new purchases. Find out more by going to go dot forward slash WPBuilds and we thank GoDaddy Pro for their support of the WP Builds podcast.

Okay. We should be back to a full schedule of podcasty things over at WP Builds. Hopefully my holidays are now out of the way and we can resume our schedule of Monday every Monday, 2:00 PM. UK time. WP Builds.com/live. We've got our, this in WordPress show. Usually I'm joined on the screen by three. Word Pressy guests, and you can give us some commentary and chat to us.

And it's quite a lot of fun. I repurpose that and put that out as a podcast episode on Tuesday, but also we'll be having our regular Thursday podcast updates. That's what you're listening to now. So hopefully we're all back on track. I appreciate you listening. Thank you so much. Stay safe. Have a good week byebye for now.

RECOMMENDED STUFF

These are affiliate links and the small amount of income we derive from affiliate income allows us to pay the bills and keep the lights on