Our Process

Hello and welcome to Inspect, a show about web design and development. In today's episode, we're going to be talking about process, like the design and development process, so going from wireframes to designs and then into development and then find the introduction. And basically how that differs between working for a large company or an agency and also doing that freelance where you can re-handle a lot of that process on your own. How do you want to keep this off?

I think it will be interesting to find out for yourself how your process works. This is going to be that because you're working for an agency and I think the process there differs quite a bit from everyone else's process, especially if you're freelancing when you're running your own business. I think it would be a few steps, something, additional steps to the agency model. So let's go through what you do with your processes and then...

Yes, I'll let you know, like I said, I'm part of an agency. So I'm from an end developer in the agency. I'm quite an official designer as well. I get called upon to do design work every now and then just because of my sort of past experience.

But visually, I'm not part of the design team. So we tend to have, I guess, a three-step process where you have the design team work on the visuals and then it gets handed over to the front end team to... Well, hand it over to the development team and we tend to work sort of concurrently in front end and back end guys building up with templates and then doing the wiring up in the background. And then obviously, I'll go on to QA and eventually get released.

The issue, why not the issue? But the difference with where I'm working at the moment is that our team is all distributed. So obviously I'm in the UK office, but then we've got offices in Germany and Croatia in Austria and a few other places around Europe. So the teams are very spread out.

So we have to communicate, we do all of our communication online really. So that can sometimes be a challenge. So we've got to make sure that we're using the right tools to sort of get designs started and get handed off to the right people. So I think most of our designers are using Sketch to do their design work these days.

Yeah, it's enormous in everyone's going to use that now. Yeah, and even when I do do design work for the company as well, I'm mainly using Sketch wherever I can. Just to sort of be on the same tool set as the actual design team. Okay.

And the design team will then work closely with the production managers and the product owners and the client themselves as well to sort of do some requirements gathering at the beginning, work through wireframes and do all that iterative process towards the beginning. And sometimes the developers are involved in those early conversations. Not always. I guess it depends on who's on the team and where their location is.

Most of the projects I've been working on have been clients within the UK. So I've been involved in those conversations from the beginning as well. And that's always helpful because then you can, as a developer, you can sort of help the designers and the design team, but stay at them in the right direction of what's possible or what's not and what your plan is and when it comes to developing product as well. So it always helps us to win all the team in the same location, but that's one of the challenges that we tend to face.

So you've got your distribution teams all over the world. I'm guessing you guys are collaboration for, right, where you can converse and talk about some aspects of this as a wireframe. Yeah, I mean, we use Slack for most of our projects. There's a couple of projects where the client has their own requirements.

So, you know, we may use their own communication tool. So for one of them, we're using Microsoft Teams, which is obviously the same sort of thing in Slack, really. The client is bound to use Microsoft licensing. But, you know, totally, we're fairly flexible.

We're internally within our company, we use Slack. And then for things like design handoff and sharing prototypes and things like that, we use mainly Envision, but we're slowly making a bit of a transition towards Zeppelin now. Some projects which are still on Envision and then anything that's new is kind of going on to Zeppelin as a tool. So that's pretty good because then everyone's always got visibility of everything.

You know, conversations happen in Slack, they happen in threads. So everyone's part of the same channel and there's a history there. And then everyone's got access to the design projects as well. So they can see what the mockups look like and they can extract assets from there from Zeppelin and the developers can get their colors and fonts and spacing and all that sort of stuff.

And they need to that works out pretty well. I think it's important to have the right tools as well. Just to screen a team. Yeah.

Especially with big teams, a lot of teams, you know, it's essential. Yeah. Yeah. And depending on the size of the project, sometimes if teams are spread out, you know, across different countries, there may be like an initial session where everyone does gather in one place in one location and maybe have like a couple of days where we're trying to time and just sort of flesh out the beginning part of the project and then everyone will go go back to their own desks wherever they're located and then, you know, we're remotely after that.

Cool. So, how about how to work for you? I mean, freelance with a couple of contractor team members. How did the process work for you?

So for me, when I was freelancing, it was kind of it's the same now. I think there's a big distinction between freelancing and being a solo printer or running a small agency or a small business. And I think the processes are very similar. So the way the way I'm working and the way things are handled with me is usually there'll be a meeting the client to determine what their requirements are.

