Announce only if something customers use has changed: a login, a saved link, a process, or a set of details. A new design on its own is not news to anybody outside your business.

The instinct to announce

A rebuild is months of work, real money, and a great deal of internal attention.

That makes it feel like an event, and events get announced.

From outside, almost none of that is visible. A customer who visits twice a year notices a different look for about two seconds and continues to whatever they came for.

The gap between how significant it feels internally and how significant it is externally is the largest in this entire process.

The test for whether to say anything

One question: has something a customer relies on changed.

If the answer is no, there is nothing to announce, and an announcement is a message that spends attention to deliver no information.

If the answer is yes, then the announcement is not really about the website. It is about the thing that changed, and the website is only the reason.

That reframing tends to produce much better messages, because it starts from what the reader has to do rather than from what you have built.

What genuinely warrants a message

The first three are the ones that generate support calls if unannounced, which is the practical reason to send anything at all.

What a good version says

It leads with the change and what to do about it, not with the project.

The version that opens by describing months of work on a fresh new online experience buries the useful sentence four paragraphs down, and most readers will not reach it.

The useful version says: the login page has moved, here is the new address, your existing password still works, and here is who to contact if it does not.

Keep it short, make the action obvious, and give a route to a human. The design can be mentioned in a line at the end for anybody who cares, and few will.

Who actually needs to know

Not everybody, and segmenting saves goodwill.

People with accounts or logins, if those changed.

Anybody mid-process, such as a live quote or an open order, who should hear directly rather than through a mailing.

Partners and suppliers who link to you or embed your material, who need advance warning rather than an announcement afterwards.

And your own staff, particularly anybody who answers the phone, who should see the new site before customers do.

Tell your own people first

This is the step that gets skipped and it produces the worst impressions.

A customer phones with a question about the new site and reaches somebody who did not know it had changed.

That single exchange does more damage than a slightly awkward design would, because it says the business does not communicate internally.

Whoever answers phones and email should have seen the site, know where the common pages now live, and know who to escalate a fault to. A twenty-minute walkthrough the day before is sufficient.

A worked example

A distributor rebuilt a site that included a customer portal for order history.

They sent one message to their whole list describing the new website, its improved design, and its modern responsive layout.

The portal login had moved and now required a password reset, which was mentioned in the sixth paragraph.

They received over ninety support calls in four days, most of which opened with the customer saying they had been locked out of their account.

The second attempt, sent to portal users only, had a subject line saying the account login had moved and three sentences underneath: the new address, the reset link, and a phone number.

Calls dropped to a handful.

Nothing about the site changed between the two messages. Only what was said first.

Timing

Advance notice for anything requiring action, and afterwards for anything informational.

A login change or a new process deserves a message before the switch, so people are not surprised mid-task, and a reminder after.

Partners who link to you want warning early enough to update, which means weeks rather than days.

What almost never works is announcing on launch day and nowhere else, because that is precisely the moment when small faults are still being found and you have directed the maximum number of people at the site.

Where there is any doubt, launch quietly, spend two days fixing what surfaces, then tell people.

Asking for feedback, carefully

Inviting comment is reasonable and it has a cost worth understanding.

A general request for opinions on a new design produces opinions on the design, most of which are taste, none of which you will act on, and all of which create an expectation of a reply.

A specific request produces something useful: ask whether anything they used to do is now harder to find, which is a question about function and generates reports of real problems.

Ask the narrow version, or do not ask.

The counter-case

There is a situation where announcing the rebuild itself is right, and it is when the site is genuinely the product.

An online shop, a booking platform, a members' organisation, or a business whose customers use the site weekly rather than annually.

There the change is a change to something people actually inhabit, and treating it as a non-event is its own kind of discourtesy.

Even then, lead with what is different for them rather than with the achievement, and expect the first week's feedback to be disproportionately negative regardless of quality, because familiarity was itself a feature you removed.

The decision

  1. Ask what changed for a customer, specifically.
  2. If nothing did, send nothing.
  3. Brief your own staff the day before, regardless.
  4. Warn partners who link to you, weeks ahead.
  5. Message only the affected group, not the whole list.
  6. Lead with the action, not the project.
  7. Launch quietly, fix, then tell people.

Most rebuilds stop at step three, and that is the correct outcome rather than a missed opportunity.

Announcing an actual problem is a different discipline, covered in telling customers something went wrong.


Frequently asked questions

Should I announce a website redesign?

Only if something a customer relies on has changed: a login, a saved link, a process, or contact details. A new design alone is not news outside your business.

What should the message say?

Lead with the change and the action required. The new address, whether the password still works, and who to contact. The design can be a line at the end.

Who needs to be told?

People whose logins or processes changed, anybody mid-order, partners who link to you, and your own staff. Not the entire mailing list.

Why brief staff first?

Because a customer calling about the new site and reaching somebody who did not know it changed does more damage than any design flaw.

When should I send the announcement?

Before the switch for anything requiring action, and after for anything informational. Avoid launch day, when faults are still surfacing.

Should I ask customers for feedback?

Ask a narrow question, such as whether anything they used to do is now harder to find. A general request for opinions produces taste, not problems.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Rebuild about to go live?

Ask what actually changed for a customer. If the answer is nothing, brief your staff and send no announcement at all.

Start a Conversation