When you are writing your requirements for your next web project, here are some handy questions to ask yourself to make sure that you are doing an effecitve job. Being a web developer myself, I've seen a lot of variety of requirements from different clients. From no requirements, to well thought-out and concise requirements. Realize, that projects with no requirements always end up with requirements by the time we are done discussing your project, so just do them ahead of time. Specifically, by a list of requirements, I mean written down, clear requirements about the web site and the environment the web site will operate in.
When a potential client comes to me with well written requirements, I know that this web project isn't some random idea that a person isn't serious about. Also tells me that you have a clue about web sites and running a project, which in my experience always leads to a better relationship and better outcome. I am a lot more likely to take your project if we can communicate, and the requirements and our initial interview is often all I have to go by.
Why are writing requirements important?
Writing good requirements are most people's least favorite thing to do, but are important in so many ways.
Clearly set expectations
Allows your web developer to accurately estimate time (so you stay on budget)
Makes any requirements meetings before the project starts more efficient (nobody likes to waste time)
Your potential web developer will know you are serious and is more likely to take your project
Less communication needed during the completion of the project (no wasted time)
All of the tips I'm offering to you are part of my initial interview process that I go through with potential clients and their projects. This is BEFORE the project is started. So if these questions are answered in the requirements before we initially talk, the initial interview goes smooth and we can talk about more exciting stuff, like brainstorming the ways your web project can help you in ways you never thought of.
You'll also find that these tips center around figuring out how your web project fits into your business. This is something your web developer needs to understand. If I work on your project, I must understand your business so I can make appropriate decisions as I develop the site. I also can then recommend small, little things that might make a big difference in how your users interact with the site.
Does your pizza delivery guy need to know about pizza?
You wouldn't send a pizza delivery guy out without understanding pizza. He wouldn't realize that it needs to be delivered hot as a priority, and he wouldn't understand that people might want sprinkle cheese and pepper with their pizza. He might even flip the pizza box over and ruin all that cheesy deliciousness if he doesn't know what a pizza is. So in the same way, please make sure your web developer can understand your business before letting them loose on your project.
So here are the questions to ask yourself when writing requirements for your web project.
1. What is the business purpose of your site, how does it fit into your overall business model?
Without knowing the purpose and how it fits in, what will drive the little details of where things are placed, and how things are done. Don't have your pizza delivery guy know nothing about the pizza.
2. What goals do you have for visitors of your site?
Do you want people visiting your site buy something? Share something? Signup for something? This is really important for layout of your web pages, and how the site is designed to funnel people towards those goals. Just reading an article is rarely the goal, you want people to form a connection with you, so make it easy for them to do so.
In addition, knowing the goals allows us to put the proper analytics in place to make sure we are tracking those goals.
3. How will your customers reach your site?
Search, Ads, Social media? Sure, you say all of them right, but what is the reality? Do you know where they are coming from now if you have an existing site?
4. What geographic location of people does your site serve?
If you are only targeting local people, then the web site should reflect that and it should be obvious to visitors of your site that you are a local company. Also helps to figure out what your methods to reach out to people should be. Its easier for local businesses to focus efforts on a small area, than a bigger area like the whole US.
5. What are some examples of similar sites that you like?
This doesn't mean: What site should I copy? As unique of an idea as you have, there are almost always people who have done similar things, reinventing the wheel is not good. Even if its bits and pieces from several different sites, this is a tremendous help for a designer to get what color schemes you like, and what navigation you like.
It's also important to know what you don't like. If you don't like big image sliders at the top of the home page of sites, please tell somebody. Save everybody some time.
6. How will the web site be hosted? What are the capabilities?
If you already have a hosting solution, or know what you are going with, this is very important to know. Why? What are the hosts capabilities? The site that is designed must fit into these parameters. Also, right along with this is what are your backup requirements for your files and database. Designing these into a system can take some time, so include it in your requriements. You have thought about backups, right?
7. How many people will have logins to the site?
Its just an estimate. Also, how many of those people will be members of your organization, and how many will be customers? Its important for the web developer to have an idea of the type of internal security that is needed, and what roles will be necessary to protect content from internal vs. external vs. anonymous users.
8. What user authentication methods will you use?
When users register, do you want to just user regular old user/password that is saved in your own site's database? Or do you want to allow Login with Google, Facebook, OpenID? Or is this an internal site that you want to use an existing login system like LDAP?
9. How many users will be allowed to contribute content and what kind of technical ability do they have?
Designing a rich text editor for a single person with lots of technical experience is a lot easier than designing one that will be stripped down so that a non-technical person can't make posts that look bad. A technical user can be trusted with a lot more control over the way the content looks and is formatted.
10. What kind of content will people add?
That helps determine the work required to theme the individual page templates. Typically, individual content types will have their own template, which just means the layout of the individual fields within each content type might be different enough to have its own special HTML/CSS page layout.
Knowing the different type of content also helps to imply what other kind of views might be needed. Such as, if you have an Event type of content, then it implies you will have a calendar view, and possibly an upcoming events view. This is another really important part to have for estimating time properly.
11. What roles will users be able to have?
This mainly has to do with security, but also usability. This is what user groups the users fall into, those user groups can have permissions extended to them.
The security part is to make sure that only certain types of users can add an Event, but that other users cannot. Maybe you have certain users that are superusers and can edit or delete any existing Event content.
For usability, if a person cannot edit an Event, then they should not see an "edit" link. Its important in the usability of a site to only have the valid actions presented to a user.
12. How will users interact with the content?
Do you want users to be able to comment on particular types of content? Do you want them to share on social media using share buttons? Which social media outlets? Just putting them all on there is pointless, too many options leads to indecision, narrow down the most important sources and include those. Can always change later.
13. Any restrictions on technology or licensing used?
An example of this would be no Flash used for videos. This is probably more important for internally developed software, but it needs to be discussed. Its a given that the license will be need to be compatible with your intended delivery method, as there are different restrictions if you are selling the software, or just using it internally.
14. What devices do you want to target?
This is where designing for the small screens on mobile devices comes in. Its also good to prioritize the screens you design for, whether it is PC, tablet, mobile. All comes down to effort required and you can save money on your project if you can keep the design flexible (buzzword: responsive) enough to work on all devices with a single theme layout.
15. Do you want a single site for mobile?
When it comes to mobile design, there are a couple broad options: single site that does all sizes of devices, or a mobile-only device. The trend, and the better way in my opinion, is to go with the single site that is flexible to shift with screen size.
16. Do you have any graphics or color scheme that will be provided?
Already have a logo? Already have a vast library of stock images that will be used? It's important to mention this so your graphic designer knows what they have to work with. If your brand has a specific color scheme, mention that it needs to be adhered to.
17. What are the metrics for success?
This is related to what goals you have for embarking on this web project, but list out what a successful web project completion would mean to your core metrics. Increased visits? Increased shares? More sales or signups? This helps communicate what is truly most important to you so expectations are clear.
A big part of this is also knowing what those metrics are currently. Or if you don't have an existing site, what you estimate them to be. Use of analytics in a web project is a MUST, you need to be able to track your progress, at least to ensure that your web project doesn't cause you to take a step backwards when completed.
18. What are your frustrations with your current site?
You have built up experience using your current site, or even other similar sites, so communicate those frustrations. They will be #1 on your developer's list of things to take care of on the new project.
19. What do you want to keep the same as the old site?
This is important too, if you like something, its important to understand why you like it so that if possible, it can be incorporated into the new site. At the very least, a similar feature can be implemented to give you the same benefits.
20. What methods will you use to drive traffic?
If you drive traffic through advertisements, it may mean that you will want to be able to create landing pages easily and track the metrics. If you are collecting signups on your landing pages, will possibly want to tightly integrate if you are having to make new signup forms often.
21. How will you send email from the site?
Will you have the capability of sending email from your web hosting company, or will you be using a 3rd party like MailChimp to collect signups and send followup emails.
22. Are you taking payments on your site?
Who is your payment gateway and processor? What kind of products or services are you selling? This also helps to understand costs incurred with PCI compliance and other taxation factors.
23. Do you need an SSL certificate?
Are you wanting to protect a shopping cart, or the admin area, or both?