And this is usually for a website or any kind of web project. So we'll find out what they need, what's required, how the website's going to function, what are the main features of the website, what's that in goal of the website. So for example, the website's going to take inquiries for an inquiry form. You know, we need to know about that the very first step.

So, you know, we know about all the moving parts and anything that may cause issues during the development process. So that's usually done through like a, in any sort of conversation. And then once that conversation is done, we'll send over like a proposal for the client which has everything mentioned in black and white. And then they'll, you know, basically go through that and agree on everything that we discussed.

And once that's done, then we'll send an invitation into our project management tool. Usually we use Trello for any kind of project management work. Okay, so I've like a external Trello board for myself and the client. And just an iron on myself and the client can see everything that's going on.

And then we'll do like an internal one where I'll be using Trello board with anyone else that's going to be on that project. So that could be anyone from like a brand designer to someone who's going to be doing development work. Or anyone else who is going to be involved in the project on my side. So, yeah, that's a set formula of how you set up your Trello board as well.

Like internally and externally. Yeah, so the external Trello board, the client is usually, you know, there's usually like three or four columns that we set up and have like a backlog column and then things that we progress. And then we'll have another column for completed. And then what we'll do is basically we'll just set up all the tasks individually on individual cards in the backlog column and assign members onto each card.

So the client will be added to anything where they required to provide any kind of content or feedback. And then once they've provided their actions or carried out what's required of them, then we'll basically take off the card and move it across into a completed column. Just so they know that what's going to be, what's going to be, what's going to be. But they've got full access to it so they can actually move stuff back and we get that quite a lot of the client will move tasks back into backlog or importance.

They'll create additional columns. They kind of get the hang of it pretty fast. Okay. And the flow works pretty well.

Internally, it's very similar. We might have additional columns to it. We might have notes and other important information where we discuss various things between ourselves rather than emailing back and forth, you know, conversations will be kept within like a combo or column or card with Intrilo. So that's purely for websites.

But we do have, you know, digital marketing projects where it works slightly differently. So we'll have columns with Intrilo, which will just mark out the beginning of the week. And so we'll have, you know, we commencing saying, you know, first of June and then the seventh of June and the seventh and so forth. So then we kind of set up cards, which we know are going to be carried out throughout that week.

And, you know, we can set up labels for those cards. So we know if anything's green, it's been done, anything red is important, orange is being carried out. And if it's not completed during that week, then that card is carried over to the following week. And, you know, we get a lot of that as well.

So a lot of cards are carried over from weeks. Yeah. And that's kind of, you know, longer scale we'll be doing. Maybe a three month Google ad campaign or six month SEO campaign for a friend.

Okay. Good. Yeah. So, you know, when you've got clients on the same motherboard and you, like you said, they've got access to move cards around.

Do you do you find that you have to be quite stripped with what gets added or do you do almost give them freedom to add whatever they want to the back? Because I can imagine you probably have a scope group like that. We don't use we don't use Trello really. I mean, some of the teams might use it internally, just to manage it, but with the clients we use Jira and the Jira boards, although clients do have access to tickets, they they're restricted into what in terms of what they can create and all requests have to come through the right channels throughout project managers and product owners and they act as a buffer for between the client and the design and development team.

So there's no unnecessary scope pre-bapping. Yeah. I mean, we Trello just recently I found one of the clients adding additional cards out of the blue and having full-blown conversations in the card and asking questions and, you know, dropping things like passwords and user names and things like that and copying, pasting content from somewhere and just going really ridiculous with it, you know, adding, you know, 50 megabits worth of photography into a Trello card. It blows everything up and it came back to our, but I think we don't have the conversation with the client beforehand and just say to them that this is purely for tasks that we say, setting up and be required feedback and a card will also be feedback.

Yeah. You also use Trello to then get feedback on designs, for example. I've been using various different types of tools for that. So, in vision, it's a really good one.

So once we've done the design work, we'll drop it into Envision and create a simple prototype where you'll be able to go from page to page or carry out user journey. So if you're adding a product to the basket and going to the checkout stage, we'll show that in vision and, you know, we can get feedback from there. But just recently, we've started using another tool, which is really good. But I think it's in this beta stage.

It's called DropLab. And I don't know if you've heard of it, but you can essentially upload all your design assets to that. So you can upload logo designs, upload your website page design frontends, anything you like, whether you want high res, and the client can then log in with their own user name and password and secure link. And then they can comment within there as well so they can provide you feedback.

