RFP for Website Redesign: A Global Brand Framework

An RFP works when it gives agencies a problem they can solve and a boundary they can price. Start with the decision behind the redesign: are you entering new markets, repositioning the brand, improving recruitment, supporting sales, consolidating regional sites, or replacing a platform that has become hard to govern?

Write the current problem in observable terms. “Our website feels dated” is a weak brief. “Brand teams in five markets publish the same product story in different ways, and no owner can approve a global change” gives an agency something to investigate.

Add the business measures that matter. They might include qualified inquiries, applications started, product discovery, recruitment actions, content publishing time, or the share of pages that meet accessibility and performance targets. Do not promise a lift you have not measured. Give bidders the baseline if you have it, and label unknowns as unknowns.

Your RFP does not need a final budget, but it needs a commercial frame. State the budget range or the funding bands you are comparing, what must fit inside the fee, and what should appear as an optional phase. Ask agencies to show assumptions instead of hiding scope inside a single total.

Separate the work into useful cost units:

• discovery, research and content strategy
• brand translation, art direction and design system work
• information architecture, UX and interactive prototyping
• content modelling, migration and localization
• front-end and back-end implementation
• integrations, analytics, accessibility and quality assurance
• launch, training, support and ongoing optimization

Give bidders a target launch window, decision dates, blackout periods, market dependencies and the date when the selected team can start. A global redesign often slips because legal review, translation, product data or regional approvals arrive late. Make those dependencies part of the response, not a surprise after award.

Describe the digital estate before you describe the new homepage. List domains, subdomains, regional sites, languages, templates, content volumes, authenticated areas, campaign pages and third-party experiences. Identify what is in scope, what is out of scope, and what may become an option after discovery.

Ask for a proposed scope map with three layers:

1. The shared global foundation: brand rules, design tokens, components, content models, governance and technical standards.
2. The market layer: local content, regulatory needs, translations, campaigns and market-specific journeys.
3. The experiment layer: interactive stories, prototypes, campaign modules and features that need a separate decision.

This keeps a global site from becoming either one rigid template or a collection of unrelated local sites. It also lets you compare proposals on the same boundaries.

Include the content reality. Say who owns existing copy, imagery, video, product data and translation memories. Ask the agency to identify what should be kept, rewritten, consolidated, redirected or retired. A redesign that ignores content is only a visual refresh with a migration problem waiting behind it.

An interactive prototype should show the experience at the moments where a static comp cannot answer the question. Ask for a realistic path through the global navigation, a market switch, a core conversion journey, a long-form editorial page, and at least one motion or immersive interaction if the concept depends on it.

Define what the prototype must expose:

• the hierarchy and purpose of each key screen
• responsive behavior across narrow and wide viewports
• keyboard focus, reduced motion and error states
• content changes between markets and languages
• loading, empty and failure states
• the relationship between editorial content and conversion actions

Do not ask for polished screens alone. Ask bidders to explain what they are testing, what evidence would change the direction, and which parts are illustrative rather than production-ready. The prototype is a decision tool. It should help your team reject a beautiful idea that cannot scale before engineering begins.

State the constraints first: hosting, security review, identity, analytics, search, commerce, CRM, product information, localization, consent, deployment and ownership. Then ask for a recommended architecture with alternatives and tradeoffs.

A headless stack separates the content management interface from the presentation layer. That can help a global team reuse structured content across markets and digital surfaces, but it also creates more integration and governance work. Do not choose headless because it sounds modern. Ask the bidder to show why the separation fits your publishing model, team skills, release process and budget.

Require the response to name:

• the CMS and its role permissions, workflows, preview and localization model
• the front-end framework and rendering approach
• the content model and migration method
• hosting, environments, deployment and rollback
• search, analytics, consent and experiment integrations
• API ownership, documentation and exit options
• security controls, dependency management and incident responsibilities
• performance budgets and how field data will be monitored

For performance, use measurable acceptance criteria. Google’s Core Web Vitals guidance defines LCP for loading, INP for interactivity and CLS for visual stability. The current “good” thresholds are LCP within 2.5 seconds, INP at or below 200 milliseconds and CLS at or below 0.1, measured at the 75th percentile across mobile and desktop. Treat those as engineering targets, not a promise that every page will always pass.

Put accessibility in the scope, prototype, design review and launch gate. The W3C WCAG 2.2 Recommendation was published on December 12, 2024 and provides testable success criteria for web content. Ask bidders which conformance level they target, which criteria need manual testing, and how they will handle content, components and third-party tools.

Your RFP should require evidence for keyboard operation, focus visibility, contrast, text alternatives, headings, forms, error handling, motion preferences, zoom and responsive reflow. Ask for an accessibility test plan that includes assistive technology and human review. Automated scans are useful, but they cannot confirm every interaction or content decision.

If the concept uses custom widgets, ask how semantics will reach assistive technology. The WAI-ARIA 1.2 specification says ARIA supplements native language semantics rather than replacing them. That gives your team a practical test: the bidder should use native HTML where it already expresses the interaction, and use ARIA to fill genuine gaps.

Require milestones with inputs, outputs, owners and approval rules. A useful plan usually moves from alignment and research to architecture, prototype, design system, implementation, migration, quality assurance and launch. The exact sequence can change, but every handoff should have a decision attached to it.

Ask each agency to show how it will manage:

• executive direction versus day-to-day product decisions
• global governance versus local autonomy
• content approvals and translation lead times
• design and development running together
• accessibility and performance checks before launch
• redirects, analytics continuity and search preservation
• training, documentation and post-launch ownership

Request the proposed team by name, including time allocation and location. Ask who makes design decisions, who owns architecture, who leads content and who is accountable when a dependency blocks the schedule. A large agency logo does not tell you who will do the work.

Share the evaluation categories and weights in the RFP. Weight the things that can change the outcome, not the easiest things to count.

Tell evaluators how to score each category. A five-point scale is only useful when the anchors are concrete. For example, a top score for technical approach could require a diagram, a migration example, a rollback path and an explanation of what the client can operate after handoff.

Ask for a short response format. Require the same case-study fields from every bidder: client context, problem, contribution, deliverables, team, constraints and result. Ask for one relevant example of global governance and one example where the agency changed direction after testing. This makes the comparison fairer than rewarding the longest deck.

End the RFP with the structure you want returned. It should include:

1. Executive summary and understanding of the brief.
2. Proposed approach, workstreams and decisions.
3. Prototype plan and research questions.
4. Technology, content and migration approach.
5. Accessibility, performance, security and quality plan.
6. Team, roles, location and availability.
7. Timeline, milestones, dependencies and client inputs.
8. Pricing, assumptions, options and payment schedule.
9. Relevant work and references.
10. Risks, open questions and contract exceptions.

Set a word limit, file format, deadline, question period, presentation format and contact method. State how late questions will be handled. If you want an NDA, procurement form or security questionnaire, include it before the response deadline.

• W3C WCAG 2.2: accessibility criteria, conformance model and publication date.
• web.dev Core Web Vitals: performance metrics, thresholds and field measurement.
• WAI-ARIA 1.2: semantics for custom interactive components.
• NIST Cybersecurity Framework: a reference for discussing security risk and organizational responsibilities.