 Hello, everyone. Welcome to Ellison Tapps webinar where we have guest Laura S. Quinn who is here to speak to us about demystifying the steps to a successful website project. So I'm looking forward to hearing what we need to do as we go through our website build and I'm going to turn it over to Laura now. Fabulous. Welcome everybody. I am excited to be here today. Let me just introduce myself. I am an independent consultant that helps nonprofits build websites. I work a ton with legal aid. And I'm working right now with the folks building the either the new Oregon legal help, as well as the Virginia Poverty Law Center and the Lawyers Trust Fund in Illinois and I have a whole slew of previous clients. So I do both website strategy so upfront what to think about as you're trying to define what your website will be. And I am a coach and guide to through the whole life cycle. So I work with folks in like a weekly call or bi weekly calls to help them to think through best practices and potential risks and how to work with vendors and things like that. And that ties in very much with the idea of what we're here to talk about today, which is thinking about the whole life cycle the whole journey through a website process. So this is our roadmap to the whole session. So this is a pretty overwhelming slide, but it's because it is in fact a map of every single slide that is in this, this session. We're talking about before, what happens before design, which is different vendors give it different names. So the, I haven't tried to actually name this thing but it's basically everything that happens before design, then there's design itself. There is the build. There's the test and launch. And throughout the whole thing there's the project management will actually jump into project management after the right before the design. So the this presentation pretty much assumes you're working with a vendor it were it assumes that you have a sizable enough website that you're not just going to kind of crank it out by yourself. And if you have, you know, unless you're building your own site on like Squarespace or Wix, which you certainly can do. But you I'm suspecting you're not here today to do mystify that process. So this assumes that you are slightly mystified by the process, which means to me that you are potentially working with or thinking of working with a vendor. So a website firm to do your project. Let's dive in. So the steps prior to design. Some people call this entire process discovery, but I have labeled a particular piece of it which is the firm working with you to understand kind of what has come before as discovery. Talk about user research and branding, both of those are kind of optional steps, and then documenting your scope, not an optional step. Just in general, my slides that you'll be seeing today are very wordy. They are somewhat slimmed down from a deck I have that I actually use with coaching clients to describe what to expect in their project. So it is, you'll find that I'm not actually touching on every point in every slide, just for the sake of time. Do ask questions if you have questions about something that you see that I don't talk about. And also you absolutely will get the slides. So these will also be a reference that will go it kind of dive in slightly differently into some of these topics. All right, prior to design. Discovery. So discovery is should happen on pretty much every project in which you work with a website firm. That's where they review what you've already have. And work with you to understand your perspectives about what it is you're building. So they're reviewing, for instance, your website, your mission, anything you've got that's relevant analytics for any relevant existing websites. For some projects you might want to think about looking at comparable or competitive with competitive websites we don't think about competitors and the nonprofit sector but you know you probably have them. And then you want to make sure that in some way through this process, you want to define what the goals are for the site. So what your organization is trying to achieve, and who you're trying to reach in terms of audiences. This is generally done through the firm conducting some potentially internal stakeholder interviews so they're interviewing you they're interviewing your leaderships things like that, possibly email surveys with internal staff. So they send out, you know, to 20 staff members to get their opinions and workshops are a very typical thing to do here to understand okay here are approximately rank ordered goals, approximately rank ordered audiences. So, we talked about identifying audiences, you also want to think through, what are your audiences goals, you're throughout a website trying to balance the organization's goals with your audiences goals. And so it's critical to actually define what your audiences goals are. If you are going to effectively be able to do that. This is where user research up front can be very handy. And I generally recommend it on a larger site so if you have, I don't know 50 or $100,000 or more. Well, 50 or $100,000 or more, and you have an audience that is somewhat different than a typical legal aid audience I've actually in the world of self help resources for general publics. I've started to recommend not bothering with initial user research because there is a lot of user research about what low income populations want or need in terms of self help resources. So it's well worth putting those resources elsewhere like user testing, for instance, which has not done nearly enough. Anyway, sort of think about interviews. If you have a website to do a quick pop up survey conceivably I don't do much typically with email surveys or other types of surveys. This makes more sense if you have like a membership population or something like that. But then regardless of what you do. It's very useful to do a workshop or multiple workshops to arrive at agreement among kind of your internal team and the firm as to what you think the audience wants that might be based on research or not based on research, whichever doing something like this this is just a screenshot of a mural board. What is so for this audience, who are they what are their goals what content do they want what actions do we want them to take. It can kind of be an interesting balance here branding. So if you were doing a website that is more targeted towards people like donors media legislature so less towards educating people about legal information and more towards showing how you are an important part of the ecosystem who should be listened to and funded. You definitely want to think about whether you have a solid explicit vision of how you're portraying your organization. And if you don't a website can be a really good impetus to create one. This could be done by a website firm. Some website firms do branding as well. This could be done by a separate firm. It's probably a little you can make the whole project a little cheaper likely by having a specialist branding firm and then a specialist website firm. Either way, branding is typically does not come cheap is typically going to be a 10,000 to $50,000 or more project to define kind of who you are in a really compelling way. So, before you go into design. The point of all of this stuff is choose for you and your firm to agree on what the scope of your website is. So scope meaning the features, the approximate number and kinds of pages, and therefore the amount of work on a site. There is no standard way to document what the scope is, but you should make sure that it is documented in some way. So basically, if you come back to at the end of the project and you're like for instance testing, and you say, but wait, it doesn't do x. There is actually some document from you for you to go back to that says it should do that that is actually part of the site. Because otherwise things get as what you can imagine very icky at the end when there is no definition as to what actually the site should do and people disagree on that. So scope is a very typical way to document smaller sites. Here's an example. So it's just a great way to kind of get a sense of the gestalt and the site might have some additional documents to do more complex functionality. So environment spreadsheets. So you may have things that aren't easily portrayed in a diagram. So like for instance here we're looking at user accounts and how those work, how our email and SMS stuff happens. It's a lot easier just to write it out than to put in a diagram. So that could also apply. Some people also use what's called wireframes, which I'm actually going to be defining in the next section. It's basically a set of diagrams page by page. So, as you're in this particular part of the project before you get into really the, the depths of design, as you're defining your scope. It's possible that you had a either a fixed fee with your firm, or you had a range with your firm, and it's become clear as the firm has talked to you that the project is actually larger than what they understood and that would typically be because either the RFP wasn't very clear, or the RFP was out for the proposal, or there was room for misinterpretation, or kind of your own thoughts have evolved as throughout through the kind of the definition discovery strategy phase, and all of that is valid. It's also valid to say, I don't have any more budget. So, this is a $40,000 project I can't spend any more money, but then it's important to work with your firm to figure out what to drop to so that you actually can be a $40,000 project. It's very reasonable. I mean it also obviously it could be a tactic by a firm to try to bait and switch to say I can do it for $40,000 but then actually it's $60,000 if you want what you want so it's possible. It's also possible that it is actually, it like if it seems like there was room for miscommunication that it's quite reasonable that there was, they do have new information, and you need to work with them to figure out what can actually be done on your budget. Right. Questions on any of those before designed things before we take a little bit of a offshoot from the specific project timeline to talk about project management. I really liked your suggestion of using the website project as a chance to consider your, you know, your branding and your values I think that's really important because it can help what your website looks like but it also can help in lots of other things so I really like that point. Yes, absolutely if it's, if this is if this is kind of shaky that if your branding is kind of shaky and then obviously building a whole website on top of it is not going to improve it. And you will then have that you know like you'll still if you ever change it you'll then need to shore it up in the long run. So it is, it can be tricky to internally decide like alright we're going to spend time and money on this. But it is can be definitely worth the effort. Thanks. All right, project management. So here we're going to talk about defining roles status meetings and iterations and then just in general being a friendly person to your team. Actually, sorry I'm going to move things around slightly so I look like I'm looking at you as opposed to somewhere else. All right. So, project roles. So this is a big project team that we are looking at right now. So you may not actually have all of these roles. But I thought it more useful to have it bigger rather than smaller so within your organization there you want to make sure that there is a key point person so this is the communications contact for the firm. So there is a leadership sponsor. There's conceivably all of these are the same people if you're a really small organization, but you want to make sure there's someone from the leadership who is who has designated the money, who can make decisions if things go in a somewhat sideways, hopefully not sideways in a terrible way. So it's somewhat different direction who can allocate more money if needed. And that's important. You've got a core team potentially. So it's useful to have more than yourself. So if you can pull in another two people to help you think through and look at things that is actually a helpful thing to do. However, you want to make sure that it is clear who's responsible for the project success. You don't want to have a spread across a bunch of people. And possibly, if you have a whole organization worth of people who are wanting to get their hands on this project, you want to define some kind of essentially your core team is a governance structure for the whole rest of the organization. So you don't want to have more than so four more people and you. So that's five people, many more people than that being right. What really involved in the project is just going to start to have cause problems. So you want to have these people your core team go get solicit opinions and things like that, as opposed to having everybody in a mix. All right, at the firm. There's going to be should be a project manager who is kind of the liaison to your team. The project manager. So there should always be a someone to whom you can escalate your concerns. If you are over the project manager, you'll note that this does in fact imply that there's more than one person at your development firm. It's sometimes fine to go with a single firm. But that is this is a risk factor. If you go with a single person firm, is that there's no one to escalate things to not to mention, like if they decide to decide. Okay, something that's not quite so so if they win the lottery and they decide to turn things in, you know, two weeks from now, then there it's hard to know what to do with your project. So it can be a lot cheaper to go with a single person, single person firm single and independent contractor, but it involves risks. There are potentially in a larger firm, other leads. So someone or multiple people who you could in the largest project have a strategy lead, and then a user experience lead a user experience person is in charge of how a visitor sees your leads, they're in charge of kind of mocking up the pages, got a graphic design lead, you've got a tech lead, there may in fact be more people. So in fact, probably the tech lead is not literally coding the whole site themselves they have people but you'll likely never talk to the individual developers. So if you want how the project is set up, you may be talking a lot to these individual leads, especially someone like a strategy or graphic design lead. Or you may have most communications funneled through the project manager, you could in fact have one of these people acting as your project manager like you could have a tech lead acting as your project manager or a strategy you actually make sure that you have regular check ins with your so this would logically be be between the key contact and the project manager, just on the status of the project. So this is probably every two weeks if things aren't happening super fast or every week if a lot of stuff is going on. To in general here, what's going on to just do a rundown of who's waiting on what I make sure the firm knows that you're happy or not. So some of the things that I see in coaching is there's just kind of some basic miscommunication in that my clients, the organization is not very happy, and they haven't told the firm what they're not happy about. Generally, firms are really eager to make things right if you let them know what what isn't right. And depending on whether it's a flat. So flat the project means that they have a firm has said we will build the site for you for $50,000. An hourly project is one where they typically give you an estimate. So they say it's going to be about $50,000, but we are actually going to bill you for an amount of hours that's going to equate to that. So if it's a flat fee project you want to be checking in against the scope to make sure so we talked about defining the scope you want to make sure that things are being done according to that. If it's an hourly project, it's really critical to ask them to estimate how many hours they expect to use per phase. So for instance, how many hours are they going to use predefined how many hours they're going to use to find. And then check in on the actual hours that they have used compared to estimated hours. This is typically called a burn down. So, so this is so this means, so if they only expected to use 30 hours prior to the design phase, and they're at 50 hours already. So this can look like not it's hard to see that, unless everybody knew that it was 30 hours estimated for it because it's a drop in the bucket compared to the whole project. But if they're already 50 against 30 estimated, then those 20 hours need to either be made up somewhere, or you're going to pay those extra hours somewhere logically you and the firm wants to agree on what they're going to do faster or less in order to not have those or potentially get them to eat some of those hours so that not charge you for some of those hours if it feels like they were just inefficient. Another kind of overall project management concept iterations. So firms care a lot about iterations and iteration means that they have provided you a draft of something like so let's say a graphic design which is an intuitive thing. So if you provided you a graph, a draft of your homepage design, you give them feedback, they revise it and give you back a new updated homepage that iteration one, when you give them additional feedback, and they update it again, that's iteration to iterations are often in a contract as to how many iterations you have. They're careful about it. So if like for instance, the firm provides, let's say me personally, with a homepage and I say, Oh, but I think that we should do x y and the other thing, and they iterate it. Unless something else has been decided that's iteration one. And so if I now turn around to get feedback from other people in my organization, and they say, Oh, we have these other 12 comments. So iteration two, even though, like the initial, like nobody else's feedback was actually included the first time around so that was my fault that I made them do two iterations and really what should have been one. So you want to gather input from everybody. And more iterations are more expensive. So if you have a but conceivably desirable. So if you have something where graphic design is a kind of a core consideration, like this would be a more polished and like donor legislator facing websites, you may want to include more iterations or assume that it's going to, it's going to need to go through multiple levels in your organization sequentially and take more iterations. If graphic design is not a huge priority, then you'll just want to be careful and to say, All right, one or two iterations is likely fine. We just want to not exceed that accidentally. Lastly in project management, kind of an intuitive one, but one that not every organization does I can say as a consultant, you just want to be a human. You want to have a friendly relationship with your firm. So you want to be, you want to hold up your side of the project. You want to manage the stuff that you've said you're going to do and do it on time. And here's some particular things to avoid. So firms hate unpredictable clients so they don't know how long they're going to take they change their minds like it makes it very hard to manage the work. I'm criticizing the quality rather than the content. So, great. We talked about only two iterations of this homepage graphic design, but I expected it to be good. I expected this to be usable, saying this homepage is not good is not helpful. And it's not friendly. So to try to be very constructive and thoughtful about what your, what your feedback is, if you need to go to a place of, like it's just not polished it's not professional it's not to a standard that I would expect. That's a serious project concern and it should be framed like that. And just logically being unpleasant rude talking to people like their minions, you'd be amazed as to what organization how organizations will talk to firms. So simply going out of your way to not do that will win you lots of friends and firms will absolutely go to take go to the extra mile for firms who are for organizations who are great to work with. Alright, questions into the chat, or I will forge onwards. Go ahead and type questions as you have them. As we go through and I will ask them, and I will answer them as I see them. Otherwise, I think just for the, the sake of the amount of content I've, I'm hoping to share with you, I will go on. I see something for Molly. I was just asking how many people does she think should interact with the firm. So that is the idea of the key content your key contact and your core team. So ideally, you have about three. So yourself, and two more people. You only have yourself that's better than nothing. I would cap it out at like six, seven people total. So like for instance, if the graphic designer is presenting graphic designs having any more than that is just going to have nightmarish be nightmarish yeah Molly is saying we have a lot of stakeholders will want to be involved with different opinions. Yes, so that is this nebulous thing down here with additional stakeholders and possibly whole additional departments. So thinking so that's critical to think through. So, can, can, will your other stakeholders be okay with saying someone represents them on the core team. That's possible or possibly not. Do you want to plan for iterations with the assumption that your core team does an iteration, and then you put it out to possibly a whole bunch of other people, and you'll get somewhat more comments, but you're not going to take like alright this is completely a design direction. So it's worth thinking through. Yeah, so Molly's added it sounds important to go to the firm with a unified message of what you're looking for. Yes, it's certainly at least a unified message of what you're doing. So a unified message of here is what our core team thinks, and then we're going to as part of our process, we are going to then put it out to 20 more stakeholders and expect that we'll get a diverse side of opinions, and we will then parse through it and tell you what to do. It's important that you not provide a bunch of dissenting and all over the place, opinions to your firm, they're just among other things they don't know how to decide among them like if people disagree, like they don't know how to decide which to do. Thanks for that Molly. Shelly mentioned in identifying the work group and core team versus the stakeholders seem to be important element, 100%. And I acknowledge that in reality, teams don't always fall neatly into these buckets. But if you can get people to agree as to who's on the core team that will really help you out. All right, let us move on words. Thank you Molly and Shelly design. Let's talk about wireframes graphic design user testing content and taxonomy design detailed specs. Okay this almost every every slide in this presentation could be a presentation in itself. So it's, there's a lot more to know here, but hopefully I'm giving you enough to at least know what words to look about in more detail. So wireframes are black and white line drawings of elements on the page and priorities. So this will almost certainly be the first step of your firm saying, here is kind of a page by page look, or many pages. On the site look of what will be there. And this is not looking at every piece of text, every, like the layout, all of that stuff it's generally to say, is this page doing the right things, will it achieve its goals. Will it are the priorities seem to be highlighted correctly. This is, sorry, and what we're looking at is a site for legal aid at work, which is in California by the firm theory and principle. This is as opposed to graphic design, where you can see so this is the same site. This is the entire frame we just looked at. And here's the final graphic design and copy. So the copy has changed here. So you can see various things changed here. And I think this is. In fact, I think one of the things that have changed is there may be no 100% desktop layout anymore that it changed so that it's something that works, at least on a tablet if not on a phone is what's also showing up on desktop. So we've got when you go to the guided help it actually drops the menu is one of the things it does. You can see the different treatments of the logo you've got colors which you didn't have in the wireframe you've got text which is different. So you can see this isn't. Although there's not no crazy design visible on this tiny navigation, there are things that have changed. So it's important to not look at the wireframe as a finished representation of your site. And on the graphic design stage, however, this will be a book the copy won't be final, but you should take it as a realistic look, looking version of the page. And it's important to review it for, again, the prioritization of information the polish the credibility are the calls to action clear does it present the attributes of your grant brand. It's important not to get caught up on whether you actually whether you quote, like the graphic design, whether they're pleasant. It's easy for a team to get caught up on whether this is the right shade of yellow, unless there is some branding implication for this shade of yellow, that is the designer's job. So possibly or like you could say I'm nervous that this button isn't prominent enough. Or like I worry that it's not visible enough should this be brighter or more called to you know to attention somehow, but simply saying I hate that shade of yellow is exactly the type of thing that can just believe to total disarray. You should leave to your graphic designer user guessing. Underrated. Very expensive. Here's a couple kinds of user testing that you can do that you could look up on after this if you wanted to to find out more about them. You can likely do user some user testing yourself. It's not rocket science to name a book in that field. For a contractor 1500 2500 is the type of thing that I do, for instance, for a small test, your firm may or may not do user testing unfortunately there's too few of the two for two few firms have it as one of their kind of core competencies content and taxonomy. So taxonomy refers to the, the organization of the structure so what the categorization is so here we see the list taxonomy content design and content strategy is also a huge thing in of itself to basically say, what type of content should we have on our site. We'll see it down, we'll do it. How is it updated over time. Is that achievable. All of that good stuff. Unless it's been arranged in advance, likely all of the contents design and organization and strategy will fall on your team. So this is something to think about way up front or sorry not before the project but early in the project to make sure that you are prepared to think about these things what are the types of content that's important to you do who's doing it how is it being updated all of that good stuff. Or there certainly are content strategists who you can hire to augment a project. I do that as well. Functional specs. On a more complicated side like for instance if you're building a triage portal or something against that. Business rules that want to be documented. So you might so things like what values are in a drop down box what how and especially and or logic tends to be much more complicated than you immediately realize it's counter intuitively complicated. You can either note the rules on on the wireframe, or still on some projects, people will do whole functional specs. All right, I'm going to forge onward through built, please do put your questions into the chat and I will go back around to answer questions. I'm realizing that my earrings match my brand color that I'm using in my slides which was not purposeful and is a little freaky. All right. In the build. So writing site content. Actually literally building the site front end testing getting content in and redirects. So, writing the content. It looks coordinate and color coordinated. So, it's often a huge amount of work to write the content for your site, and it's often left way too far to the end and it actually is. It's not at all unusual for it to delay the launch of the site, because you as an organization are still carefully writing the marketing text. So like for instance what goes on the homepage or the about page. You're finalizing the text of what goes on every button every link what the nav says. And there's obviously that people don't typically forget about this but it's a vast amount of work potentially the long form articles and information that are on your site. If you are moving stuff over from a different site which has long form articles or information. Definitely worth thinking about at least doing a pass for what's called rot redundant outdated or trivial content. If not a detailed audit to go through every resource on your site. On my website there's some pretty detailed resources about audits and how to do the building the site. So, the build is going to take up most of the, or the probably the majority of the hours for your development firm, but you're not actually going to be that involved in it. There's three kinds of things that you, you don't even necessarily need to know this, but it's sometimes useful to know there is front end testing front end testing is. I'm sorry front encoding, forgive me front encoding is done is the implementation of the graphic design into flat web pages. So it's what used to be just the HTML and CSS work which now is, you know, ballooned out. And includes, for instance, all of the accessibility work. There is the system development. So, if you're building on something like WordPress or Drupal, which you probably should be if you're doing a site of the size that we're assuming here. Much of the work is in configuring the system of kind of interconnected pieces, installing add ons modules. There's not actually, you can do fairly sophisticated sites without ever actually doing any custom back end coding. However, if you're doing things like decision trees or triage you're pulling information out of the database. That's going to involve building custom back end code. We're going to come back around as to why you might care in just a second front end testing. For a larger site, the firm will probably finish coding the front end pages. Well before they have the full site done. And it often makes sense to start testing the front end pages standalone. So it's just kind of here's a link to a page here's another link to another page. Before the site is done. So, the firm should certainly be doing a design review so their graphic designer should proof to make sure that the pages actually do look like the graphic design. This is a time the time for them to do accessibility testing as well. If you want to make sure that they are doing some automated tests, unless you have a very expensive project almost certainly your accessibility testing will be automated. Human testing is a lot better, but it's, it's quite expensive. And it needs a lot of expertise, which is why it's expensive. And in your organization, you want to review each page so they'll send you a bunch of page page templates to look at. You want to review each page on an actual phone, and on a desktop. So an actual phone as opposed to a, as opposed to a phone emulator on a desktop, they are good but not perfect and given you almost certainly have a phone, you might as well just bring those pages up on a phone. You should log all the issues you find, but only fix things that are clearly important. We're going to talk about prioritizing issues in a minute. Somewhere hovering between you and the firm is a very important aspect which is browser testing. So, we've mentioned a few devices, somebody needs to be testing a fair number of devices like probably like some combinations of phones, browsers, desktops, things like that. It should be defined who is doing that. Typically the firm does it. But I find often when you ask them about it, they're like, oh no, we're going to test these three things. If you want more, you should do it. You want to think about how content is getting into your site. Logically, there's at least some of it. There's the stuff on your homepage, there's the about page and all of that stuff. So, it's going to be one or two things. Likely, it will be mostly manually entered. So you'll use your WordPress or Drupal to actually put content into your site, copy and pasting it from someplace else. If you are copying and pasting it from an old site, keep content accessibility in mind as you go. So things like image alt texts and ensuring link texts. You may think that it's desirable to pull a bunch of old information from your old site over to your new site automatically. It's a lot less straightforward than you might think. It's kind of just hand wavy, 20 to 40 hours, kind of regardless of the amount of content. So if you have tons of content, if you have thousands of pages, then this could well make sense. But if you have a couple dozen pages, it's almost certainly going to be faster to copy and paste them. And you're going to need to proof by hand regardless because it can just old sites tend to have weird formatting that doesn't move over quite right. It's just it's very difficult to strip out all the old formatting and get it all formatted correctly. And so this is the type of place where if you have a giant site, you have thousands of pages, people will hire attempt, for instance, to look at each page redirects. If you have an old site, make sure if for instance you had a URL that looked like this article slash about us and it's going to be just about us. And then one points to the other, or you'll break all your old links and you will no longer have the search engine optimization you use that. All right, dash to the end and then we will have some time for questions. Oh, I love you so Shelly added something to the chat. I said iterations user testing firm size and documentation are all good things to know so that it is possible to compare firms on an equal footing. Absolutely yes and that's. So this is definitely a. So we looked at in a previous webinar kind of planning for your project. But as you think about all of the things that we're going to we're talking about here, they can absolutely be useful in thinking through and asking the right questions to hire a development firm. So, yes, all of those things that Shelly mentioned and I will add something yet to come, which is testing testing is really important to ask your firm about. How is our testing and then the testing stuff that's to come. In fact, it's coming right up. QA and testing hosting and maintenance, launch and training and then just the idea that this is not the end of the flow but just the, just the beginning hopefully of your awesome new site. All right, so. They both mean the same thing. So, too often in the website world testing is defined as clicking around the site. So, and certainly that needs to be done. That's the lowest bar. So, so you should plan as your organization to spend a few hours clicking around to make sure that entering content looking at things, the leading content, you know, making sure that things seem to be working right. And the firm should be doing the same. If so if you remember back to this page, we talked about custom back end coding. So you have a database you've got a triage you've got decision trees. You should think about what's called system testing. Somebody should define scenarios to test all of the things that has been custom coded. And ideally somebody else should conduct the tests. And if you imagine triage, that would mean defining a bunch of different paths, not, not literally every different path through the triage, but a bunch of representative paths to the triage, and then looking at like, and if for instance resources are like law firms are recommended at the end of it. Somebody should define which specific law firms should be pulled up based on what specific criteria is entered, and somebody should test to make sure it's actually doing that. This is very frequently really underdone. This is not an area where just clicking around is going to find the truthfully likely, at least slightly existent issues that come with every build like no firm should be expected to build things perfectly. And no firm shouldn't be expecting themselves to build things perfectly so they should also be testing. And they also hear about user acceptance testing. This is if you have a larger firm and a larger sites. This may be checklists or scripts of some sort that they will ask you to walk through, which conveys that you have checked the site and you're happy with how it works. It's important as part of your scope, all the way back thinking through the beginning to the beginning on your defining your scope, agree on who will test what, and how many hours will be reserved for testing, and for actually fixing problems that are found. The time you get to this point in the project, things are often behind or even running on fumes. And that's a bad time to have a, you know, high level discussion of what's the expectation of how much time the firm is going to spend testing and fixing. If you need to drop features to ensure that there's time to test them, that may well be worthwhile. There's no point in putting a detailed triage that takes you to law firms, if the law firms all wrong, or cannot be our only right 95% of the time in a unreliable way. So I'm not going to go all the way through this table. So the purpose of this table is to give you a mental model that you will likely on a bigger project find a lot of issues. Many of those issues will be tiny. Like, for instance, the navigation moves six pixels to the left on this device on this page. So, yeah, okay, that's not optimal, but it's probably not going to make a break your website deployment. So you want to think carefully about what you actually wants to ask to be fixed. And when you're speaking to your web firm about so basically that's the priority useful useful that have nice to have useful critical. When you're talking to your web firm about it, it will be very important to them as to how it matches the specs. So all the way back to the, what we talked about in terms of functional spec. So, a bug using that term will mean to them, it does not match the spec. So it was clearly defined what this should do, and it doesn't do it. And that should logically be on them to fix. Make sure you don't use the term bug to mean something else, like for instance that it's not in the specs or there's been a miscommunication, or you'll get into a argument about the word. Whether it is or is not in the specs, because it's actually really important to try to not go down a rabbit hole, like fundamentally, if it's critical, then it's critical, whether or it is or is not in the specs, although in fact the specs are wrong. So, you get into this. So with these overlooked and miscommunication areas, basically you get into a process of defining priority and trying to just fit what you can fit into the time that's allotted to fix issues, which is as we talked about non zero. And it's important to define it as a non zero amount of hours. Alright, just a couple more things here maintenance. So, the, there's two different entities that are going to help in the future of your site. The maintenance is a person who is doing things like security updates and maybe small updates to your firm. The hosting provider is a large global firm that literally connects your has your server and connects the website to the internet. They should not be literally the same person, though, basically that's a question for them and they may be presented as the same person but they should not literally be the same person. The launch, you can look at this through your own at your own leisure the launch is a pretty minimal thing I mostly put the slide in because people ask well what about the launch itself, but it's by this time, it's often pretty anticlimactic. And you want to make sure that you don't think of the end of your so think of your site launch as the end of a journey. It is the start of a journey, which is to have having and maintaining this awesome website. You want to make sure that you're updating content you're planning small feature releases. You really want to plan for small improvements rather than just saying alright we're going to let this one, hang out there for five years and then do another redesign. That's not really the right way to think about it. So that is our, I should put this slide at the end I'm really wishing I didn't I'm going back to our whole roadmap here. That is our look at the steps to demystify a website and look I have one whole minute to answer your questions before we wrap up questions but I'm certainly am happy to stick around for another few minutes to answer questions should you have them. And I know that I picked up a lot of things I have probably six pages of notes. Well it is going to be the top of the hour if you have a question we do encourage you to, to ask it. But I want to thank all of you for stopping into our webinar today I want to thank Laura for being here and demystifying the steps on a website build I know that for people like myself who get into this and don't have knowledge this is going to be a really great resources we move forward. We will get it posted to our YouTube channel will also have the slides there. And hope you'll join us for some of our upcoming webinars. And do this was the slide I was supposed to end on. I do if you have quick questions I do. I'm happy to answer quick questions. Please do email me. I'm just Laura at Laura s Quinn.com. And I will do what I can with a quick answer. I should mention that we do have an office hours. So we should definitely talk about that so it is on December December 12 I believe at. Yes December 12 at noon. So it is exactly the time next week. And we'll take any questions you have and have discussion on kind of the steps and what people have learned they should be through their own expertise on what they should be thinking about websites. Awesome. Well, thank you. Thank you.