So they can highlight a certain section of the page and then they can like type on there and give you feedback. Like Dropbox, very soon as I drop lots of it as well. Okay. You can have a semi-linkable, I'm having a quick search for it, but I think it's coming up with the right results.

Do you send me a link to that? I'll try it out. Yeah. Okay.

That's pretty good. That's an Envision network, really well. Yeah. Like I said earlier, we mainly use Envision and Zeppelin as well.

Zeppelin is good when you're handing off from designers to developers because you get all the measurements and you get all the assets laid out quite nicely and you get the stars eyed with all the colors and typography as well, especially if you're sinking with your sketch documents as well. It does a really good job with that. So quite like Zeppelin. I have looked into it and I did set up an account with Zeppelin and this is a lot there.

This is a hell of a lot there for some of myself in my situation where it's usually just me and I might be working with a couple of people here and there. But I think for you, it's really with the logic scenes. Yeah. So do you obviously using Trello, which is a canned ban style?

So most of your projects, do you approach them with this sort of agile methodology? Are you iterating often and doing little sprints or do you have traditional waterfall approach? I think everything that we're taking, all the projects are taking will be work in iterative format. Yeah.

And I think that's where the canned ban comes in and really suits the project work that I'm doing. And I think it works for everyone as well. The clients appreciate it as well. They think it's really professional.

But it's something like that out there and it really blows their mind and it makes their lives easier. So definitely I haven't come across any project where we think that it's not going to fit or it doesn't work. If you like. Yeah.

Yeah. I mean most of us are trying to do that as much as possible. But there's one big project I worked on recently where the client themselves insisted they wanted to work in more of a waterfall approach. They wanted to have a long period of requirements going right at the beginning and they wanted to really flesh out the whole project and try and basically think of everything before any design work even started.

So this was like, I mean, to name it was for a utilities company. So I guess it's a very traditional background. They've got a lot of processes in place, which they want to stick to. And they do so not necessarily the easiest client to to mold, I guess.

But yeah, it was it was tough because we spent we spent a couple of months, I think, just working on wireframes and just basically fleshing out what the project is going to be looking like and how it's going to work before any, you know, even lines were drawn in sketch. And then, you know, there was a long design process because it was basically a form we're building this multi step form, which had about 15 steps to it. So quite a lot of screens and a lot of logic as well that we designed. And it wasn't until the whole form had been designed and all thought that any of the actual development works side.

And then, you know, obviously, as most projects go, there's there's going to be changes. So came to the development process and then it was like, okay, that doesn't quite work when you do an update the designs again. And then this whole cycle just starts again. So should have been a four to six month project, probably, if it was if it was, I don't turn into almost a year and a half.

So, just really right now. I mean, we've got the end. But it just, you know, it just showed importance of working agile and, and, you know, having, having this sort of iterative process where you design a bit, build a bit, design a bit, build a bit. It was interesting.

And let's just say it was interesting. Yeah, it's happened to me. I'd say this line. No, you're fine.

All right. Okay. And when it comes to like, so when you've done with the project, let's say you're done with your design and then you've hand off to your development team and you know, it, how do you then hand off to your client then from that point? So I make sure that, you know, on the design side, it's all signed off of the line.

So every, you know, screen that they're going to see that the user is going to be signed off. And then that's passed on to development stage where, you know, myself and I probably have someone working alongside me, who will start coding and building the templates for WordPress for the actual website. Now we do this in the development environment. And so we will create a sub domain, which is hidden from public view.

And what we'll do, we won't release anything to the client until we've fleshed out all the visuals onto WordPress, you know, with actual templates. So what we don't want to do is start, you know, putting stuff together and then give them a link to it. And then they start looking at it. And the first thing I'll say is, why isn't this done?

Why is that, you know, like that? Why is that? Why is that broken? The fonts are wrong?

This is wrong. Yeah. And we always work in a mobile first approach as well. So the thing is what we find is clients always look at desktop first.

So that kind of like, you know, puts a span in the work. So we release, you know, early, then we get all kinds of issues in the time because they don't look at mobile first. They always look at desktop. Oh, they're generally happy to wait.

Yeah, they usually are. So what we'll do is, you know, first thing first, we'll get the first page ready. We'll get the home page. We'll get that all fleshed out, looking, you know, pixel perfect as it is in the design.

And once each one of those templates is, you know, ready to be viewed, we'll release them as a working site. In some cases, we'll do a prototype first. So, you know, we'll create a set up an envision where they can, you know, have a play around with it. And that usually keeps them happy.

