Download our FREE Requirements Gathering Form PDF, or read on to learn about how to properly gather requirements for a website.
When gathering requirements for a website design project, it is important to cover the right topics in order to gather sufficient information. I’ve previously written about how to set your agenda with a client for the website design requirements gathering session. In this post, I will be covering some of the proper criteria for your project requirements.
Or continue reading about the requirements gathering process below.
Requirements Gathering Form Overview
Smaller projects can typically be assessed and defined in meeting duration of 1-3 hours. Larger projects may take longer and need to be broken up into multiple sessions with different stakeholders. How thorough you want to be may vary depending on your client’s preferences. Your end goal of this session is to define the following criteria of the project:
- Business Objective
- Website Design
- Website Features
- Website Layout
- SEO / Search Engine Optimization Strategy
Keep in mind that many clients, especially on smaller projects, don’t really know what they want and are likely expecting you to make recommendations. When you have the information gathered, you should be ready to make your design mockups and put together a binding agreement/statement of work.
Website Objective
Newcomers to requirements gathering often forget this key component, which is to define what the client’s expectations are of this project. While it can be easy to assume that they want to increase their business growth, that is too vague of a goal and does not allow you to provide a proper strategy to meet their objective. Additionally, some key functionality should be briefly discussed before diving deeper into the other topics. These criteria are:
- Objective
What is the specific objective of this project, and how will we try to meet this goal? - Basic Features & Functionality
This should be a brief overview of a few key topics: Is this website going to be responsive or have a mobile version? What are the key features of this site? For example, this may have e-commerce capabilities, support multiple languages, or have a business directory listing. - Deliverables
Discuss expectations and deliverables for project documentation and processes - this includes how wireframes and mockups will be delivered, timeframe/project plan (including project reporting aspects), how communications will be handled, and quality assurance processes and standards. Smaller projects may not need a wireframe or project plan (a projected deployment date will do), and quality assurance may be as simple as discussing browser and device type support.
Website Design
I typically cover how many design mockups will be expected for the client to review – 2-3 options is usually sufficient. When diving deeper into the design aspects available, I then decide on what to include on the different designs I will provide. For example, one design could have a set of 2-3 chosen colors, be full browser width, have square buttons, and have a menu spanning the top of the site horizontally. A second option could have a set of 2 chosen colors, have a max width of 1200px, have round buttons, and have a menu spanning vertically on the left side.
Below is an outline with some notes of the topics to cover for the website design.
- Review design Examples
I find that the best design samples can be found by reviewing competitor websites, reviewing template designer demos, or viewing website design award sites (such as http://www.awwwards.com/). - Logo
Does the client want to redesign their logo? If so, define how they want it to look. Keep in mind many clients already have marketing collateral in place and may not want to change their logo. - Color Schemes
What colors do they want on their website elements? Usually 2-3 primary colors are sufficient. Larger companies may have branding guidelines available that will already contain color choices. - Design Mockups
How many design mockups should you provide? Usually 2-3 mockups is sufficient - Design Elements
Areas to discuss include:
Buttons/calls to action (square or rounded edges, gradients, etc.)
Website Dimensions (max-width, alignment, etc.)
Borders
Headers
Padding/Margins (more padding vs. tightly configured content) - Images
Is the site going to be image-heavy? What kind of theme? (vectors, photography, or stock images). Discuss a content to image ratio. - Menu
Horizontal or Vertical navigation? Fixed/”sticky” navigation or static?
Website Features
The features that are implemented in the website can often be where many of the hours of work estimated are used. While areas such as the design and layout are easier to calculate the work hours (the variables are usually how many pages, how many mockups provided, and page complexity), website features can vary quite a bit. For example, an e-commerce site with many products and variants will have many more hours allocated than a site with simple e-commerce functionality for making a Paypal donation. Larger, more complex projects should have more bullet points added for core features, and be more detailed on their functionality.
- Content Feeds
Discuss potential feeds – these could be either internal or external content. External content sources include Facebook/Twitter feeds, aggregated content, or Yelp reviews. Internal feeds could be content previews to other pages within the website. - Content/image sliders and rotators
Discuss if they want to have this feature or not. They are becoming very popular on websites, and add some visual flair to home pages. Keep in mind that statistically they are under-utilized by visitors (i.e. they don’t get clicked often), and are usually only recommended for the visual benefits. - Core Features
This section is reserved for primary features of the website. If the website has e-commerce, discuss products, product variants, checkout, payment options, etc. Try to cover all the important aspects – usually you can find reference sites with similar features that you can use as topics reference. Another topic to cover is integration with any vendors or 3rd party software they use, and ask if they have any future implementations planned. Keep in mind that it is crucial to define what is included in the project and what is excluded. - Forms
This topic is should include forms used throughout the site, such as contact and registration forms. Gather what information should be required to fill out on these forms, and remember that registration forms should gather the bare minimum of information in order to reduce bounce rates.
SEO / Search Engine Optimization Strategy
Depending on how many hours are allocated into SEO for the website deployment, how thorough you want to be may vary. I believe that any website should be initially setup properly for SEO, so always allot a base amount of hours for this and discuss this topic. A basic understanding of targeted audience and keywords should be garnished, which will help you with the implementation and provide a good starting point should they decide to utilize your SEO services.
- Explanation of SEO
Start with explaining SEO and its benefits. Many clients do not understand what it is or how beneficial it is to their business. - Company Profile
Gather a basic company profile – what they specialize in, what their plans are for expansion (such as adding a new product line or service), and who their customers are. - Competition
Define who their competitors are – this will help you see how they achieve success and analyze potential improvements. - Local vs. National/International
Define if their audience is local or on a national/international scale. This will dictate keywords and organization of company profiles. - Targeted Keywords
What keywords does your client think would be relevant to their business? I advise doing some research before-hand in order to get search statistics and provide some recommendations. - Adwords
Briefly cover Adword options so they are aware of the benefits. It is usually not a good idea to start purchasing Adwords after a new website launch. It may be a possibility if there is already analytics data available, but if there are major changes to site structure and content, it is best to wait until the new website is indexed. - SEO Strategy
I don’t recommend going too in-depth on this topic in the initial requirements gathering session. However, it is recommended to discuss what kind of benefits can be obtained from long-term SEO campaigns, and your strategic approach.
Website Layout
The website layout is usually constructed around a wireframe and/or sitemap. This will help decide what content will need to be written/carried over and the overall layout. Smaller website projects are usually less strict in this area, and may not need an actually wireframe or sitemap to be created. This is not necessarily a bad thing, as it may give you some freedom to create a better user experience (as long as you make the right decisions!). Even without generating these documents, covering the following aspects is still important.
- Sitemap
- Pages
Discuss pages to be created or added to existing content. Also cover main menu items, sub-menu items, and any additional menus used throughout the site (including how they link to each-other). - Layout Consistency
Discuss if pages will follow the same layout across menu items and while drilling into sub-menu items. It is usually a good practice to follow the same general layout site-wide, however home page and sidebar content can fluctuate when implementing different cross-selling, content feeds, or calls to action. - Header & Footer
Layout in these sections should be defined for mobile devices as well (if this is a responsive site or has a mobile version)
- Pages
Other topics to take into consideration
The topics previously discussed cover the business and functional requirements for you website project. System requirements are another topic to take into consideration, and this may vary depending on what platforms you utilize. If you have a specific platform or CMS that you utilize, it is important to cover what that is and the benefits that your customer can harness from it. Larger companies, especially ones that have their own IT department, will likely have their own server environment and may or may not want to provide their own hosting. I know from experience that trying to convince Windows Server customer that open-source/Linux-based solutions are viable is an uphill battle. The key factors that system administrators often take into account are:
- Can we support this server?
This includes the Server OS (such as Windows or Linux Server), Web Server (such as Apache or IIS), and Database (such as Oracle, SQL, or MySQL). Many companies invest millions of dollars into disaster recovery services, and may want to utilize them on their new website. Also, if they are a Windows Server environment and consider bringing on a Linux server, do they have someone who can support it, or would anyone want to? - Does this software provide 1st party support?
Many companies have specific requirements around software vendors and solutions, and if your platform doesn’t have 1st party support they may reject your proposal. Of course, if you have your own platform and have been around for a long time, this is probably a non-issue. However, CMS platforms like Wordpress, Drupal, or Joomla all do NOT provide 1st party support. - Does this software integrate with our existing software and services?
If the company utilizes software such as a CRM or ERP package, they may require integration with them. Sometimes there are readily available solutions, and other times these solutions may need to be custom developed. On rare occasions, the software or services may not integrate well with others because they want them to only rely on that vendor for solutions.
These challenges can be difficult to address, but it helps to leverage the strengths of your solution. While an enterprise software packages may address all of these concerns, is that solution cost effective and within budget? Your client may make concessions on some of these aspects if you appeal to them in the right way.
Regardless of who is hosting the website project, it is also important to define what requirements your platform of choice has, so that you don’t run into issues when it’s time to deploy the website.
Conclusion
We’ve discussed some of the key topics to cover while gathering your requirements, but I recommend fine-tuning your document to fit your specific needs. This document is more generalized to approach a wide variety of initiatives, and is a good starting point for your own documentation. When finished with your requirements gathering sessions, it is usually a good idea to send an e-mail with the completed requirements document for your client to approve. Once approved, you can then put together your binding agreement/statement of work, which should include the project objectives & scope, deliverables, boundaries (assumptions & commitments) , project inclusions/exclusions, and tasks/estimates (hours & billing – use exact estimates rather than ranges, include a project timeline, billing schedule, and a breakdown of hours estimated). Smaller projects may be more loosely defined and have fewer topics in the binding agreement/SOW, but they should still cover the project objectives & scope, inclusions/exclusions, breakdown of hours estimated, billing schedule, and deployment date.
I hope this guide helps you with gathering and organizing requirements properly, and wish you luck with your project!