We've seen a familiar pattern in redesigns that don't deliver lasting change. At launch, they look like successes.
The site goes live after months of planning, design reviews, and content migration. It looks great. Leadership is pleased, and the marketing team can stop apologizing for the old one. For a while everything feels like progress.
Then marketing needs a landing page for a campaign. The template isn't quite right, so someone opens a development ticket. A small content change gets caught between departments. A workaround that was supposed to be temporary becomes the way everyone does things. Work still gets done, but it takes longer, and the list of things the team wants to improve grows faster than the list of things it can change.
A few budget cycles later, someone in a planning meeting says what everyone is thinking: the site is starting to look dated again, so the next redesign gets scoped.
We've seen this when organizations come to us for a second redesign, sometimes a third. The new brief often describes the same constraints that made the previous site difficult to change. In those cases, the last redesign failed because it left the underlying problems alone.
What a redesign changes
When someone says the website needs a redesign, they usually mean what customers see: layout, navigation, visual identity, and templates. But that's one part of a larger system, and it helps to think of that system as three layers.
1. The presentation layer is what people interact with: design, navigation, templates, and the front end. This is where a traditional redesign concentrates its attention because it's the most visible part of the investment.
2. The foundation makes those experiences possible: the content management platform, architecture, integrations, reusable components, and publishing tools. It determines what a site can support and how hard it is to change. When it's poorly built or weighed down by technical debt, even straightforward improvements can require substantial engineering work.
3. The operating system is how the organization gets things done. Who owns the website? Who can publish? Which changes need a developer? Who approves what? When marketing, technology, and compliance disagree, who decides?
That third layer is easy to overlook because it never appears in a screenshot or a platform demo. Yet even a well-designed site on a capable platform can be difficult to improve if the people responsible for it can't make decisions or move work forward.
Imagine two credit unions preparing to launch a loan promotion. Both use the same content management platform. Both need a landing page, an application path, and the right disclosures.
At the first credit union, marketing assembles the page from approved components, compliance reviews it through a defined workflow, and the page goes live in time for the campaign.
At the second, the templates can't accommodate the promotion. Marketing submits a development request, waits for an estimate, and works through several rounds of changes. Compliance approval happens separately, mostly by email. By the time everything is ready, the campaign has slipped.
The platform is the same. The difference lies in how it was configured and how the organization works around it. A redesign might give both credit unions a more attractive website, but unless it also changes those underlying conditions, the second team will struggle just as much with its next promotion.
Why the gains from a redesign fade
The pattern we see most often is a burst of progress at launch, followed by a gradual return to the old pace of work.
The launch is real progress. Changes that accumulated over years arrive together in one release, and for a while the organization can point to a long list of improvements finally delivered.
Then the project ends. The implementation team moves on, the budget closes, and the internal team returns to its regular responsibilities. The familiar approval processes, development dependencies, and resource constraints are still there. If those haven't changed, neither has the organization's ability to keep improving the site.
That's the mechanism behind the decline: a redesign concentrates a great deal of change into one event, but the rate of change afterward returns to whatever the organization can sustain.
The agency may have delivered exactly what it was asked to build. And sometimes design really was the problem: poor navigation, dated visuals, accessibility failures, and confusing customer journeys can all justify substantial design work. But when the frustration driving the next redesign is about how hard the site has become to operate, another visual refresh won't resolve it.
The harder question is whether the last project improved the organization's ability to keep improving the site. The broader argument is explored in our article: Every company is in the software business now. Act accordingly. In sum, the ability to deliver digital change repeatedly depends on how the organization works around its technology.
How to tell which problem you have
Before commissioning another redesign, find out what makes the current site difficult to operate. You don't need a consultant to begin, only a few honest answers from the people who get work live.
How long does a simple change really take? Pick something routine, like updating a campaign landing page, and measure the time from request to publication, including approvals, development queues, testing, and rework. A change that takes hours to make may spend weeks waiting to start. That gap tells you where the constraint lives.
Who can publish without asking someone else? Sort the changes your team makes by who can handle them: marketing alone, IT, an outside partner, or a committee. Some controls are necessary, particularly in regulated environments, but authority for routine decisions should be clear and approvals should match the risk.
What happens when you need something the templates don't support? Can your team assemble it from reusable components? Does a developer have to build it? Or does someone duplicate a page and embed content where it doesn't belong? The answer shows how well the architecture supports change.
How many workarounds are you maintaining? Ask the people in the CMS every day about duplicated content, spreadsheets used to manage publishing, manual data transfers, and processes that depend on one person knowing the trick. Each workaround may be reasonable on its own; together they can make a capable platform hard to operate.
When was the platform last evaluated against the work you need it to do today? Your CMS may have been chosen years ago, by people with different priorities, for a site whose main job was managing pages. Today you may need multiple sites, complex approvals, personalization, or faster campaign delivery. The platform may still fit, but the assumptions behind its implementation deserve another look.
These questions help separate three situations. If customers struggle with the experience but your team can improve it easily, the priority may be design and UX. If the team knows what to change but technology makes it difficult, the foundation needs attention. If the tools are capable but work stalls between people and departments, the operating system is contributing to the problem. The causes often overlap, which is why it's worth separating them before committing a budget to a solution.