So they know how it's going to look and how it's going to work and how we think it's going to flow. And while they're having a play with that envision, we can crack on the development work. And then what happens at that stage is they usually come back to us and say, Oh, we know it is something with, you know, the buttons weren't clear enough. The core directions weren't really that clear when viewing it as a prototype.

So while we're developing, we can actually, you know, implement those small fixes or small amendments as we go along. Yeah. That's how we work it. Yeah.

And you have a lot of input from your clients when it comes to the design process or do you tend to trust your judgment? Yeah. What happens? I used to get clients who would say to me, so the common board, you know, say, Oh, you know, have you ever built a website for a dental surgery before?

And I'm like, no, I haven't. But, you know, we've built plenty of websites in different sectors and industries. So the question should be asked is, can you build a website and not for a particular business or sector? And I'll be like, no, no, we haven't.

And then we're like, well, you know, we really want someone who's built a website for a dental surgery before. And then we'll say, some examples of websites that catch away and things that you like. And they'll send us links to websites that were built in the 90s and get really, really badly designed, unresponsive, you know, just terrible. And then we kind of get your lumbails running at that stage and it's kind of like, OK, that's cool.

You know, maybe refer to someone who can help you up and we'll just leave it there. So I've kind of managed to get rid of those kind of clients, but I do still get people on that kind of level where they want to have their input and they want to, you know, make suggestions. You know, and it's, you need to, you need to hear them out and listen to them. But at the end of the day, you know, you're the professional, that's the way I see it.

So, you know, I've trained and want to do a spent years at university studying human computer interaction and why certain colors are used over other colors and why text should be a certain size and, you know, why websites should be laid out the way they are. And you pass that information on to the client and they kind of respect you for that. But, you know, it doesn't matter what you say they always going to try and get something in there. You know, and it's sometimes you just have to, you know, go and go with it.

Yeah, no, true, true. I mean, I guess sometimes people don't know what they want until they see it as well. So, you know, someone says, OK, I want a website for my dentistry like you just mentioned. So, you know, just a competition out there is all of a certain caliber, but you can bring something new and fresh to the table, then, you know, providing links to competitors or to other sites that you like may not always be the best option.

Sometimes it's good to just start from a clean slate and just let someone approach it with their unique style. And, you know, there's obviously going to be some requirements that need to be met and some maybe some restrictions that will need to be considered, but you've got to let the design team and let the developers do what they know best. And what we only do as well is if we, you know, if we've agreed to take on a bespoke approach, the client tends to stick out of it and they'll stay clear of the design process completely bespoke. They'll either to us and I'm not OK.

Yeah, you want someone who's just, you know, being the voice of the design or, you know, spearheading the project. Otherwise you're just going to have this design by committee where you've got all everyone in the team, the client, the developers, the project managers, all sitting in on how things should look and feel, but you need to send a point to sort of take charge and, you know, listen to feedback, obviously, and incorporate what they can. But you definitely need a. Yeah, I think quite critically, the big thing that's been creeping up recently and I've been seeing it all over Twitter, actually, with friends of mine who are web developers and they want their own businesses is the influx of digital marketers who are now getting involved with, you know, web designers.

And so what happens is a scenario would be, I've built a website for a client, website is all signed off, great, you know, looks great, works great. And then all of a sudden the client decides to, you know, he's been pitched by a Facebook marketing guy or Google Agwards person. They, you know, ideas on how to improve the website and get leads and traffic, et cetera, et cetera. And so the client will go ahead with that.

And then what would happen is that for that digital marketing person will get hold of my details from the client and send me a list of things that they need to change on the website. They'll say, OK, so we need 10 new landing pages with optimised with these keywords. And we also need a form on each page and you know, four or five bits of course. Buttons everywhere.

Buttons everywhere, pop ups, you know, all of these crap nonsense. And it's like, are you for real? Like, you're completely just worried everything that you know, just worked on. And it's just crazy.

And it's like, you can't really, there's not much you can do in that scenario. And there is a place for that sort of stuff in certain industries and certain types of product, but it's not a blanket solution for everything. It's not. I mean, we think of all the solutions anyway.

We think of the scenarios and the call to actions are all there. You know, that's all taken care of anyway. But when you're talking about running a Google Agriets campaign where they might have five or six campaigns running, you know, multiple ad groups and then multiple ads. Then OK, they're going to need multiple landing pages, but it gets crazy with the marketeer.

