The website redesign checklist that starts with your business

Define the change you want to make

Begin with a description of the current problem in ordinary language. A confusing service catalog, a difficult mobile inquiry, and an outdated editing process are different problems. They may require different work even when all three appear on the same website. Describe what happens today and what should happen instead. This gives the project a useful direction before anyone chooses a framework or a homepage composition.

Separate essential outcomes from ideas worth exploring. A company might need clearer qualification questions immediately but only be considering a future customer portal. Recording that difference prevents speculative features from quietly becoming launch requirements. It also helps a designer leave room for later expansion without building an entire application before the business understands how it will be used.

Choose a few journeys that matter enough to review throughout the project. Examples include finding a relevant service, understanding whether the company is a fit, completing an inquiry, and receiving an understandable next step. Describe those journeys from the visitor's perspective. Internal department names are often less helpful than the questions people bring with them.

Inventory the website before replacing it

Create an inventory of existing URLs, important downloadable resources, useful search destinations, forms, and external links. Add a short explanation of each page's purpose. When analytics or search data are available, use them to add context, but do not assume a page has no value simply because its traffic is modest. A detailed support page might matter to a small group of valuable customers.

Give each existing page a decision: retain, improve, combine, or retire. When a destination changes, identify the most relevant replacement. Mapping everything to the homepage is rarely an informative experience for someone following a specific old link. The inventory becomes the working record for content migration and redirect implementation.

Include the less visible material. Thank-you states, confirmation messages, error pages, document links, legal pages, and automated emails are easy to overlook because they are not part of a polished design presentation. They still shape the actual customer experience. Record who can approve each item so these details do not become late surprises.

Prepare content around customer decisions

For each primary page, write down the questions it should answer. A service page may need to explain the problem addressed, the situations where it helps, the shape of an engagement, relevant limitations, and a useful next action. A general list of adjectives does not replace those details. Good content makes the interface more useful before visual styling adds personality.

Identify the evidence you can publish honestly. Existing testimonials, accurate product information, a clear explanation of the process, and genuine examples can all help. Do not fill empty sections with invented client logos or results. If evidence is limited, a specific explanation of the work is more credible than a decorative claim that cannot be supported.

Decide how the content will be maintained. If the team regularly adds service guides, a structured publishing workflow may be useful. If the website changes infrequently, a simpler editing model may be sufficient. The right content system is the one that fits the actual update process, including review and ownership, rather than the one with the longest feature list.

Connect the inquiry to the operation

Follow a submission beyond the form. Determine which information should enter a CRM, who reviews it, how duplicate requests are handled, and what the visitor is told. A redesigned form can create more confusion if its fields do not match the process used by the team receiving it. Agree the handoff before implementing the interface.

Be explicit about what happens when delivery fails. If the website cannot confirm a successful submission, its message should not claim otherwise. A visible retry path or direct contact option gives the visitor a way forward. Confirmation messages should explain the immediate next step without making an unapproved promise about response times.

Consider the information required at this stage. An introductory inquiry usually does not need every detail that a full project specification would contain. Ask enough to start a useful conversation, and let later questions follow the visitor's context. Every field should have an understandable purpose for both the customer and the person reviewing the request.

Review real devices and awkward states

Review the actual site on a narrow phone, a tablet, and a desktop. Check readable type, wrapping headings, menu access, form labels, keyboard navigation, and content that extends beyond the screen. A desktop screenshot is useful design evidence, but it does not demonstrate that the full journey works under different conditions.

Test missing information and unexpected paths as well as successful ones. Try an invalid address, an empty required field, a long service name, an unavailable external tool, and a returning visitor following an older link. These checks reveal where the interface needs better explanations or more resilient behavior.

Review the website with reduced motion enabled. Decorative animation should support the experience rather than become a prerequisite for understanding it. The same principle applies when a visitor uses a keyboard or assistive technology. Build these considerations into review points while the components can still be changed deliberately.

Make launch and ownership concrete

A launch plan should identify the release owner, the intended domain, the content approval state, the redirect plan, and a way to reverse a problematic release. It should also state which settings belong to the business, including domain access, analytics, hosting, and any external services. A finished website should not depend on an undocumented personal account.

After release, check the published URLs, forms, navigation, and important integrations. Observe actual search and visitor signals over time rather than assuming that a new appearance guarantees an improvement. Keep a short record of the changes so later decisions can be compared with the intended outcomes.

• Agree the customer journeys the redesign must improve.
• Assign a decision and destination to every important existing URL.
• Gather accurate copy, real feedback, and approved business information.
• Define form delivery, review ownership, and failure messages.
• Review phone layouts, keyboard access, and reduced-motion behavior.
• Document release access, recovery, and ongoing maintenance responsibilities.