How to prepare your business for a website redesign

1. Decide why you are redesigning the website

“The website looks dated” is a useful reason to start a conversation, but too broad a starting point for a project. Try to describe what should change for your business and its audience. Is the offer hard to understand? Are contact details difficult to find? Can your team update content without help?

Choose your main goals and put them in order. A website does not always need to sell, recruit, serve customers and build an extensive knowledge base all at once. A shared priority makes design proposals easier to assess later.

• What currently makes the website difficult to use?
• What should a visitor do: explore your services, send an enquiry or find a document?
• How will you judge whether the new website does its job?

2. Check what is worth keeping

A redesign does not mean starting everything from scratch. Review the current website and gather what is still useful: descriptions, photographs, documents, forms or clearly organised parts of your offer.

If you have visitor data or records of customer enquiries, use them in the discussion. Feedback from people who manage the site regularly or answer questions about your services is useful too. Visual preferences alone do not tell the whole story.

A simple content review

• Keep — information that is current and useful.
• Improve — content that needs shortening, updating or reorganising.
• Remove — outdated or unnecessary material.
• Add — information that is currently missing.

Collect existing page URLs and details of your domain, hosting and CMS. At this stage, a list and the name of the person who manages access are enough. Do not include passwords in the project brief.

3. Describe your audiences and their tasks

Think about the main groups using your website. A prospective customer, an existing partner and a job applicant need different information. Identifying those differences helps you plan navigation and content order.

Write a short scenario for each group: why they visit, what they need and what their next step should be. Elaborate profiles are not necessary. A few real questions from your audience can be more useful than a long list of general traits.

Include the people working inside your company. Who adds products, publishes news or updates service descriptions? Their everyday tasks matter when planning the content management system.

4. Gather materials and agree responsibilities

Even a polished visual design cannot replace ready-to-use content. Agree what you already have, what needs preparing and who is responsible for producing and approving it. A missing decision-maker can hold up work just as effectively as missing photographs.

• Your current offer and list of services or products.
• Copy, photography, brand assets and downloads.
• Language versions and the person responsible for translations.
• People contributing feedback and the person approving key decisions.

The materials do not have to be final immediately. You should, however, know when they will be available and who will review them. Check your rights to use photographs and other assets too. Create one organised place for files and decisions instead of scattering them across messages.

How should you collect project feedback?

Appoint one person to consolidate the team’s feedback before sending it to the studio. Explain the problem behind each comment: “customers cannot see the delivery time” says more than “make this block bigger”. New ideas can still be considered after a stage is approved, but their impact on content, design, development and timing needs assessing. Record decisions and the items deferred to a later stage.

5. Separate launch requirements from later stages

List the features you expect and explain who needs each one and why. “Product search for customers who know the product code” says more than “search”. Describe forms, catalogues, partner areas and additional languages in the same way.

Split the list into what is needed for launch and what can be considered later. Include connections to other systems if the website will receive or send data. Not every feature needs to be part of the first release.

This gives you a basis for planning a website or portal. If the solution primarily supports processes and user tasks, it is worth discussing a web application too. Choosing a CMS does not, on its own, define what the project needs.

6. Set a budget range and timeline

An indicative budget helps you discuss a realistic scope and delivery options. You do not need to know the cost of every feature. The studio needs to understand the available budget and which elements matter most to your company.

If a particular event determines the deadline, explain this at the outset. Separate fixed dates from preferred ones. Allow time for content, decisions, testing and launch preparation as well as design and development.

7. Plan the launch and ongoing support

The new website needs to be ready to take over from the old one. Agree content migration, handling of old URLs, form checks and key user journeys with the studio. Identify the people who will approve the website and use it day to day.

Check which pages appear in Google and receive links from other sites. Keep their URLs or plan redirects to equivalent new content. Save your Search Console data before launch; it will help you compare performance and identify broken URLs afterwards. Do not redirect every removed page to the homepage.

Discuss updates, backups and how to request changes before publication. The scope of support and development should match the website and available infrastructure. Different websites need different support arrangements.

8. Prepare a short brief for the first conversation

Your findings do not have to become a detailed specification. Start with a document that explains your company’s situation and main expectations.

1. The purpose of the redesign and problems with the current website.
2. Your main audiences and their tasks.
3. Content and features needed for launch.
4. Available materials, decision-makers and dependencies.
5. An indicative budget, timeline and ideas for future development.

If some questions remain open, say so. A useful first conversation can help clarify them. Tell us about your planned redesign and we will agree where to begin.