You've probably using a tried and tested format. So, you know, from their point of view, they're right. And they just assume that they can send me a list of things that I'll be able to do without thinking about, OK, this is going to take time in effort and I'm going to have to quote the client on it. And it's going to cost the client X amount to make all these changes in the minutes.

So, you know, it's pretty crazy. And the funny thing is the I provide digital marketing services as well. So it's like, why have you gone off with someone who's just gotten in touch with you? It could be a case that might be a frame or, you know, it's what it will go to them at some point.

I get that. But, you know, it does for us. I know it works with these digital marketing people. It's crazy.

Yeah. I suppose we don't really get that issue as much an agency because it is all handled in house. So that would be one of the services sold to the client at the same time as well. You know, when the project is taken on.

So it doesn't happen as often. There's anything that you'd like to change about your process and how you go from idea to vision. It's not missing from your process at the moment. I think thorough good thorough testing is probably missing because one finding is at the moment, I'm getting quite a lot of work in and with two things actually, actually spending, you know, proper time on creating this work design.

I'm finding myself having to just roll out websites without spending, you know, a good amount of time on creating, you know, multiple versions of a design. So usually I'm kind of pitching to the client that it will be the spoke design. But what we'll do will be done in an iterative process. So we'll create, you know, a design for you, take some feedback from you and then we'll kind of make changes to that design until we're both happy with it.

Okay. No, it's going to work. But then, you know, it's all rolled out pretty quick. You know, we've got a framework in place in WordPress.

You know, we've got like a vanilla theme that we created and everything kind of just falls into place. So we have a list of all the essential plugins that we require. And it's all kind of, you know, it becomes mundane, obviously, you know, and if anything, I'd like to be able to spend more time, you know, with the client discussing the brand voice, you know, their identity and how that relates to what they do and they want to speak through design. There's not much time to get that done.

And then obviously that affects the quote, you know, on the project. So a lot of guys out there, a lot of clients that we speak to, they always mention the key words, you know, I need a basic website, I need a simple website. And the long goes over in straight ways that I don't really want to spend any time working any of that kind of stuff out. So, yeah, so putting some real real time into that would be great.

But the flow that I've got at the moment works really well. But, you know, as soon as I take on a designer or recruit someone, get involved, then we'll be able to do that step properly and actually spend time between ourselves and working like this stuff. Yeah. I mean, for us, in the agency, it's someone's opposite.

Because the size of the project is generally fairly large, and the budgets are fairly large as well. We tend to have a bit of luxury to spend a lot more time with clients early on and have lots of conversations. Sometimes there's too many conversations, you know, you should be quite gone with things, but you may end up just talking about things for the first couple of weeks without seemingly without any progress, but it's all progress really every conversation is helping, you know, having lots and lots of conversations up front will cut down the amount of rework later on. So, so it may seem a bit, not pointless, but a bit too much in the beginning, but it's all quite necessary.

But for me, I think, you know, one thing I'd like to change, especially in my particular setup, a process that is just because we are distributed to be nice if we could just have a bit more time where everyone sits together and works collaboratively for a short while on the project or a bit more long term as well. So that's probably the only thing I'd like to change. It's one of the things that it will, it happens, it comes and goes and it all depends on the client and their location and that has a big, big influence on the team that gets used for the project. So, as I said, we've got offices in the UK, Germany and Croatia and Austria.

So if there's a project for a client, which is a Germany, chances are majority of the German team is going to be used on that project. So, it's kind of driven by the client. You know, I've been, I've been only really working on UK projects for the past year. So, and every now and then someone from one of the European teams will come over and come visit with me, but most of the time it's just for the clients, you know, or people in the UK.

One question I've got for you. Once you, this is what you're working on a project, right, and it's all signed off and it's all ready to go. You've got like a testing sort of phase, right, for this project. Yeah, right.

How many, how has that done? How do you guys deal with testing? Like, I'm sure we've got like a massive department which carries that out or it's out to you. Yeah, I mean, it's not huge.

We've got a QA team. So we'll have, you know, all the developers will do an element of their own testing as they develop the end. Right. We kind of, we have some guidelines and we have some things like browser support defined and we'll have device support defined up.

