Stop Calling It A “Redesign.”

The word poisons the project before it starts. We’ve been saying this to clients for a few years now and getting pushback every time, so we’re going to make the case here in writing.

Here’s the problem. When you tell your team you’re doing a redesign, everyone in the organization hears the same thing. New colors. New fonts. A fresh homepage. Something that looks less tired than the current one. Maybe some updated photography. The word is doing all the work, and the work it’s doing is making the project smaller and more cosmetic than it actually needs to be.

That mental model shapes everything that follows. Budget conversations. Scope conversations. Who gets involved. Who doesn’t. How you measure success. Whether anyone cares six months after launch.

And it’s almost never what the project actually is.

What the project actually is

In twenty-plus years of doing this, we have never once worked on a project where the real problem was that the site was ugly.

The sites that come to us with “we need a redesign” written in the subject line are almost always suffering from something else. The content is out of date and nobody has owned it in years. The organization has changed and the site doesn’t reflect the new reality. The audience has shifted. Mobile usage overtook desktop and the current site was built in a different era. The CMS is a nightmare that only one person who left the company two years ago knows how to use. The analytics have been quietly flat for a long time and someone finally looked at them. The sales team has been begging for better materials to send prospects. A new executive director arrived and inherited a site that embarrasses them.

None of these are design problems. All of them look like design problems from a distance, because “the site” is where the symptoms show up. But treating the symptom doesn’t help if you don’t understand the cause.

A redesign fixes the way the site looks. That’s it. If the real problem is anything else on the list above, you can redesign all day long and the problem will still be there under the new paint.

What happens when you call it a redesign anyway

Here’s the pattern. Client gets the word out that they’re doing a redesign. The brief gets written in design language. We get hired to make something that looks better. Design happens, build happens, launch happens.

Six months later, we’re having a hard conversation. The site looks great. Traffic is about the same. Conversions are about the same. The sales team is still complaining about not having good materials to send. The CMS is still the same CMS, just with a new theme on top. The executive director is less embarrassed, which is nice, but the thing that was broken is still broken.

Nobody is quite willing to call this a failure, because the site genuinely does look better. But nobody is calling it a success either. The project just sort of sits there, declared done, with everyone a little quieter about it than they expected to be.

We’ve been part of this cycle. We don’t want to be part of it anymore.

What we call it instead

The word we use now is “rebuild.” Sometimes “replatform.” Sometimes “re-architect.” Sometimes just “the website project,” without a verb attached, until we know what the actual verb should be.

Those words sound bigger than “redesign.” That’s deliberate. They force a different kind of conversation at the start. “Rebuild” implies that we might change what’s underneath, not just what’s on top. “Replatform” implies that we might change the technology, the content model, the way the thing gets fed and maintained. “Re-architect” implies that we might change the whole information structure.

Any of those might end up including a visual redesign. Sometimes they don’t. Sometimes the right answer is to keep the existing design mostly intact and fix the three things that are actually broken underneath it. That’s hard to propose if the project has already been named “the redesign.”

The deeper problem

The real reason this matters is that “redesign” is a word that lets everyone off the hook.

A redesign is a thing you can hire a firm to do. You tell them what you want it to look like, they come back with options, you pick one, they implement it, and the project is over. The client doesn’t have to do much. The organization doesn’t have to change. Nobody has to look hard at why the current site isn’t working. You just get a new one.

A rebuild is different. A rebuild forces the organization to answer harder questions. What are we actually here to do. Who are we trying to reach. What’s broken about how we’re currently reaching them. Who inside this organization is going to own the thing we build, after we build it. What are we willing to stop doing in order to do this well.

Those are leadership questions. They’re hard. They require sign-off from people who don’t usually get involved in “the website.” They require honest conversations about what’s working and what isn’t. They sometimes surface problems that have nothing to do with the website at all, which is uncomfortable for everyone.

A redesign lets you avoid those questions. A rebuild makes you face them.

That’s why clients prefer “redesign.” That’s also why we don’t.

What this looks like in practice

When a client comes to us saying “we need a redesign,” here’s what we do.

We don’t correct them in the first meeting. Nobody wants to be lectured about word choice. We just ask our usual discovery questions. What’s happening. Why now. What success looks like. Who’s going to own this.

By the second or third meeting, we have enough information to say, usually something like this: “What you’re describing isn’t actually a redesign. It sounds like a rebuild. Here’s why that distinction matters for how we scope the project.”

Then we show them. We show them which parts of their current situation a visual refresh would solve, which would be few. We show them which parts need bigger structural work. We show them what skipping the structural work would mean six months after launch.

Most clients, when it’s laid out that way, get it. They may still call it a redesign in their internal communications, out of habit or because that’s the budget line it was approved under. But by the time we start the actual work, we’re all operating on the same understanding of what the project really is.

A few clients don’t get it. They want a redesign, in the small sense, and that’s all they want. We generally decline those projects now. We’ve been part of enough declared-done-but-nobody-is-happy launches to know how they end.

The one-sentence version

If you take one thing away from this: before you call a project a redesign, ask whether redesigning the thing would actually fix the problem.

If the answer is yes, great. Call it a redesign. Hire somebody to redesign it. Everyone goes home happy.

If the answer is no, give the project a different name. The name you give it on day one determines what it’s allowed to become. If you call it a redesign, that’s what you’ll get, and the actual problem will still be there.

Give it room to be bigger. Give it a word that makes room for the questions underneath the surface. You can always decide later that the answer is actually just paint.

But don’t let the word decide for you.