Daniel: Welcome back to Web6. This season we are talking about how to navigate the website and project process. I’m Daniel Cowen.
Chris: And I’m Chris Lafay.
Daniel: And today we’re talking about the QA process and then we’re going to be discussing the question, how can I make sure my website really works?
Website Testing
Chris: And one of the things, we’re going to go back a few episodes here, is we were talking about the proposal and the contract and making sure that all of the things that you want are highlighted in that proposal and contract. And, this is really where that comes up and kind of shows its head from an actual, like we’ll call it a checklist format, is that when your website is ready to be tested, usable you can actually start clicking through it. Now is the time to go back to that contract, and even if you want to make a handwritten list of here’s everything that my contract says should be involved in the site, and go through it and check off all the items. Because if those things aren’t done, now is the time to bring those things up. And the earlier you can bring up these problems, the more the, the more easy, the easier. That’s the right word I’m looking for is a, it will be to actually squash those and keep your timelines on track.
Daniel: Yeah. And keep that in. Keep in mind that, you know, your developer might be demonstrating your site to you before everything is done. So, you know, just because someone shows you a website that you can click doesn’t mean every feature is there, but you know, pay attention and communicate with your developer. If they’re demonstrating and they’re telling you the whole site is done, it’s ready for you to approve and you just go through and test it. That is absolutely the time to go back to your contract and go through that checklist. What is not the time for is it’s not the time to add new features. So, if you’re in the QA stage of your website project and you start, you know, you had never mentioned a blog before, it’s not in the contract and now you’re here saying, “Well, okay, well where’s the blog?” Well that’s, that’s not the what the QA process is for
Chris: During that final QA process, when your site is done, that is probably the one of the hardest times as developers to add new features to the site. Just because you’re on the closing stretch, your designer might not be a part of that process as much anymore. You’re really mostly working with the development team to make sure that all the features and the functionality are what they say they should be in your contract. So, you then have to pull extra people back in that haven’t been a part of the process for awhile and it gets a little bit cumbersome. And that’s not to say that it’s not possible. It definitely is. But for some of these big feature adds, even if you haven’t opened it in a contract or one that allows you to make changes waiting until the site goes live and then initiating a phase two –
Daniel: Absolutely.
Chris: Is a much better and much cleaner way to go about doing these.
Introducing Phase 2 Ideas
Daniel: I was just going to say, it sounds like you’re saying if you get to the end of a project and you realize there’s something critical that you really want to have it’s, it’s very common to have another phase of development. And, even if you have the, you know, especially if you have the budget for it, you know, you’re, I’m sure your developer would be thrilled to know that you held their business for them.
Chris: Uh huh.
Test All Features
Daniel: And when you’re testing, I think it’s really important to walk through every part of the process. So if you have e-commerce on your site and you’re selling products online, don’t just click and see the products are there and make sure the prices are right. That is one aspect of, of the quality assurance process. But you as the client are responsible for clicking through every part of that from the first time you hit the website all the way through to the checkout process and making sure that confirmation emails are formatted the way that you want them to be. Um, don’t rely on your developer to say it’s okay. Everything’s good. Go through that process. Another thing that you, that I’ve noticed that clients will miss, is if you are using cookies to on your site to um, deliver up a certain message to someone one time but not another time, for instance, uh, you as the client, it’s still your responsibility to make sure that it works the way you expect. So if you expect a pop-up to come up the first time you hit the site and then not the next time but then come up after a certain amount of time later, maybe 24 hours, make sure you’re testing that. You know, I’m just trying to give you examples of the kinds of things that people, you know, forget are these little things that, you know, people forget are part of the process and need to make sure they work.
Make Detailed Notes
Chris: And every developer, every development company or creative firm or freelancer, even, have a different process they like going through for these QA notes. And QA is a very common term in this industry. Quality assurance and talk with your developer before you start going through and doing all this testing. Ask them how they would like to receive your notes.
Daniel: Right. Right.
Chris: Some people like having Word documents with screenshots. Some people would rather you do like a screencast and video your screen and talk over top of it so they can actually see these things that are not working correctly. There’s a plethora of ways and every agency, every person has a different preference on what makes their process the most efficient. And typically these different ways don’t take you, the end client, a large difference in amount of time it takes to compile them, but it might make a huge difference in terms of how efficiently and how quickly you can get back those changes.
Daniel: Right. I think another thing is super important as a, as a part of that is the timeline of how long you as a client have to turn in your feedback. So if, if it’s important to you to make sure that you have a certain amount of time to look over a certain element of the site before you need to give feedback, make sure that’s in the contract. It’s very common to have, you know, a 48-hour revision cycle where, or feedback cycle, where of the, the contractor will demonstrate the site to you and then you have two days to deliver the feedback. Well, if you’re on a really aggressive timeline trying to get the project done in 60 days instead of you know, a longer timeline, you might need to have a shorter feedback cycle and be respectful of that. If the contractor saying this is what we need in order to hit your timeline, then go along with that. If you as the client know that you need longer because you got more stakeholders involved, make sure that that’s communicated and like we’ve said over and over again, if it’s important to you get it in the contract.
Being “Pixel Perfect”
Chris: I’m going to kind of jump topics here a little bit, but something I really wanted to touch base on before we wrap this up is when you’re, especially when you’re doing marketing sites, anything that has design a part of the web is this term called “pixel perfect”. And, nowadays with browsers, you know interpreting code and unique ways. You know you have multiple browsers, right? You have Edge, you have older versions of IE, Safari, Chrome, Firefox and other ones as well. And, you have a lot of different screen sizes from you know, the big 45 inch Mac book pro to all the way down to you know, the tiniest of cell phones. Your website will not look exactly like the mockup across every single device possible. And, so back in the day, however you want to define that, the term “pixel perfect” was thrown around a lot because there weren’t as many different use cases to have to code for. But, nowadays with the expansion of the web and with all the different devices that we have, it’s really not feasible to be 100% pixel perfect to your layouts in the designs that you have.
Daniel: And, I don’t think it’s an advantage to be quote unquote “pixel perfect” either because you want a website that’s going to respond to the different ways that people use it.
Chris: Exactly.
Daniel: So, if you have a website that is, you know, productivity focused people might be you know, changing this, the screen size or the browser size so that they can be working on something else while they’re using your product, your product or your site. Or, you want it to be responsive to the many different screen sizes that are coming out with every different, you know, every new phone that or a Mac or a laptop that’s released.
Chris: Exactly. And we have watches. Now obviously you can’t put websites onto watches, but the, the screen size is getting smaller and smaller and being able to accommodate your different data points and you know, you’re selling points onto all these different screen sizes, takes a good amount of development work. And so just making sure that you’re aware ahead of time that it’s not going to be exactly like those designs across every single browser is something that’s good to know. And a lot of people know that especially that are going through this web process for the first or second time. That’s not really common knowledge. So just kind of arming yourself with that piece.
Daniel: And, you’ll make your developers so happy if you say to them —
Chris: Yes.
Daniel: “Should I expect this to be exact on, on my device?” You know, how, or even ask them, “how much flexibility should I expect” if something’s breaking into more than, you know, more lines than you want to see. That’s one thing, like lines of text, that’s one thing. But as far as the exact placement and that kind of thing I think that’s something really important to keep in mind, and you can make your, your communication even better with your developer by just being open about it.
Chris: And I think that wraps us up for this week. So join us next week to talk about actually how to get your website launched. We’ll see you then.
Dawn Audano