20 Questions to Ask When Choosing a Corporate Web Design Agency
Procurement
Sep 2026
11 min read

20 Questions to Ask When Choosing a Corporate Web Design Agency

A procurement-ready shortlist checklist: twenty questions across strategy, research, information architecture, design systems, engineering, governance and post-launch evolution — with what a strong answer looks like.

Most corporate website RFPs ask what an agency has done. The questions that predict the outcome ask how they work when the project gets difficult. These twenty questions are written to be used directly in a shortlist meeting or an RFP annex: each one states why it matters and what a strong answer sounds like. Ask all twenty of every finalist and score the answers side by side.

Strategy and discovery — question 1: What business outcome should this website change, and how would we know? Why it matters: a site without a defined change becomes a redesign for its own sake. Strong answer: the agency reframes your brief into two or three measurable outcomes and admits which ones the website alone cannot move.

Question 2: What would make you advise us not to run this project now? Why it matters: partners who only agree are selling capacity, not judgement. Strong answer: concrete preconditions — unresolved content ownership, a pending brand change, an ERP migration mid-flight.

Question 3: How do you scope, and what happens when scope changes? Why it matters: most disputes are scope disputes. Strong answer: a described change process with pricing logic, plus an example of a change they absorbed and one they charged for, and why.

Users and research — question 4: With no research budget, what would you still insist on doing? Why it matters: it reveals whether research is a habit or a line item. Strong answer: a proportionate minimum — stakeholder interviews, analytics and search-log review, support-ticket themes, a handful of moderated sessions.

Question 5: Show us a project where research changed the plan. Why it matters: research that never overturns an assumption was decoration. Strong answer: a specific reversal, what it cost to change course, and what it saved.

Question 6: How do you handle the internal audiences — the people who publish, approve and maintain? Why it matters: corporate sites fail through their editors more often than their visitors. Strong answer: editor interviews, publishing-workflow design, and training as part of scope.

Information architecture and content — question 7: How will the structure hold when a new business line or country is added? Why it matters: enterprise IA is judged in year three. Strong answer: content types, ownership mapping, URL strategy, and a stated growth path.

Question 8: Who writes the content, and what happens if it is late? Why it matters: content is the most common cause of launch slippage. Strong answer: an explicit content plan with owners, dates, and a defined behaviour when material is missing.

Question 9: How do you migrate existing URLs without losing search equity? Why it matters: a clean redesign can erase years of accumulated visibility overnight. Strong answer: an inventory-driven redirect map, canonical strategy, and post-launch monitoring, described as standard rather than optional.

Question 10: How will the site be structured so AI answer engines describe us accurately? Why it matters: buyers now meet summaries of your company before they meet your homepage. Strong answer: entity clarity, structured data, consistent external profiles and answer-shaped content — with no guarantee attached to any of it.

Design systems and accessibility — question 11: Will we receive a design system, and in what form? Why it matters: a design file is not a system. Strong answer: tokens and coded components under shared naming, with documentation and contribution rules.

Question 12: Who governs the design system after launch, and how does a change reach production? Why it matters: ungoverned systems fragment within months. Strong answer: a named owner, a review path, and a versioning approach.

Question 13: Which accessibility standard and level do you design to, and how do you verify it? Why it matters: accessibility retrofitted at the end is expensive and shallow. Strong answer: a named target such as WCAG 2.2 AA, applied during design, verified with automated checks plus keyboard and screen-reader testing.

Question 14: Show us a project where accessibility changed a design decision. Why it matters: it separates policy from practice. Strong answer: a specific trade-off — a colour system, a form pattern, a navigation model — and how it was resolved.

Engineering, CMS and integrations — question 15: Who builds it, and are they the people we meet today? Why it matters: pitch teams and delivery teams are often different. Strong answer: named roles, their availability, and how continuity is protected if someone leaves.

Question 16: How will our editors work in the CMS, and what can they change without you? Why it matters: dependence on the agency for routine edits becomes a permanent cost. Strong answer: a demo of an editing workflow, a clear boundary between editable content and governed structure, and training as part of delivery.

Question 17: How do you integrate with our existing systems, and who owns the interface contract? Why it matters: enterprise sites rarely stand alone — CRM, ERP, identity, payment, document and data services all show up. Strong answer: prior integration examples, an explicit contract and error-handling model, and an honest account of what their side cannot control.

QA, governance and ownership — question 18: What is your definition of done, and who signs it? Why it matters: undefined completion is how projects drift. Strong answer: written acceptance criteria covering functionality, performance, accessibility and content, with a named approver on both sides.

Question 19: Who owns the code, the design files, the content and the accounts at the end? Why it matters: ownership ambiguity is leverage, and it usually surfaces when you want to leave. Strong answer: unambiguous client ownership, documented handover, and no dependency on agency-held accounts.

Post-launch evolution — question 20: What does month eighteen look like? Why it matters: a corporate website is an operated asset, not a delivery. Strong answer: a described operating model — release rhythm, prioritisation, monitoring, accessibility and performance review, and a named client relationship that has actually run that long.

How to score it. Weight the twenty questions before the meetings, mark each answer one to five, and note where an agency gave you an example rather than a description. Examples are the signal. Presentation quality is not — the most polished pitch in the room is frequently the one with the least operational detail behind it.

One caution about references. Ask each finalist for a client who has worked with them for more than three years, and a client whose project did not go smoothly. The second request is the more informative of the two, and a partner who can discuss a difficult engagement candidly is usually the one who will handle yours well.

Have a project in mind?