You don’t usually get a calendar invite titled “website governance crisis.” You get a Slack thread: sales says the site “feels dated,” the CEO shares a competitor’s homepage, and someone asks you to “price out a full redesign.”
Use each redesign request as a governance trigger: before approving new design work, decide who owns the website after launch, what they control, and how ongoing support will work.
If you react by jumping straight into scopes, timelines, and design partners, you’re treating a governance problem like a UI problem. The useful move is to pause and ask: “Is this really about pixels—or about the fact that no one owns this site between big projects?”
This article is about that pause.
We’ll treat “we need a redesign” as a diagnostic signal, use Maintenance Maturity as the lens, and walk through the ownership and governance decisions that prevent you from having this same conversation every 18–24 months.
1. The moment you hear “we need a redesign” is usually a governance problem, not a design problem
Picture the meeting.
You’re the VP of Marketing. The CEO says conversions feel soft, sales says prospects are “getting lost,” and product leadership complains that messaging is out of date. Someone suggests a redesign. Heads nod.
Notice what no one says:
- Who is responsible for keeping core user journeys healthy between big projects.
- Who owns content changes day to day.
- How often anyone reviews the site against current strategy.
- Who can approve fixes without another executive meeting.
That silence is the problem.
In support work, we often see the same pattern: the last redesign shipped, everyone high-fived, and then ownership quietly evaporated. There’s no clear runbook, no recurring review, and no accountable owner. Two years later, the site is stale, inconsistent, and fragile—so a redesign feels like the only option.
We explored this symptom-level pattern in “redesign as ownership problem” terms in the article When a Painful Redesign Request Is Really a Website Ownership Problem, which works well as a prerequisite if you need that framing.
This piece goes a step further: what governance decision do you need to make the week you’re being pushed to “just get the redesign going”?
2. Common redesign requests that secretly signal “no one owns this site”
Not every redesign proposal is a governance red flag. Strategy shifts, rebrands, and new product categories can absolutely warrant a fresh experience.
But there are recurring request patterns that scream ownership gap more than design gap.
Pattern A: “The content is out of date everywhere”
If the complaint is “the site doesn’t reflect who we are anymore,” the root cause is often:
- No named owner for each critical area of content (products, pricing, legal, careers).
- No standard for what “current” means (e.g., every tier’s description reviewed at least quarterly).
- No mechanism to flag, prioritize, and approve content changes.
That’s not a layout problem. That’s missing content governance.
Pattern B: “Prospects keep hitting dead ends”
Sales hears “I couldn’t find the right information” or “the form didn’t work.” Marketing hears “our funnel is broken.” The redesign ask shows up as, “We need a new IA and new page templates.”
Underneath, what’s really happening is that no one is accountable for:
- Monitoring key conversion paths after launch.
- Logging and closing tickets when forms, flows, or integrations break.
- Owning UX fixes that cross team boundaries (marketing copy, dev changes, ops data).
If your only response to broken flows is “let’s redo everything,” you’re operating at low Maintenance Maturity—reacting with projects instead of maintaining a capability.
Pattern C: “The design looks inconsistent”
Stakeholders complain about “off-brand” pages, random components, and one-off experiments that never got cleaned up.
That typically points to:
- No enforced design system or component library.
- No approval path for adding new patterns.
- No review cadence to prune experiments or legacy layouts.
You can absolutely solve this with a thoughtful redesign—but if you don’t fix the decision rights around who can add, change, and retire patterns, the new design will drift just as fast.
Pattern D: “We keep bolting on tools and it’s all getting fragile”
Marketing has layered chat, personalization widgets, pop-ups, and assorted SaaS tools onto the site. IT is nervous. Performance is suffering. Someone suggests “a new platform and redesign” to clean it all up.
The deeper signal is that no one owns:
- A standard for what can be added to the site and why.
- A review process for third-party tools and scripts.
- The technical health of the stack between big projects.
Again, this is governance first, design second.
When multiple patterns like these show up together, you’re not looking at one redesign request—you’re looking at a website that’s been running without an owner.
3. A simple diagnostic: Is this a redesign task or an ownership decision?
Use this quick diagnostic to separate “we need different pixels” from “we need different governance.”
Question 1: What would stop this from happening again?
Ask your stakeholders: “If we did a full redesign, what would make this same set of complaints less likely two years from now?”
If the answers sound like:
- “We’d have a better brand story.”
- “The new design would be more modern.”
- “We’d be on a new CMS.”
…then you’re still in project-thinking.
If the answers start to sound like:
- “Someone would need to keep content up to date.”
- “We’d have to watch funnel performance over time.”
- “We’d need a way to manage all these integrations.”
…you’re already describing ownership and governance.
Question 2: Who is accountable between projects?
Clarify the distinction:
- Budget approver: the person who signs off on spend.
- Project sponsor: the person who champions a redesign.
- Site owner: the person accountable for the site’s health every week of the year.
In many organizations, these three roles are blurred into a single executive. That’s dangerous.
If the only name anyone can offer for “site owner” is the same person who just asked for a redesign—and they have no time, no runbook, and no support budget—you’ve found your governance gap.
Question 3: Is the pain recurring or event-driven?
Some triggers are legitimately event-driven:
- Major rebrand.
- New product category.
- Entering a new market.
Others are recurring:
- “Our product pages are always behind the roadmap.”
- “Forms keep breaking and no one notices until sales complains.”
- “Analytics are a mess every year.”
Recurring pain almost always points to missing ownership, not missing design talent.
If most of your pain is recurring, your first move should be an ownership decision, not a creative brief.
4. Who should own the website after launch—and what that ownership actually includes
Once you’ve decided you’re facing a governance problem, the next step is assigning real ownership.
The core owner: business-side accountability
For a serious revenue-supporting site, the core owner usually lives in marketing or a nearby commercial function—often a director or VP.
Their ownership should cover:
- Outcomes: traffic quality, conversion performance on key paths, and alignment with go-to-market strategy.
- Prioritization: deciding which website work happens this month versus next quarter.
- Standards: approving the content, UX, and technical baselines that others must follow.
- Escalation: owning the call when there’s a conflict between speed and risk.
Notice what this is not: pushing pixels in Figma or writing every line of copy.
Supporting owners: IT, product, and external partners
The site owner can’t do it alone. You need a clear division of labor:
- IT / engineering: owns infrastructure, security posture, deployment processes, and production access.
- Product or operations: owns data flows, integrations, and how the site connects to systems like CRM and billing.
- External design/dev/support teams: own implementation quality, support responsiveness, and execution against agreed standards.
What matters is that each group knows:
- What they can decide unilaterally.
- What requires cross-functional review.
- How work is requested, tracked, and accepted.
Maintenance Maturity: the lens for right-sized ownership
Maintenance Maturity is a practical way to describe how your organization treats the website:
- Reactive: you only touch the site when something breaks or leadership complains.
- Routine: you have basic checklists, simple monitoring, and a named owner who can approve small changes.
- Proactive: you run recurring reviews, have a roadmap for improvements, and budget ongoing support.
If your redesign request emerges from a reactive posture, your primary governance decision is to move at least to routine: name a site owner, define their rights, and create a small but reliable cadence.
Without that, any new design will quickly revert to chaos.
5. Designing a light-weight governance model so redesigns don’t become your only maintenance plan
“Governance” sounds heavy. It doesn’t have to be.
For most mid-sized organizations, the right level is light but explicit: a few clear documents and cadences that everyone respects.
The Website Charter: one page, real decisions
Start with a short Website Charter that answers:
- Who is the named site owner.
- What outcomes they’re accountable for.
- Which decisions they can make without another executive meeting.
- Which changes require cross-functional review (e.g., pricing pages, legal content).
- What “good enough” looks like for performance, accessibility, and UX.
This is not a policy tome. It’s a page you can share in Slack and reference in every “we should redesign” conversation.
Operating cadences that beat redesign cycles
Replace “big redesign every few years” with lighter recurring rhythms:
- Monthly: tactical check-in on bugs, small UX issues, analytics anomalies, and content updates.
- Quarterly: review core funnels, top content, and any drift from brand or product strategy.
- Annually: ask whether any structural shifts (new lines of business, major rebrand) justify a real redesign exploration.
Most websites do not fail because the annual review didn’t happen. They fail because nobody owns the monthly and quarterly basics.
Change thresholds and escalation paths
To keep governance from becoming a bottleneck, define thresholds:
- Minor changes (copy edits, swapping images, adding FAQs): logged and executed without a committee, within a defined SLA.
- Moderate changes (new templates, new flows, adding tools): require review by the site owner plus one relevant partner (e.g., IT).
- Major changes (rebrands, platform migrations, new IA): treated as projects, with formal approval and planning.
Publish a simple escalation path: who decides when a moderate change becomes a major one; who gets paged when risk is high.
If you want a deeper dive into governance pitfalls that turn well-intentioned redesigns into years of support pain, it’s worth reading Governance Mistakes That Turn a Website Redesign Into an Ongoing Support Headache as an expansion.
This is what “light but explicit” looks like: enough structure that people stop improvising, not so much that work grinds to a halt.
6. How ongoing support changes the redesign conversation
Once you have basic governance in place, you still need the capacity to act on it. That’s where ongoing support comes in.
We have noticed that the most stable sites pair clear ownership with a standing support relationship instead of ad-hoc heroics. The combination is what moves you up the Maintenance Maturity ladder.
In practice, an ongoing support model gives you:
- A runbook: agreed processes for content updates, fixes, small UX improvements, and releases.
- A ticketing and triage system: issues aren’t debated in Slack; they’re captured, prioritized, and resolved.
- A budgeted capacity: you don’t have to fight for funding every time you discover a problem.
- A feedback loop: insights from incidents and small improvements feed back into your governance standards.
When you treat your support partner as part of governance, not just a help desk, you can also extend ownership into specialized areas.
For example, if you’re wrestling with who owns specific post-launch risks, you might contrast this broader governance view with focused discussions like Who Actually Owns Fixing Accessibility Bugs After Launch: Marketing, IT, or Ongoing Support?, which zooms in on a single responsibility area.
Over time, this is how your Buyer Maturity Path evolves:
- You notice repeating redesign conversations.
- You recognize the governance cause, not just the design symptom.
- You formalize ownership and light governance.
- You invest in ongoing support to operationalize those decisions every week.
At that point, redesigns become strategic choices—not emergency resets.
If you want to see how ownership and execution can work hand-in-hand at a service level, it helps to contrast this governance-first view with domain-specific escalation topics such as Who Owns Technical SEO After Launch? Turning Your Support Vendor into a Search Governance Partner.
7. Decide your next move: redesign now, fix governance, or do both in sequence
When you’re in the live conversation—CEO asking for a redesign, stakeholders impatient—you don’t have time for theory. You need a clear call.
Use this simple decision tree.
Path 1: Governance-first, then redesign
Choose this if:
- Complaints are mostly about staleness, inconsistency, and broken flows.
- No one can name a real site owner or show you a runbook.
- You’ve been through at least one “big redesign” in the last few years and still ended up here.
Your moves in the next 60–90 days:
- Name a business-side site owner and document their decision rights.
- Draft a one-page Website Charter and share it cross-functionally.
- Stand up a basic support rhythm (ticketing, monthly check-in, quarterly review).
Only after that’s functioning should you scope a redesign—because now you have the governance to protect your investment.
Path 2: Parallel governance and redesign
Choose this if:
- A legitimate strategic shift or rebrand means your current site is structurally wrong.
- Leadership is committed to a redesign, and delaying it would hurt.
- You can secure time and attention to define ownership and governance as part of the project.
For a deeper treatment of this decision, related Website Redesign articles guidance explains the adjacent issue in more detail.
Your moves:
- Bake governance into the redesign brief: “Who will own this after launch, and how will they operate?”
- Require your redesign partner to collaborate on handover docs, standards, and an initial runbook.
- Confirm your support model before launch, not six months after.
If you want a sharper sense of how redesign planning can go wrong without this lens, consider the expansion article Why Website Problems Repeat When No One Owns the Decision After the Meeting, which dives into how decision follow-through fails.
Path 3: Minimal change (and what it really means)
There is a third option: keep the current site, approve a few tactical tweaks, and defer both governance and redesign.
Be honest about what that decision implies:
- Redesign conversations will keep resurfacing.
- Drift, incidents, and content debt will grow.
- You’ll spend more political capital defending the site than improving it.
Sometimes that’s the reality—budget or timing make deeper change impossible. But name it clearly, so you’re not surprised when the same Slack thread appears again.
Where Ongoing Website Support fits
If reading this made you realize that your “we need a redesign” conversation is actually a governance decision, your next move is not a faster mood board—it’s an operating model.
A focused Ongoing Website Support engagement is one practical way to turn these ownership ideas into how your site actually runs week to week, including a clarified site owner role, a working runbook, and realistic review cadences.
The cost of leaving governance unresolved is simple: every 18–24 months, you’ll burn budget and attention on another redesign that leaves the underlying ownership problem untouched.
If you want help pressure-testing whether you’re facing a design problem, an ownership problem, or both, reach out through a short conversation about how your site is currently being run and we can map your current Maintenance Maturity against a concrete support and governance plan.
Before the next website change, document and approve the ownership decision this article has outlined.