A website can look dated and still do its job. It can also look impressive while making everyday tasks difficult. Before changing the design, identify the gap between what visitors need and what the current website lets them do. A redesign becomes easier to judge when it is solving a named problem.

Describe the friction, not just the style

Replace “we need something modern” with observations. Visitors cannot find the booking link. Product information is hard to compare. The mobile menu covers the page. The team cannot update a service without help. These are problems a project can address and test.

If you have permission to use analytics or customer feedback, look for patterns. If you do not, watch a few people attempt a common task and note where they hesitate. Treat a small set of observations as a starting hypothesis rather than proof about every visitor.

Keep what already works

Inventory the pages, downloads, and links people depend on. Identify useful explanations and content that is still accurate. A redesign does not require discarding every sentence or changing every URL.

When an address must change, create a deliberate mapping from the old page to its closest relevant replacement. Avoid sending every old link to the homepage. Search visibility is not guaranteed, but preserving useful destinations prevents needless dead ends for existing visitors.

Prototype the important journeys

Pick two or three tasks and work through them before styling the entire site. For a service business, try choosing a service, checking suitability, and making contact. For a store, test product selection, cart editing, and the information required at checkout.

Use realistic text and product details. A prototype filled with short placeholder labels can hide problems that appear with long names, different languages, or missing information. Include empty, error, and success states in the discussion.

Launch with a way to learn

Check the finished journeys with a keyboard and on a real phone. Verify forms, redirects, page titles, and links. Make sure someone owns the tasks that continue after launch: responding to messages, updating content, and checking unexpected failures.

Return to the original problems once people are using the site. Did the booking route become easier to find? Can the team make routine updates? The useful measure of a redesign is how well it supports those tasks, not simply whether the old and new homepages look different.

Before you build

  • Write down three specific problems.
  • Keep an inventory of useful pages and URLs.
  • Test realistic journeys and error states.
  • Review the original problems after launch.
Make it yours ↗