Digital products ·
A website redesign begins with deciding what to keep
A request to “refresh the website” can conceal very different jobs: change its visual language, rebuild its journeys or replace its technical foundation. Before drawing screens, find out which parts still work.
Name the reason for change
A website rarely needs a redesign simply because it is a few years old. Age does not explain the problem. The real cause may be new positioning, weak conversion, difficult editing, accumulated pages, poor performance or a product that no longer fits the original structure.
Describe the problem through an observable action. A visitor cannot find the relevant service; a mobile form loses enquiries; editors are afraid to change a page; the team cannot add a section without a developer. This gives the project a measurable outcome and prevents it from collapsing into a change of colour.
One request, three possible scales
A visual refresh keeps the structure and primary journeys while changing typography, imagery, layout and components. A structural redesign changes navigation, content and user flows. A rebuild also replaces architecture, content management, integrations or the publishing model.
The scale should not be chosen by how attractive a mock-up looks. If the current platform is dependable and the problem lies in language and presentation, migration adds unnecessary risk. If every change requires a workaround, a new interface on the same foundation simply wraps technical debt in a cleaner surface.
An audit reveals existing value
Before designing, examine four layers: business goals, visitor behaviour, content quality and technical condition. Analytics reveal entry pages and broken journeys. Conversations with the team expose manual work. A content inventory finds duplication and gaps. A technical audit identifies constraints in performance, accessibility and maintenance.
Record what works as carefully as what fails. A page may look dated while consistently attracting the right audience. An awkward opening line may still explain a difficult service well. A redesign should preserve proven value, or the team can lose a working element without noticing.
Content defines the frame
A new grid cannot repair a site whose sections reflect the company’s internal structure rather than visitors’ questions. Define audiences, decisions, evidence and the next action first. From that comes the page map, and only then the interface.
Real copy is more useful than placeholders. A long headline, comparison table, list of conditions and legal qualification immediately test the composition. When content is postponed, the layout starts dictating meaning: important ideas are cut to fit, while necessary pages appear too late.
Migration is part of the redesign
If URLs, platform or structure change, plan redirects, metadata, canonical pages, the sitemap and analytics migration in advance. Otherwise the new site may lose accumulated search visibility and the team may lose its ability to compare behaviour before and after launch. This is part of the design decision, not a technical clean-up at the end.
Forms, CRM connections, email, payments and customer accounts require the same treatment. Test them as a chain: visitor action, data transfer, notification, system record and recovery after failure. An elegant home page cannot compensate for an enquiry that disappears between the form and the sales team.
A prototype lowers the cost of error
Before complete production, test the new structure through a few essential journeys. An interactive prototype shows whether a person understands the structure, can see the next step and can finish the task. It also helps the team agree on content while changes are still inexpensive.
Do not test the home page alone. Follow a journey from a search result to an internal page, on to a service, through the form and back from an error. If the proposal survives those transitions, its visual layer has a sound foundation.
Choosing redesign or rebuild
Redesign is suitable when the platform remains maintainable, data and integrations work, and the main changes concern content, structure and interface. A rebuild makes sense when technology blocks development, security and performance cannot be repaired locally, or a new product model demands a different architecture.
I begin this work with an initial review and a technical audit, separating what deserves to survive from what prevents the next stage. That evidence defines the website development scope, prototype and migration plan. The decision becomes testable before the team commits to full production.
Start with the website's purpose
If you are planning a website or rethinking one, we can begin with its role in your business, its structure and the visitor's path to an enquiry.