Questions to ask before commissioning a website redesign
A redesign does more than replace an outdated appearance. It needs to retain what works, address identified difficulties and organise the transition to the new site. These questions help you prepare the initial review, decisions and responsibilities before design starts, while keeping your visitors and team’s actual uses in view.

Before commissioning a website redesign, ask a starting question: what genuinely needs to change, and what deserves to remain? An ageing interface may contain useful pages, sought-after information or working habits that should not disappear inadvertently.
Preparation separates visual improvement, changes to the offer and operational transition. It also clarifies who decides and how the new site will be checked. The following questions help you hold a concrete discussion before early designs turn uncertain assumptions into an apparently settled plan.
Why redesign now?
Ask your team to name observed difficulties. Has the offer changed? Are recent projects hard to publish? Do visitors repeatedly ask a question that should already be answered online? These facts are a better starting point than a broad impression that the site is dated.
Group reasons into image, content, operation and organisation. New art direction may improve perception, but does not independently fix misrouted forms or poorly explained services. The project may need to address several dimensions; identify them separately.
Then choose a few outcomes that can be observed at delivery: a clearer offer structure, updatable projects and an understandable enquiry journey. Avoid defining success through a guaranteed number of customers. The site contributes to business relationships without controlling every factor that shapes them.
What do we know about the current site?
Collect existing pages, available content and the tools used for operation. Identify the people who understand incoming enquiries and administration difficulties. Their experience complements a visual review.
Where usable browsing data exists, let it guide questions without assuming it explains intentions by itself. A lightly visited page may be secondary, hard to reach or simply new. Distinguish the observation from your interpretation.
Keep precise examples: a difficult menu, a page with inaccurate copy or an enquiry sent to the wrong person. They demonstrate the problem without asking the agency to guess the site’s history. Record when an issue occurs as well, so an occasional difficulty is not mistaken for the behaviour of every visitor.
Which pages and information should remain?
Request a shared inventory with a decision for each group: retain, update, merge or remove. The appropriate person should approve business facts, especially services, operating areas and contact details.
An old page may still contain useful explanations. Its appearance should not alone determine its removal. Conversely, automatically copying everything can preserve outdated offers and repetition.
As a fictional illustration, an architect might retain the description of an important project while replacing its opening photograph and clarifying the context. There would be no need to delete that page merely because the new portfolio uses a different grid.
Ask for a reason beside each major removal. It might be an unavailable service, obsolete information or duplication addressed elsewhere. The reason helps content owners understand what the redesign changes, rather than discovering missing material only after publication.
Will page addresses change?
Ask which addresses will remain and which need to change. If some move, identify who maps old pages to relevant destinations. Google recommends this mapping for URL changes. Google guidance on changing website addresses.
The decision also concerns links already shared through email, documents and campaigns. Gather addresses used in those materials rather than looking only at the main navigation.
Do not leave this until the final day. New page choices may depend on content that must be merged or rewritten. Editorial decisions need to be coordinated with address changes, so someone following an old link reaches an appropriate answer.
What happens to enquiries during the transition?
Describe how visitors contact you today and who receives each request. There may be several routes: a form, a reservation journey, an external tool or direct contact details. Each needs an identified destination in the new arrangement.
Ask how submissions will be checked before and after publication. A form that looks correct is insufficient if the message never reaches the right team. Name the person performing the test and the person confirming receipt.
If data must be transferred, identify exactly what is involved and who is responsible. Do not assume everything in the former administration will automatically move. Scope should distinguish public content, enquiries and operating settings.
Who holds the necessary access?
List accounts connected to the domain, hosting, content and integrated tools. Identify their holders and the person able to supply appropriate access. A redesign can be delayed by an administrative dependency discovered late.
This does not mean sharing every password indiscriminately. Arrange useful access with the relevant account holders according to each service’s possibilities. Your company should know who may intervene and how that authorisation ends when no longer required.
Ask which elements of the existing site can be retrieved. Some content may export readily; other material may need organised recovery. Check this before treating complete transfer as an established promise.
Which structure will better answer customers’ needs?
A redesign provides a chance to reorganise pages, but each change should have a purpose. Ask which visitor questions guide the proposed structure and how services will be distinguished.
A shorter menu may simplify discovery if important information remains accessible. An additional page may help when it addresses a genuinely separate need. The number of categories is not an objective in itself.
Give someone unfamiliar with the project a scenario: understand a service, find a related project and request a conversation. Their hesitation may reveal wording or grouping that should be reconsidered before development.
Discuss repeat visits as well as discovery. Someone returning to find contact details has a different need from a prospect exploring the brand for the first time. The new structure should account for the ordinary uses your team identifies, without forcing everyone through the same presentation sequence.
Will new content be ready in time?
For each page, identify existing material, required revisions and new production. Assign writing, photography and approval. A design filled with temporary copy does not mean a page is ready to publish.
If several languages are planned, organise work around reviewed versions. Pages should not diverge on essentials such as available services or how enquiries work. Identify who will maintain that consistency after launch.
Prepare a realistic delivery schedule. Photography of an unavailable location or copy needing several opinions can become an important dependency. Make it visible so you can decide whether the first version should wait or use an already workable alternative.
How will design, animation and operation be approved?
Ask which deliverable supports each decision. Structure may be assessed in a page plan, identity in a visual proposal and scrolling behaviour in an appropriate demonstration. No single format answers every question.
For animation, examine its purpose and the transition into the remaining content. Ask how the page remains understandable for visitors who do not want a long sequence. Storytelling should support the offer rather than make it more distant.
Organise feedback: one person consolidates it, facts are checked by the relevant specialists, and changes to earlier decisions are identified. This makes the conversation easier to follow and allows consequences to be evaluated before additional work begins.
When can the site launch, and who decides?
Publication should depend on explicit conditions: accepted content, checked functions and known follow-up responsibilities. A commercial deadline can guide scheduling, but does not replace those checks.
Ask who gives final approval and how remaining issues are classified. An error preventing contact and a preference about photography should not be treated as equivalent obstacles.
Clarify the period immediately afterwards. Who observes the site, receives reports and requests corrections? A transition must be planned through its first uses, rather than only to the instant a new appearance becomes visible.
Give the team a way to record an issue precisely: affected page, attempted action and observed result. This avoids describing every problem as “the new site does not work” and makes follow-up discussions more useful.
What will your team manage afterwards?
A redesign should improve daily work as well as presentation. Request a demonstration of real tasks: adding a project, replacing an image or changing a service page. Involve the person who will perform them.
Clarify the difference between a routine update and a change requiring a revised template. Independence can be valuable without meaning that any structure can be changed without assistance.
Document maintenance and content responsibilities. A site can become inaccurate if nobody knows who removes an old offer or completes a project entry. Launch is a handover, rather than the end of editorial activity.
A summary to share with the agency
Prepare a short document bringing together observed difficulties, important content, existing journeys, identified access and open decisions. Add launch priorities and your team’s availability.
The document does not need every technical answer. It should make your situation understandable and prevent design from starting on guesses. To prepare the transition with MV Design, share what you want to retain and the uses you want to improve. That provides a basis for discussing a redesign grounded in specific needs.