Key Takeaways
A useful website redesign request for proposal explains the problem, defines the work, and gives every respondent the same information. It should make it easier to compare proposals without locking you into a technical solution too early.
- Connect the redesign to a clear business problem and measurable goals.
- Describe your audience, current site, scope, and technical needs.
- State timeline, budget context, responsibilities, and deliverables.
- Ask each respondent for comparable information, then assess proposals consistently.
- Confirm ownership, accessibility, search visibility, and support before signing.
What to include in a website redesign request for proposal
For a broader diagnosis of whether the work calls for a redesign, development, performance work or conversion fixes, start with our Website Design & Development guide for small businesses.
A website redesign request for proposal (RFP) is a shared brief that helps you explain what needs to change and invite designers or developers to describe how they would approach it. You do not need to know the technical solution in advance. You do need to provide enough context for respondents to estimate the work, identify risks, and ask useful questions. Think of the brief as a decision tool: it should help you compare proposals on more than price or visual style.
State the business problem the redesign should solve
Start with what is not working for the business or its customers, rather than opening with a request for a new look. Perhaps visitors cannot find the right service information, staff struggle to update pages, or the site no longer reflects a change in the company. Describe what you see, who is affected, and why it matters now. Separate confirmed issues from assumptions so a respondent can investigate instead of treating every guess as a fixed fact. a clear problem statement is a useful first step whether you plan to handle the brief yourself or hire help.
Set measurable goals and success indicators
Turn the problem into outcomes you can observe. Goals might concern inquiries, completed forms, important page visits, content maintenance time, or task completion. Choose indicators that relate to the business problem, and note how you currently measure them if you know. Avoid promising a result the designer or developer cannot control; instead, ask for a site and measurement plan that supports the outcome. A compact table can clarify the relationship between a goal and its evidence:
| Goal | Possible indicator | Context to provide |
|---|---|---|
| Make service information easier to find | Visits to key service pages or task testing | Which services and audiences matter most |
| Improve inquiry flow | Form starts and completed submissions | Current form path and known friction |
| Make publishing easier | Staff time or steps needed to update pages | Who publishes and how often |
| Support search discovery | Relevant organic visits and indexed pages | Existing analytics and search priorities |
Use indicators as a starting point, not a guarantee or a substitute for baseline data. If analytics are incomplete, say so and ask the respondent to recommend a practical measurement setup within the proposed scope.
Describe your audience and its needs
Explain who uses the site and what those people are trying to accomplish. Include the audiences that matter most, such as prospective clients, existing customers, job applicants, or community members, and distinguish their priorities where they differ. Share known access needs, devices, locations, language preferences, or familiarity with your services when relevant. Avoid relying on broad labels such as “everyone”; a few concrete user tasks give a respondent more useful design context. If you have customer interviews, support questions, or search data, summarize the patterns and make clear how representative they are.
Summarize the current website and its limitations
Give respondents a practical picture of the site that exists today. Include its URL, approximate number of pages, platform if known, and any features or content that must remain. Describe the limitations you have observed, such as confusing navigation, outdated information, slow updates, or inconsistent mobile layouts. Where possible, distinguish a technical problem from a content or process problem; a redesign may not fix an issue caused by unclear ownership or missing information. The Gig Resource offers free, step-by-step guides for common business and digital challenges, and the same plain-language approach can help you record what you know without pretending to diagnose what you do not.
Define the redesign scope and requirements
A website redesign brief should draw a usable boundary around the work. It does not have to specify every screen or implementation choice, but it should show what the new site must support and what is outside the project. Distinguish essential requirements from preferences, and invite respondents to flag assumptions. That balance gives them room to recommend a sound approach while keeping proposals comparable.
Identify pages, content, and content migration needs
Estimate the size and shape of the site: key page types, landing pages, articles, resource libraries, product or service pages, and any private or gated content. State whether existing copy will be kept, edited, rewritten, or replaced, and who will make that decision. Content migration includes more than moving text; images, downloads, metadata, redirects, and page relationships may need attention too. If you do not yet know the inventory, say whether you expect the respondent to audit it and include that work in the proposal. Flag content that is legally required, time-sensitive, or subject to approval.
Describe required features, integrations, and user journeys
List what visitors and staff need to do, not just the names of tools you hope to use. For example, describe the route from a service page to an inquiry, or what a staff member needs to do to publish an announcement. Note known integrations such as forms, scheduling, customer records, email communications, or analytics, and clarify which are required versus merely in use today. State who controls access to these tools and whether documentation is available. The more clearly you describe a task and its starting and ending points, the easier it is for respondents to identify functional dependencies and estimate the work.
Set design direction without prescribing every detail
Share examples of sites, layouts, or visual qualities that feel appropriate, and explain what you like about them. You might value clear typography, a calm tone, strong photography, or simple navigation; describe those preferences in terms of the experience they create. Also identify visual elements that should carry forward, such as a logo, color palette, or established brand guidance. A reference is inspiration, not an instruction to copy another site. Give the designer room to propose a direction that fits your audience and goals, and ask them to explain how their design choices support those needs.
Specify platform, accessibility, security, and performance needs
State any known platform requirements, hosting constraints, account limitations, security policies, or internal technical standards. If you have no platform preference, say that and ask respondents to explain their recommendation, maintenance implications, and any ongoing costs they expect you to manage. Describe accessibility expectations, including whether an existing site needs an audit or remediation, and ask how accessibility will be considered during design and development. Include performance expectations in practical terms, such as responsive use and efficient loading, rather than prescribing an unverified technical fix. for a technical brief, use that kind of accessible explanation to separate your must-haves from questions an independent specialist should help resolve.
Set project constraints and working expectations
A good proposal depends on more than a feature list. Respondents need to understand the calendar, budget context, available staff time, and decisions that could hold up the work. Share what is fixed and what can change, and name the people or outside services that may affect delivery. Being candid about constraints early makes it easier to compare realistic approaches and avoid misunderstandings after a contract begins.
Outline milestones, deadlines, and launch dependencies
Provide a target launch date, if one exists, and explain whether it is firm or flexible. Identify meaningful milestones such as discovery, content review, design approval, development, testing, training, and launch. Note dependencies that could affect timing, including a campaign date, internal review, legal approval, photography, or access to a third-party service. Ask respondents to provide a proposed schedule and state what they need from you at each stage. A useful timeline shows decision points and review windows, not only a final date; it gives both sides a way to notice delays before they become urgent.
Share budget context and explain what it includes
Give a budget range or explain how you intend to evaluate cost if you cannot share a number. There is no need to invent precision: identify whether the available amount covers design and development only or also content work, migration, hosting, licenses, training, and support. Ask respondents to separate one-time project costs from recurring expenses and optional work. If the work must be phased, say what needs to be included in the first release and what could wait. Clear budget context helps a respondent propose a workable scope instead of guessing at an invisible ceiling.
Clarify who will provide content, assets, and approvals
Identify who can supply copy, photos, brand files, technical access, and subject-matter decisions. Explain how many people will review work and who has final approval; multiple reviewers with unclear authority can create long feedback cycles. If your team cannot produce content by a certain date, note that constraint and ask the respondent to describe any content support they propose. The responsibilities should be realistic for the time your team can commit. Make room in the schedule for gathering materials and reviewing drafts, rather than assuming those tasks will happen instantly.
Define deliverables, ownership, and post-launch support
Name the outputs you expect, such as design files, a working website, migrated content, documentation, training, or a launch plan. Ask respondents to clarify what files and access you will receive, when ownership transfers, and whether any third-party licenses have separate terms. Post-launch support can mean different things, so specify whether you need a defined period for fixing defects, staff training, or ongoing maintenance. Ask what is included, what is excluded, and how additional support would be arranged. Written definitions make handoff less ambiguous and help you plan for the site after the project ends.
Copy and customize a website redesign RFP template
Copy this framework into a document, replace the bracketed prompts, and remove anything that does not apply. Mark unknowns as questions for the respondent rather than filling gaps with assumptions. Send the same final version to every shortlisted designer or developer.
1. Project summary
Business and website: [business name, URL and a one-sentence description of what you do.]
Why this project is happening now: [the business problem, such as an outdated offer, poor mobile experience, difficult content updates or weak enquiries.]
Project outcome: [what should be demonstrably better after launch.]
Primary audience: [who the site needs to serve and the tasks they need to complete.]
2. Scope, content and functionality
Pages and content: [page types, approximate volume, material to retain, rewrite, migrate or create.]
User journeys and features: [enquiries, bookings, ecommerce, member areas, forms, integrations or other functions.]
Design direction: [brand assets, examples you like, examples you do not, and any non-negotiables.]
Technical context: [current platform, hosting, accounts, analytics, constraints and facts still to be investigated.]
3. Delivery, budget and responsibilities
Timeline: [target launch date, milestones, fixed dates and approval windows.]
Budget context: [a range, ceiling, or the way proposals will be assessed if a figure is not being shared.]
Your team: [who supplies copy, images, approvals and access, and when they are available.]
Deliverables: [design files, build, content migration, testing, training, documentation, launch support and post-launch maintenance.]
4. What every proposal must include
- The respondent’s understanding of the problem, recommended approach and assumptions.
- Scope, deliverables, exclusions, schedule, responsibilities and key risks.
- Relevant examples of comparable work, the proposed project team and communication process.
- Itemized costs, recurring expenses, ownership terms and post-launch support options.
- Submission format, deadline, question process and the criteria you will use to make a decision.
Ask every respondent for the same information. Comparable proposals make it much easier to separate a thoughtful solution from a low initial price that leaves essential work undefined.
Compare proposals thoughtfully
A proposal is not automatically the best fit because it is polished, inexpensive, or full of technical terms. Compare how well it responds to the brief, what it assumes, and whether the proposed process fits your team’s capacity. If a respondent suggests a different approach, judge the explanation against your goals rather than rejecting it simply because it was not your first idea. Consistent evaluation makes trade-offs easier to explain to colleagues and helps you choose a suitable independent specialist when needed.
Score proposals against consistent criteria
Choose a small set of criteria before reviewing responses, and decide what matters most to the project. Possible categories include understanding of goals, completeness of scope, relevant experience, communication, timeline, cost clarity, and support. Use a simple rating scale and leave space for evidence or questions. You can assign weights if one factor is materially more important, but avoid giving false precision to subjective judgments. The point is not to turn a creative project into arithmetic; it is to apply the same lens to each response and notice where your decision relies on an assumption.
Check how clearly each response addresses your requirements
Review the proposal alongside the brief, requirement by requirement. Does it address content migration, approvals, accessibility, integration needs, and handoff, or does it only describe the visual design? Notice when an answer is explicit, when it is conditional, and when it is absent. A missing detail may simply need clarification, but it can also signal a mismatch in attention or understanding. Ask respondents to explain how their proposal addresses the outcomes you named, rather than relying on a general promise to deliver a successful redesign.
Compare scope assumptions, exclusions, and risks
Look carefully at what each estimate includes and excludes. One proposal may include content migration while another assumes your team will do it; the totals are not comparable until that difference is understood. Check assumptions about page counts, integrations, content readiness, feedback rounds, third-party services, and launch support. Ask each respondent to identify risks and explain what could change the schedule or cost. A lower initial estimate can reflect a narrower scope, so compare the work described rather than the headline number alone.
Assess relevant work, communication, and project approach
Review examples that resemble your project in audience, content complexity, or technical needs, not only examples with a similar visual style. Ask what work the proposed team member personally handled and whether the example demonstrates the type of problem you need solved. Consider how the respondent explains trade-offs, asks questions, and communicates uncertainty. A thoughtful process should make it clear how decisions are made and how your feedback will be used. You are assessing working fit as well as technical or creative ability.
Ask questions before choosing a designer or developer
A proposal leaves room for interpretation, especially when requirements are still being refined. A short conversation can reveal whether both sides understand the project in the same way and surface decisions that should be written into the agreement. Share the same core questions with finalists and record the answers. Use the discussion to test the fit of the proposed process, not to pressure a respondent into promising results they cannot responsibly guarantee.
Clarify the proposed process and decision points
Ask what happens from kickoff through launch, which decisions you will need to make, and when. Find out how discovery may change the scope, how design reviews work, and what must be approved before development proceeds. Ask what the respondent needs from your team to keep work moving. You should be able to picture the main stages and understand how uncertainty will be handled. If the explanation stays vague, request a concrete example of a typical review or approval point for a project of similar shape.
Ask who will do the work and how responsibilities are divided
Confirm who will be your main contact and who will perform design, development, content, testing, or project coordination. If work is shared among several people, ask how handoffs and decisions are managed. Find out whether the people you meet during the selection process will remain involved after work begins. Clarify which tasks stay with your staff and whether you must arrange any other specialist support. Knowing who is responsible for each part helps prevent important work from falling between roles.
Confirm access, ownership, handoff, and ongoing support
Ask what accounts, source files, credentials, documentation, and training you will receive at handoff. Confirm that the business will retain the access and ownership it needs, and identify any third-party services or license terms that apply. Discuss how the site will be maintained, who handles routine updates, and what happens if you need help after launch. If ongoing support is optional, ask how it is scoped and billed rather than assuming it comes with the project. Record the agreed terms in the contract or statement of work.
Discuss how scope changes and delays will be handled
Ask how either party can request a change, how its effect on cost and timing will be assessed, and who must approve it. Discuss what happens if content, feedback, access, or an outside integration arrives late. A clear process should explain how work pauses or priorities shift, rather than implying that every change can be absorbed without consequence. Agree on how risks will be raised and documented. These details protect the working relationship when the project meets a real-world complication.
Use a final checklist and reliable references
Before sending the RFP, read it once as a prospective respondent. Could someone understand why you need the project, what work is likely involved, and how you will make a decision? A brief should be specific enough to support a useful proposal without pretending every technical question has already been answered.
Check that the brief is complete and internally consistent
Review the problem, goals, audience, site context, scope, timeline, budget, responsibilities and proposal instructions together. Make sure the stated launch date leaves room for content and review, and that every respondent receives the same version and deadline.
Set requirements that can be evaluated
State accessibility, search-visibility, security and handoff expectations as work to be proposed and verified. A redesign does not automatically guarantee accessibility, search performance or security; ask respondents to explain the checks they will perform, the limits of their scope and who signs off the result.
Four authoritative references
- W3C Web Content Accessibility Guidelines (WCAG) 2.2 — a current, testable accessibility standard for web content.
- W3C Planning and Managing Web Accessibility — practical guidance for building accessibility into a web-production process.
- Google Search Central: Site Moves and Migrations — useful when a redesign changes URLs, page structure or redirects.
- OWASP Application Security Verification Standard — a recognised baseline for discussing web-application security requirements and verification.
Final pre-send checklist
- The business problem, audience, current site, goals and success indicators are stated.
- Scope covers content, pages, features, integrations and technical needs.
- Timeline, budget context, team responsibilities, deliverables and ownership are clear.
- Proposal format, deadline, evaluation criteria and question process are included.
- Accessibility, search visibility, security, handoff, support and change handling are addressed.
Conclusion
A clear website redesign RFP gives designers and developers a fair chance to propose work that fits your needs, while giving you a sound basis for comparing their ideas. Be specific about outcomes and constraints, transparent about what remains uncertain, and consistent in how you review each response. With those pieces in place, you can decide whether to do more preparation yourself or hire an independent specialist who understands the project and can explain a practical path forward.
Frequently Asked Questions
What is a website redesign request for proposal?
It is a document that explains the reason for a website redesign, the expected scope and constraints, and the information you want prospective designers or developers to include in their proposals. It supports a consistent selection process.
How long should a website redesign RFP be?
There is no required length. Include enough context for a respondent to understand the goals, likely work, timeline, and decision process, while removing repeated background and details that do not affect the project.
Should I choose a platform before sending the RFP?
Only if your organization has a firm platform requirement. If not, describe relevant constraints and ask respondents to explain their recommendation, including maintenance needs, limitations, and costs that may continue after launch.
Do I need to include a budget in a website redesign brief?
Sharing a range or budget context can help respondents propose an appropriate scope. If you prefer not to provide a figure, explain how proposals will be assessed and ask for itemized costs and options.
What should I ask a website designer or developer to include in a proposal?
Request their understanding of the problem, recommended approach, scope, deliverables, exclusions, schedule, responsibilities, costs, risks, relevant work, and post-launch options. Ask for the same information from each respondent.
How do I compare website redesign proposals fairly?
Use consistent criteria tied to your requirements, then check scope assumptions, exclusions, cost details, schedule, relevant experience, communication, and support. Follow up on missing or ambiguous answers before making a decision.
When should I hire an independent designer or developer?
Consider hiring when the work requires expertise or time your team does not have, or when a clear plan would help you manage risk. A well-prepared brief makes it easier to discuss fit, scope, and responsibilities before committing.