Your website still works. Customers can find what they need, complete their purchases and use the services you provide. But visually, it is starting to feel dated, or perhaps it no longer reflects your brand.

Does that mean you need a complete redesign?

Not necessarily. Sometimes a website needs a reskin: an update to its visual presentation without fundamentally changing what the website does or how its main journeys work.

I've experienced the challenges firsthand. I worked on the reskin of Domino's UK website while it was still running on a legacy platform. The project involved much more than changing colours and typography: we had to work around years of accumulated code, ongoing development and the risks of making visible changes to a busy e-commerce website. That experience shaped how I think about reskinning, particularly the importance of understanding what's underneath the interface before committing to a visual refresh.

That can be a sensible investment. But a reskin is not automatically quick, cheap or risk-free. A new colour palette can affect accessibility. A different font can change page layouts. And a seemingly small change to a shared button can involve more work than expected if the website has several inconsistent versions of it.

Before committing to a project, the useful question is not simply How different should the website look? It is What problem are we trying to solve, and what level of change will solve it?

Here are ten questions I'd encourage business leaders to ask before deciding whether a reskin is the right approach.

1. What's the difference between a reskin, a redesign and a rebuild?

These terms are often used interchangeably, but they describe different kinds of work. The boundaries are not always clear-cut, so agreeing on what they mean for your project matters more than the label itself.

A reskin might update typography, colours, spacing, imagery, icons and component styling while keeping the existing journeys intact.

A redesign might change how customers find products, complete a checkout or navigate the site. It does not necessarily require a new back end.

A rebuild is usually driven by technical needs: replacing an outdated framework, reworking architecture or moving to a different platform. It can happen with very little visual change.

You can also combine approaches. A business might reskin a website while selectively redesigning one underperforming journey. What's important is agreeing on the boundaries before work starts.

2. How do you know whether your website needs a reskin?

I wouldn't recommend a reskin simply because a certain number of years has passed. There is no universal three- or four-year rule. A website can remain effective for years, while another might need attention much sooner.

Look for a specific reason to change. Perhaps your brand identity has evolved, your visual styles are inconsistent, or the website feels noticeably different from your other digital products. Perhaps customer feedback shows that the interface is difficult to read or visually confusing, even though the underlying journeys work reasonably well.

Then look at the evidence. Review customer feedback, analytics, usability findings, accessibility issues and the performance of key journeys.

If customers struggle to find information, navigation is confusing or checkout abandonment is linked to the journey itself, new colours and typography probably won't solve the underlying problem. That's a sign you may need a redesign, or at least more targeted UX improvements.

A useful starting question is: If we kept the same structure and functionality but changed the appearance, would we solve the problem we're seeing?

If the answer is no, a reskin alone is unlikely to be the right investment.

3. What can change during a reskin, and what should stay the same?

A reskin usually focuses on the visual layer: colours, typography, icons, imagery, spacing, borders, shadows and the appearance of reusable components. It might also refine responsive layouts and interactive states such as hover, focus and disabled buttons.

The intention is generally to preserve existing functionality and core user journeys. Customers should still be able to complete familiar tasks without having to relearn how the website works.

But even visual changes can have behavioural consequences. Larger type may wrap onto new lines. Different button sizes can shift layouts. A redesigned navigation component can affect how menus open, close and respond to the keyboard.

That's why I would ask the team to define what is in scope, what is out of scope and what counts as an acceptable exception.

For example, if a page has a confusing form, will the project fix the form or only restyle it? If a component is inaccessible, will that be treated as part of the reskin? If the mobile layout breaks at larger text sizes, who owns the fix?

Answering these questions early helps prevent a visual refresh from quietly turning into an unplanned redesign.

4. What should you assess before starting?

This is where the condition of the existing front-end codebase matters.

During the Domino's reskin, we worked with a legacy codebase where UI components weren't standardised. The same elements appeared repeatedly across the website, sometimes with slightly different implementations. Older layout techniques, including CSS tables, floats and fixed-width elements, made apparently small visual changes more complicated than expected.

We improved the organisation of the styles using BEM, but there were limits to how much HTML we could refactor within the project's scope. Updating duplicated templates across different areas remained repetitive and time-consuming. It was a practical reminder that the cost of a reskin depends heavily on the condition of the existing code, not simply the number of pages that need a new look.

Before estimating the work, I'd ask the delivery team to assess the current UI architecture: how much styling is shared, where components are duplicated, whether design tokens exist, how responsive behaviour is implemented and how much technical debt could complicate the changes.

Also check third-party interfaces. Payment forms, embedded widgets, authentication pages and externally supplied components may not be styled or released in the same way as the rest of your website.

This doesn't mean you must rebuild the component library before reskinning anything. It means the estimate should reflect the actual implementation, not just the number of screens in a design file.

5. How much time and money should you budget?

There is no reliable standard price or timeline for a website reskin. Two sites with a similar number of pages can require very different amounts of work.

The biggest cost drivers are usually the number of unique layouts and components, the quality of the existing code, the amount of custom design work, the number of devices and experiences to support, and the complexity of testing and releasing the changes.

A useful estimate separates the project into design, development, quality assurance and release activities. It should also account for accessibility reviews, stakeholder feedback, external dependencies and time to fix issues found during testing.

I'd be wary of an estimate based only on how quickly the new designs can be produced. Design approval is not the same as production readiness. The new interface still needs to be implemented, checked in real journeys and introduced safely.

Ask for assumptions and exclusions alongside any timeline. For example: does the quote include mobile layouts, the logged-in experience, error messages, third-party integrations and post-launch fixes? What happens if existing technical debt is uncovered?

