Web development

Web Redesign: How to Decide What to Change and What to Keep

Your website can still be published and, even so, leave doubts: it costs to explain the services, the form receives useless queries, updating a page depends on too many steps or the appearance no longer represents the company. In this situation, the decision is not simply "redesign or not redesign". You must decide si just adjust what you already have, if you need to reorganize specific parts or if the problem requires re-make the base.

By finishing this article you can compare these alternatives and define a web redesign according to your goal, existing content, the necessary functions and the risk you can take during the change.

The decision: what really needs to change?

A web redesign can pursue very different objectives. For example, better present a new line of services, make it easier for a person to find the information he needs, simplify content editing or replace functions that no longer fit the business's operations.

Before choosing a solution, separate three layers:

-OBJECTIVE: what should improve for the company or for those who visit the web. -Scope: which pages, contents, route, forms or functions should be reviewed. -Solution: how the technical and visual change will be implemented.

This separation avoids deciding for appearance. A visually old website may need only a design update; a recent website may require further review if it confuses services, does not allow for content management, or depends on hard-to-maintain tools.

Three alternatives for a web redesign

The following three options respond to different needs. None are superior by default.

1. Visual update on existing website

This alternative retains the structure, main contents and current technology. Elements such as the visual identity applied to the web, typography, hierarchy of blocks, images, calls to action and adaptation to small screens are reviewed.

It fits when visitors can already understand the offer and complete the main action, but presentation needs greater coherence or clarity.

Its advantage is that it limits the change to what is necessary. Its counterpart is clear: it does not solve a confusing information architecture or remove technical limits from the existing platform. Changing the facade does not correct a function that is not well-defined.

2. Partial redesign with structure and route review

Here, usable elements are kept, but important pages, order of information, messages, forms and how to manage certain content are reviewed selectively. You can include removing sections that no longer provide, creating clearer service pages or redefining what happens after you send a query.

It is an intermediate option if the business has changed, the website has grown without a common criterion or the relevant pages do not guide well towards the next step. It also allows prioritizing: first you act on the essential, and you reserve the rest for a later phase.

The main risk is to treat it as a small change when it affects many dependencies. If URLs, forms, content, analytics or integrations are modified, those elements must be identified before posting changes.

3. Complete Web Reconstruction

A reconstruction again raises the structure, the design and, if necessary, the technical basis. It does not mean that everything should be discarded: useful content, commercial knowledge and certain assets can be preserved. What changes is that the website stops evolving on its previous organization.

It usually makes sense when current technology prevents reasonable changes, there are functions with their own rules, it requires different internal management or patch accumulation makes it difficult to maintain the site. It may also be necessary if the scope requires integrating tools, user profiles or processes that a standard structure does not cover well.

In exchange for greater scope for ordering the project, it requires more definition. It is appropriate to inventory content, accesses, forms, data, integrations and decisions about URLs before replacing the previous site.

Matrix for comparing alternatives

Visual updatePartial redesignComplete reconstruction
Problem that best solvesImage and readabilityStructure, messages and specific pathsStructural, technical or functional limits
Elements that are retainedAlmost all the current websiteParts that remain usefulOnly assets that are decided to reuse
Change in contentsSetting and spot reviewReordering, rewriting or selective creationInventory, debugging, migration and new organization
Current base dependencyAltaMediaLow, after change
Risk of omittingdependencies Minor, althoughMedium should be reviewed: relevant pages and streams can be changedHigh if no migration, access and removal from the previous system is planned
Evolution Capacity Conditioned by the existing websiteImprovement in theintervention areas Depends on how the new

The matrix guides the conversation, but does not replace the review of the specific case. Two companies can ask for "a more modern website" and need very different scopes: one may require only visual order; another may be describing a content problem, forms or internal management.

When to choose each option

Choose a visual update when:

  • The offer, pages and forms continue to respond to what you need.
  • You can update the content without relevant friction.
  • The problem is focused on presentation, consistency or mobile reading.
  • You don't need to change rules, integrations, or how to manage the site.

Choose a partial design when:

  • Services, public services or business priorities have changed.
  • Some important pages have become messy or hard to understand.
  • You want to improve a specific route, such as the request for information or the booking of a meeting.
  • There are valid parts that are not worth replacing, but you need to intervene on which conditions the objective.

Choose a complete reconstruction when:

  • The current website limits changes needed for the business.
  • Functions require rules, data or integrations that are not well resolved.
  • Maintenance has become a succession of exceptions and patches.
  • The above structure no longer reflects how you work or how you want a person to understand your offer.

In all three cases, it first defines the main action you expect from the web visitor. Without that criterion, it is easy to discuss styles, sections or tools without knowing what decision to support the redesign.

Limit cases: situations requiring more care

Some decisions do not fit well in a quick choice between ‘retouching’ and ‘redo’.

A website that receives visitors, but does not represent the company. If services, positioning or the public have changed, the problem can be of message and structure, not just design.Before changing screens, check what a person should understand when arriving and what information he needs to take the next step.

A seemingly simple website with many contents. Changing the design can be direct; reviewing, deciding what to keep and moving each content can be the most delicate part.It is appropriate to assign responsibility for preparing and approving texts, documents and images.

A web with linked forms, reservations, payments or tools. These pieces should not be treated as visual blocks. You have to specify which data they collect, where they are sent, who manages them, and what should happen to an error. If third party services intervene, you also have to check who controls the accounts and what will happen if that dependency changes.

A change of URLs or platform. If content is deleted or moved, the work must include an express decision on each relevant address and on co-existence or removal from the previous site. It is not appropriate to assume that migration will occur by publishing the new website alone.

An urgent project with a still diffuse scope. Reducing the first range may be reasonable, but only if the target is retained.For example, in a hypothetical case, a company could prioritize its service pages and its main form, leaving a secondary area for later.What is postponed should be identified, not implied.

What should be defined before the change begins?

You don't need to have the technical solution solved, but you should be able to answer some basic questions:

  1. What should the website get and what action should the visitor complete?
  2. Which pages, contents and functions remain valid?
  3. What parts prevent progress: presentation, structure, editing, integration or maintenance?
  4. What content should be created, reviewed or migrated, and who will approve it?
  5. What tools, accounts, forms and accesses depend on the current website?
  6. What's left out of the first phase?

These responses help compare proposals more fairly. One proposal may include only design and development; another may also include content, migration, testing, analytics or training. If the scope is not separated, two options with similar names may be describing different works.

Conclusion: the best redesign is the one that adjusts the change to the problem

If the web works and the difficulty is in how it is presented, a visual update may be enough. If the problem affects specific pages, messages and paths, a partial redesign allows concentrating the effort. If the technical base, structure or functions block a reasonable evolution, the complete reconstruction provides a more appropriate framework, provided that migration and subsequent maintenance are planned.

The decision depends less on the website looking old than what it prevents you from doing now. If you are still not clear what to keep, what to replace and what scope your case needs, you can explain your web redesign project to the AVSISTEC team.