So if we know that, you know, the site has to work in our 11 because that's what the client uses and the developers will make sure that it's tested in our 11 before it's even handed over to anyone. But then obviously we have QA as well. And the QA team will generally do a bit more in depth testing. They'll test that very specific scenarios.

They'll based on user stories. Right. And they'll do a lot more device testing as well as physical devices and then try and find anomalies and edge cases. And so there'll be a round of internal QA testing and then there'll be, we'll hand over like the first phase to the client and the client will then do their own testing in a staging environment or sort of environment.

And then that will come back to QA and then, you know, we'll go through a process of bug fixes and another release. And then it's until it's all the release passes those steps. So we'll go through development release and then a normal staging release, then an external staging release and then finally on to production. So it's mostly a four step process.

Right. So this is the thing with what I'm doing with websites I'm building. The testing that I'm doing is yeah, involves the client. So before we launch the client, we'll see a website in a staging environment where they can go through every sort of scenario.

They will click on every single link or click on every single page. If it's an e-commerce website, you know, we'll set up dummy products. We'll have like a dummy payment cards available so they can go through the whole procedure and then see invoices come through via email. And then we'll see how the logo is on there.

We think the brand is probably, if there's push notifications set up, they want to see that working. If there's SMS set up, they want to see notifications come through. So they will literally spend, you know, a good few days or a week on site. So that's the e-commerce site, especially.

And usually what we do is, you know, we'll go through it as well. And we might pick up on a few things that will be sell or things that aren't working. It could be like a plug-in. It's not working or something that we've put together from scratch is really working as it should be working.

We pick up on those kind of things. But we'll kind of do it in tandem with the client. Okay. So that's how we'll do it.

But for the smaller websites, you know, it's literally a case of just going through everything. We're only really testing in modern browsers to be honest. I don't do it in older browsers. And mobile first is key as well.

So we'll do all the standard kind of checks there and make sure all the enquiries are working as it should be. Maybe run the website through GT metrics or Google PageSpeed and just pick up on anything that might be bottlenecking anyway, like large images and things like that. Yeah. So up to CDN, if we have to, you know, if it's required.

So, you know, we'll find out about all of that kind of stuff during that sort of testing phase. It's not all the websites need to CDN. That's what I'm finding anyway. But anything, you know, image heavy with lots of content, you know, multiple style sheets in place, then, yeah, we find that CDN has got to be put in.

And we've got a test of that as well. Make sure that's all working properly before we move this all rolled out. Yeah. You mentioned that it's got dummy products and dummy content.

One thing that we try and do is the sort of stick around of staging, which we, you know, sometimes referred to as pre-production. We'll try and mirror that to the production site as closely as possible. So it won't have dummy content and they'll have actual content. And it will be set up in a way where you can put real orders through as well with real credit content.

Yeah. It's just basically a backup. That's where it essentially becomes. Because any of your production site, and then you've got this other one, this pre-production, which is almost an exact mirror.

Unless someone goes and makes a change directly on the production site, you know, content might not be exact, but functionality should be in the exact mirror. And that way then if the production site for any reason would ever go down, then you could quite quickly switch to the pre-production and make that the live site that will take a copy from there. And you shouldn't have to. You shouldn't lose too much content.

Yeah. So that's one of the big projects that I was telling you about the utilities company. That's kind of what we had. We had quite a few different environments.

So we had our local dev environment and then there was an internal local environment. So dev environment on individual machines and then dev environment internally on the single server and then there was a hosted internal server and then a hosted external server. It was about five steps. But, you know, it's a massive utility company and it couldn't really afford any downtime.

So it was important to get all those steps and thoroughly tested. Yeah. And, yeah, just that's going to grow with the site of a project. It's just going to grow.

I'd like to imagine how much testing is involved in releasing something on, let's say, Apple.com's website, you know, when they release a new iPhone and they have to update the product page for the iPhone as soon as it's released. Yeah. There must be so much going on in the background in terms of testing for that, just to make sure, you know, all the images are correct and, you know, the content is all going to be refreshed. You know, you don't want anything cached locally.

You've got to make sure that nothing is made visible to the public too soon. Yeah. It's happened. But, you know, just checking the checkout process and the configuration options.

It's going to be so much. But, yeah, it's just, I'm sure they've got a massive QA team. We've got generally on a project, we'll have a team of about three QA on most projects. Right.

Yeah. Between one and three, depending on the size. And that's normally enough to test out some browsers, test out all the browsers, test out all the devices. Right.

