You need is very specific website requirements to carefully delineate what the web content is going to be, what images are going to be used, whether there are requirements for data capture like web-to-lead forms. the requirements gathering process has to be done up front, because the more you get into defining those website requirements at the start of a project, the better able you are to meet deadlines, budgets, and overall satisfaction on the project.
TRANSCRIPTION:
Hello, and welcome to our website requirements video. I'm Chad Hill, and I have Adam Stetzer here with me as well.
Good afternoon, Chad. Everyone at Semify is super excited about the relaunch of our website reseller program. There's been a lot of talk about how great these websites look. A lot of our resellers who currently sell SEO and PBC and social media are eager to expand their services, offer websites to those clients.
But we've also encountered some discussion in our forums and through our account managers where we need to get a little bit back to basics on what website requirements and the gathering of website functional requirements really is. So I thought today's video would address that.
Let's back way up and let's define what is a website requirement? What's a website requirements document good for? Why do I need website requirements in my project to begin with?
Yeah that's a great question, and it's one of the things where a lot of websites get stuck with poorly defined requirements. So that usually comes down from expectations of the end client that if they see a pretty looking website template or a visual design that someone's done, that once they say, OK, that looks good, let's build it, that that's enough, and that people can go build a website from there. But the reality is, that's really just the very, very beginning, because what you need is very specific requirements in terms of what the content's going to be, what images are going to be used, whether requirements for data capture like web forms. So, all of that stuff has to be done up front, because the more you get into defining those requirements at the beginning of the project, the better able you are to hit not only the deadline, but the budget for the project, because if you discover and come up with new requirements or undefined requirements late in a project, it's only going to, again, extend the deadline and most likely the cost.
Right. So at the highest level, having definition for what the website will look like, what it will do, how it's laid out, how many pages it will be-- this is how you ensure that your customer is happy, they get what they thought they were going to get, and they come back and buy more things from you. That's pretty well documented.
So if you're new to the world of defining website requirements before the coding starts, you should reflect on that. And you're probably watching this video because you've already realized that without that, you end up with unhappy customers who fire you. Maybe you've been fired. Maybe you've got an unhappy customer right now.
So if you buy into this idea, Chad, that OK, yes, I need to learn more about website requirements-- I maybe need some help in understanding how to define them. Let's start talking about that. Is build me a website with five pages-- home, about, services, a blog-- is that a good requirement? Is that all I need?
No, no. I mean, I think that's exactly we're saying here is that each one of those pages is going to have an image, and it's going to have text, and it may have other requirements that you want to capture. So what we've done that's maybe different than some processes people use where you put the five pages up, and then you get into an eternal back and forth-- and I have friends that are in the website design business, and I routinely hear them saying that it takes them six or seven months to get a website done. And I always sort of laugh at that, because it just seems so efficient to spend that much time going back and forth.
So what we've done is said, look, we're not going to start developing the website until we have all the requirements. So we've built a PRQ process, which stands for Project Requirements Questionnaire, and that is where we gather all the requirements for your website-- the exact text, or if you want us to write the text, at least giving us direction on what text you want written. It's a website requirements document. It should provide enough information that we can then predictably and reliably, after you say I'm done with these requirements, go build the website for you in, again, a very short period of time.
Right. And we've really borrowed this concept directly from other industries such as construction or home building. Picture someone starting to build a house when you haven't fully defined everything you want that house to be. They wouldn't do it, right?
They're not going to pour any cement or run any electrical or sewage until they know, well, how many square feet is it? What kind of roof do I need? How many stories? How many windows? How many doors?
Because they understand there's going to be rework or unhappy clients, because expectations weren't met. We're doing the same thing here with websites. It's just common sense.
It seems like it might slow down the process, Chad, so I want to address that next. When people understand our process, where we don't take any money until we fully understand what the full scope of the project is, which, again, we think ensures the customer will be happy, because those website requirements are documented, some people will probably look at that and say, wow. That's a lot more work than I'm prepared to do. What do we say to those folks?
Well, I think we say that, really, it's not. Because what you're doing is just front loading that work. I mean, that work is going to have to get done in order to get the website launched. And like I said, the friend of mine who may take him six months-- if he adds up every minute that he spends on that website, I'm pretty sure he's not making very much off the website. Or if he's making money, he has to charge so much that the market for his websites is going to be a lot smaller.
So what we're doing is we're saying, look, take all that time, condense and consolidate that into the phase your project where you define the requirements, and then we're able to take that and go build the website. In the end, you'll end up either saving your money, because you're doing it up front and having us work on it instead of someone who takes six months, or you'll basically be able to mark your clients' price down. And so that's really where you want to go.
Right. So it's a little bit deceiving. It feels like more work, because you may be looking at more activities right up front. But as Chad said, doing this up front is actually making the overall project more efficient-- i.e., more profitable-- and it's also selling the right expectation for your client.
So if you're just starting to understand what website requirements are, why you should gather them, how you should write a good requirement, how you can use software to assist in that process, like what we have at the Semify website reseller program, also think about the overall profitability and customer satisfaction you're trying to achieve, because you'll learn pretty quickly that front loading this work makes the overall work level lower, not higher.