A realistic plan makes uncertainty visible rather than hiding it behind a single optimistic date.

6. What are the biggest risks of a website reskin?

One common assumption is that visual changes are low-risk because the functionality is staying the same. In practice, the visual layer is part of how people use a website, so changes can affect both usability and accessibility.

Consider a new brand palette. It may look attractive in a design presentation but produce insufficient colour contrast on buttons, labels or form errors. A new font may create text overflow when users zoom in. Updated component styling can accidentally remove visible keyboard focus indicators or make disabled states difficult to distinguish.

Responsive behaviour is another risk. A layout that works at a few common screen widths may fail with longer text, larger text settings or unusual content.

And then there's consistency: if parts of the website use shared components and others rely on one-off styling, the result may look uneven even when each individual page has been updated.

I would treat accessibility, responsive behaviour and visual consistency as acceptance criteria from the beginning. Include real user journeys, keyboard interaction and appropriate assistive-technology checks in the test plan, rather than treating them as optional polish at the end.

A successful reskin should not make a website harder to use in the process of making it look better.

7. Can a reskin affect SEO and website performance?

Yes, although a visual refresh doesn't automatically improve search rankings or performance.

If URLs, content and page structure remain unchanged, many of the more obvious SEO migration risks can be avoided. But implementation changes can still have consequences. Replacing headings with visually styled elements, accidentally hiding content, changing metadata or introducing layout instability can all create problems.

New fonts, images, animations and styling can also increase page weight or affect loading and rendering performance if they're not handled carefully.

Before development begins, establish a baseline for the pages and journeys that matter: search visibility, organic traffic, page speed, Core Web Vitals and any other metrics relevant to your business.

During implementation, protect semantic HTML, headings, metadata, internal links and existing URLs unless changes are deliberately in scope. Test mobile layouts and performance with realistic content, not just idealised design examples.

After release, monitor the same measures. If something changes, you'll have a baseline to investigate rather than relying on impressions alone.

8. Can you keep the existing CMS and back-end systems?

In many cases, yes. A reskin is often designed specifically to keep established content-management processes, APIs and back-end services in place.

That can reduce the scope substantially, especially for a website with working business logic and integrations that don't need to change.

However, retaining the back end doesn't mean every screen can be restyled independently of it. Some UI elements come from a CMS template, authentication provider, checkout integration or third-party service. Others depend on data structures that influence what can be displayed and how flexible the layouts can be.

Before promising a purely front-end change, identify who owns each part of the customer experience and how it can be modified. A new design may require coordination with a supplier even when no back-end functionality is being replaced.

The right question is not simply Can we keep our CMS? but Can the existing systems support the visual experience we want without unexpected integration work?

9. How should the refreshed design be tested and released?

A staging environment is useful, but staging alone isn't a release strategy. The team still needs to decide what to test, how to review changes and how to respond if something goes wrong.

Testing should cover the main customer journeys, different screen sizes, keyboard behaviour, accessibility, performance and any integrations affected by the new UI. If the site uses a shared component library, visual regression testing can help identify unexpected changes across covered components and states.

You also need a rollout decision. A single launch delivers a consistent new experience immediately, but concentrates the change into one release. A phased rollout can make changes easier to monitor, although supporting old and new styles at the same time may introduce additional complexity.

On the Domino's project, we introduced the refreshed interface across five phases rather than releasing everything at once. That helped us manage the scale of the changes, but phased delivery created challenges of its own. QA joined after development was already underway, so bugs found in an earlier phase sometimes had to be fixed and carried forward into later phases that were still in progress. That led to repeated work and regressions.

By the final phase, QA was working alongside development, and the process went much more smoothly, even though that phase was substantial. My biggest takeaway was that phased delivery needs more than a release schedule: it needs early testing involvement, clear boundaries between changes and a way to manage fixes across work that's happening in parallel. I've described the project in more detail in my Domino's website reskin case study.

Neither approach is automatically safer or quicker. It depends on how the site is built, how independent its pages or applications are, and what release controls are available.

Before launch, agree on the release checklist, monitoring responsibilities and rollback approach. In many modern deployments, downtime can be avoided or kept very short, but that depends on the hosting and release setup—not on the fact that the work is called a reskin.

10. How do you measure whether the reskin was successful?

This is the question I'd want answered before the project begins, not after the new website goes live.

If the objective is stronger brand consistency, define how that will be reviewed. If the goal is better readability or accessibility, agree on what improvements will be tested. If the project is expected to improve commercial performance, identify the relevant conversion or engagement measures and establish a baseline.

Useful measures might include task completion, conversion through important journeys, customer feedback, accessibility findings, performance metrics and the number of visual inconsistencies remaining across products.

Be careful about attribution. If conversion improves after a reskin, the visual changes may have contributed, but seasonality, campaigns, pricing or other product changes could also be responsible. Where feasible, use controlled experiments or carefully chosen comparisons to understand the impact.

Not every reskin needs to deliver a dramatic uplift in conversion to be worthwhile. Sometimes the value is a clearer brand, a more consistent interface or a stronger foundation for future development. The important thing is to agree on those outcomes up front and evaluate the work against them.

Final thoughts

A website reskin can be a practical way to refresh your digital presence without committing to a complete redesign. But the decision shouldn't be based on appearance alone.

Before approving the project, understand what already works, what genuinely needs to change and how the existing technology will affect the scope. Set clear expectations for accessibility and quality, make time for testing, and decide how you'll measure the outcome.

The most successful reskin isn't necessarily the one that looks the most different. It's the one that improves the experience without introducing unnecessary complexity or disruption.