Get it done in a fairly reasonable amount of time as well. It's normally a good enough QA team. That's cool. Yeah.

Because I've been thinking about outsourcing testing to people that specialize in testing websites and making sure everything flows as it should do. All right. I haven't been thinking about just to alleviate stress on, you know, on myself and anyone else working on the project. So, I don't know what you're thinking about that.

But, you know, I've been looking for Google a few weeks. I think it's a pretty big topic in itself. It could probably do something on that. Like, Toronto Automate Testing and Unit Testing.

Automate Testing is something that I've been researching recently. I haven't got very far with it yet. But I know something like that, where they do do unit testing as well. And our dev team is encouraged to write tests where possible.

It's just one of those things. It's not always, you know, in priority number one. But, yeah, when it is, it does definitely cut down on QA time and it does speed up the process from development to release. Okay.

You know, when you mentioned setting up multiple environments for the websites. Say that, sorry. When you set up multiple environments for websites, so you've got like a test environment staging, people actually, and a production. I've, so I've only just recently following that sort of concept.

So before it would literally be a local version of the website where it's all built, everything's tested locally, and they'll be shared with the client. And I'm going to have you with it is push life. And then that's it. Then it does any live version of the site and then like a backups created or that automatically, you know, every day.

Which is all good. But then we started doing more complicated websites, which require constant changes, amendments, new features, new functionality. There's one particular website which you build is another play builder and allows people to go onto the site and create their own number plate. And this website is constantly requiring new plate sizes added to it.

You know, new character limits, being imposed on certain plates, new types of finishes for the plate. So, you know, there could be a sloped finish. There could be a 3D lettering. There could be 4D lettering and acrylic lettering.

It just is mind blowing. And so this is probably one of the first websites that I've actually put through like three or four different stages now. So we have like a local version of the website. We have a live dev version of the website and there's a staging version of the website and there's a live, actual live version of the website as well.

And you know, and we're running deep with that as well. So we've got version control on that as well. And that's the first time a project. And it really is.

It really does take out of you when you're working on something complicated. And so it's a case now for making a decision on is that the standard now for every single website that I take on. It might not necessarily need to be the standard for everything, but I mean, it's a good practice to have three at least three sets. You've got dev staging and production.

And it depends on how you're hosting as well. I know with host decides as your before. They're a pretty simple to create a staging environment. Obviously you've got extra you're paying for two servers essentially.

One if you use Netlify, have you ever used Netlify? No, I haven't. So Netlify makes it pretty simple as well. So it's good for all sorts of sites, but especially for small sites is good because it's free.

You can have your hosting from them. And it basically things up with your GitHub repository and you can have it to auto deploy your master branch to a URL, which is how I've got a few small sites up. But what you can do with Netlify is you can set it to build one of your branches as well. So suppose you're your master branch.

You can create another branch called called staging if you want. And you can have that as your intermediate branch. So you do all of your commits in whatever branches and then merge those in staging first staging, then gets deployed to a separate server, separate URL. And once you're happy with that, you then merge staging your staging branch into your master and then that gets deployed to your live URL.

That's one way you can set it up. Fairly simple. That's pretty cool. Yeah, Netlify is really good.

Check it out. They're not sponsored in the show, but maybe one day they will. I'm using deploy HQ to do my deployment using Sustree and development in VS Code, but that works really well. It's pretty cool.

Okay, I'll show you some stuff on the Netlify after the show. I'm going to go offline. Brilliant. It's good.

Yeah. All right. Well, I think we should have a pretty rich wrap-out desk. We're sort of approaching our time.

Yeah, it's been interesting. And I'm sure we'll talk about this sort of thing again in the future. Definitely. As your team grows and see how things have changed for you.

Yeah, definitely. We'll create a moment. So hopefully do some interviews next week and see you come to the board. Yeah, it'd be good.

All right. Well, thank you for listening to the show. Be sure to subscribe to the show in your podcast player and feel free to drop us a rating or review on our podcast or wherever else you can leave a review. You can follow the show on Twitter at Inspector FM and you can find the show notes for this episode and all the previous episodes for archive over at inspect.fm.

You can follow myself on Twitter at AdiKawal and yours is at this app. I've been Vindi. I also find my Delve agency account there as well. She's at the Adelve.

Okay, cool. I'll put it in the show notes as well. But yeah, other than that, we will catch you in the next episode. Nice.

We'll see you then. All right. Bye.