20 Website Design Requirements Every RFP Response Should Include

I’ve recently been talking a lot about website design requirements, proposals, and contracts. I’ve done so because I know a successful website design launch is more than software code, text, and images.

Website design success is a direct result of a structured process and solid documentation.

Executing a successful website design project begins and ends with a solid documentation. This documentation can be a proposal, contract, or statement of work. The name of the document is less important than the details contained within the document.

Whether you’re a small business or a large enterprise, documentation is the key ingredient to executing a website project that is on-task, on-time, and on-budget.

The more you document in the sales process, the more smoothly the process will go for everyone involved.

In a prior blog post I discussed the creation of a website RFP. Now that the creation of an RFP document is complete, I’d like to talk about reviewing and evaluating RFP responses.

Evaluating RFP Responses

Reviewing RFP responses sounds easy right? Well in all honesty, it sounds easier than it actually is in practice.

If the project team solicited quotes from a large number design agencies, the task of reviewing website design proposals can feel overwhelming. Ok not just feel – it can be overwhelming.

The greater the number of RFP injuries, the larger the response pool and variations within those proposals. Hopefully a short list of website developers was made prior to sending out the RFP, which will keep the number of proposals limited and make the review process a bit easier.

As websites proposals arrive, it is important to ask yourself some basic questions to get started. These include:

• Was the RFP response provided within the allowed timeframe?
• Was the RFP response presented in a professional manner?
• Is the RFP response well written?
• Does the RFP response address all website design requirements?
• Is the website proposal within the project’s budget constraints?
• Does the website proposal provide within the project’s timeline?

The above questions are high level questions design to help eliminate any design firm who is clearly not a fit. A late, unprofessional, or incomplete RFP response should be a red flag about potential developers. A RFP response that is priced at twice your budget, or a third of your budget, should also be a concern.

Now that you’ve received your responses and you’ve removed out any red flag vendors, it is time to thoroughly review each RFP response to compare responses in a more apples to apples manner.

Website Design Requirements to Look for in Each RFP Response

An RFP response can be of various lengths. So I won’t focus on volume of text or the number of pages. What matters is the content and the solution presented.

When reviewing RFP responses, make sure each response covers some core elements of any website project. These website design requirements include, but are not limited to, the following details:

1. Project Plan – This should include a high-level list of project tasks. While this won’t be as detailed as the actual project plan itself, there should be enough details for you to understand the flow of discovery, design, development, and build.
2. Project Management Tools – The design agency should list their project management toolset. This will vary by firm, as there are lots of great options available. The important thing is to verify there is a structure to the project management process and that tasks, owners, and dates will be well documented.
3. Team Members – Different design agencies will have different structures for their teams. The larger the agency, the larger the project team. It is important for you, the buyer, to know who will work on your team and to what capacity of work they will provide. You don’t need full resumes of each player, but you should know who’ll you be working with in the coming months.
4. Content Management System and Baseline Technology – If your website RFP did not specify a desired CMS solution, this will be an important element of your proposal. Make sure your RFP responses list out the CMS of choice and any additional technology that will be used in coding and deploying your new websites. Take special note to anything proprietary. A proprietary CMS package should be a red flag, as it locks you into that developer for the life of the website.
5. Deliverables – A deliverables list is important because it validates what is going to be delivered at the point of go-live. This could include number of design templates, volume of content migration, plugins utilized, etc.
6. Functionality List – The functionality list is very important if the website is more than a simple brochure website. The more complex the website build, them more detailed this list of functionality should be.
7. Content Migration – If your website project will include content migration, remember to document how much content will be migrated over to the new website. This could include pages, posts, products, events, users, attachments, and so on. Not defining the nature of the content migration and the volume of content will cause scope creep and additional costs for you or the design agency.
8. Image Usage – It is important to understand ownership and assignment of the images used within the website design project. Who is responsible for image selection, purchase, editing, and placement? This will vary by project so clearly define this early on in the process.
9. SEO – Don’t forget about SEO! This includes keyword research, keyword to page mapping, on-page optimization, meta definition, and 301 redirects. If you rely on organic SEO, protect this traffic source during your redesign. The easiest way to do this it to make sure this topic is front and center during the project scoping and proposal process.
10. Mobile Responsiveness – Mobile responsiveness should be part of any modern day website project. The only exception to this rule is large websites who have a separate mobile websites or apps. If you do not have a separate mobile website, make sure your proposal includes language for managing display adapted to phones and tablets.
11. Exclusions – While I do not list exclusions in every proposal, I do list them anytime the client and I discussed an item that is not going into the website project. This helps protect me later in the process, but also clarifies our deliverables for the client.
12. Third-Party Integration and/or APIs – Mid-market and enterprise companies generally have a multitude of systems and software packages within the organization. These systems need to communicate with the new website by pulling, pushing, or syncing data. If integration or APIs need to be used, make sure the proposal defines the third-party system, data points, data transfer, and responsible party.
13. Milestones – Milestones can help ensure the project team hits goal at each stage of the website design process before moving to the next step in the process.  Typical milestones include discovery, information architecture, graphic design, theme coding, content migration, beta launch and/or testing, and go-live.
14. Schedule – Each website proposal response should include a schedule that corresponds to project milestones. This will help you understand how much time is allocated to each milestone and if the overall project will align to your own timetable.
15. Delays – Project delays can be a result of both the client and the developer. It is important to understand how these delays will be handled and how they will alter the overall project budget and timeline.
16. Payment Terms– Smaller website projects will tend to have a 50% payment to start and 50% payment at completion. Larger website projects will have smaller payments based on milestones or set timing. Make sure this is clearly defined within the proposal.
17. Expenses – Expenses could include travel, domain fees, hosting fees, plugin licenses, and/or stock images. Make sure the RFP response details out the items anticipated and the party responsible for payment.
18. User Training – If your users will be new to the CMS, you might want to establish some guidelines for written training documentation, online training tools, and/or interactive training sessions. Make sure the training methodology matches that of your user base.
19. Warranty Period – A website warranty covers the correction of software bugs within the website. It is typically established for a set period of days and stated within the proposal or contract. Such a warranty would cover coding by your website developer, but not third-party plugins or extensions.
20. Ongoing Maintenance – Maintenance is often confused with warranty periods, but they are very different. A maintenance agreement is paid for on a monthly or annual basis and it would be used to provide developer updates to the software over time. For WordPress websites this would include the update of the WordPress core software and any plugins installed on the website. Maintenance can also include security, monitoring, backups, reporting, and one-on-one assistance when needed.
21. As Needed Post-Live Support – Not every company will want or need a maintenance agreement. In lieu of a maintenance retainer, some companies will opt for on-demand post-live support. This is generally billed on an hourly basis and managed through a ticket or support system.

Next Steps in the Website RFP Process

After you’ve reviewed your RFP responses and narrowed down on your chosen supplier, the next step should be focused on negotiating contracts and final details.

While web is full of advice on contract negotiations, don’t get caught up in the process minutia. It’s important to remember this task is the last step before entering into a long partnership with the chosen website developer.

The negotiations should concentrate on resolving any open questions or issues, which will in turn provide a solid basis to begin the design and execution process. Go into contract negotiations focused on resolving any open issues and clarifying any points of confusion.

If the project team has done a solid job with project scoping and they selected the right website developer, the negotiations should be no more than a signature. If the team has selected the wrong design agency, the task may prove enough to force the team to return to the number two firm.