Training on the New Site Before Launch Day

Half an hour on launch day

The new site goes live on a Tuesday afternoon. The developer shows the owner around the editing screens for half an hour, between phone calls.

Everything makes sense at the time. Click here to edit a page, here for photos, here to add an event.

Three months later the opening hours change, and nobody can remember where they are kept. The photo on the home page is still the spring one, and the news page has had nothing new since launch.

The site was built to be updated by the business, and nobody at the business updates it.

Why the launch-day session fades

• It happens on launch day, when everyone is distracted.
• The wrong people attend, or only one of the right ones.
• It is a tour, not practice at real tasks.
• Nothing is written down for this particular site.
• The first real edit comes weeks later, alone.

The fifth is where most sites stall. By the time something needs changing, the tour is a vague memory, and nobody wants to be the person who breaks the new site.

Put training in the project plan

Training should be a line in the quote, with time set aside, not something squeezed into the last hour of launch day.

Decide early who will make changes after launch and which changes they will make. That list shapes the training, and sometimes the way the site is built.

Then book the session for the week before launch, when the site is finished and nobody is yet answering calls about it.

Practise on the real site

Train on a copy of the finished site, with your own pages and photos in it, not on a demonstration site full of sample text.

On a copy, mistakes cost nothing. People learn faster when they are allowed to get something wrong and see how to put it right.

Everyone who will edit should have their own hands on the keyboard. Watching someone else click feels like learning and mostly is not.

Teach the tasks you will actually do

Most small business sites need the same handful of changes: opening hours, a price, a photo swapped, an event added, a news post, and now and then a new page.

Teach those, each one twice, with the person doing it. Leave the rarer settings to whoever looks after the site.

Ask what changes most often in the business itself. If the menu changes weekly, the menu is the lesson.

A guide to your own screens

A short written guide, with screenshots of your own site, outlasts any session. Four to eight pages is usually enough.

Give each common task its own page: where to click, what to type, how to check the result.

Add the photo sizes that work, the parts of each page that are safe to edit, and who to call when something looks wrong.

Keep it where people will find it, printed in the office and saved on the shared drive. A guide sitting in the developer's inbox helps nobody.

A worked example

A whisky bar with about sixty bottles on its back shelf launched a new site in the spring, with a page listing every whisky and a calendar of tasting nights.

Training was twenty minutes on launch afternoon, with the owner, while the bar was being set up for the evening.

The bar manager, who changes the list most often, was not there. By midsummer the site still listed bottles that had run out in April, and the next tasting on the calendar had already happened.

The owner asked the developer to fix the list. The developer suggested a proper session instead.

The manager and a bartender spent an hour on the real site, each adding a bottle, retiring one and posting a tasting night, twice over. A six-page guide with screenshots of the bar's own screens went into the office binder.

A month later a shorter session covered the questions that had piled up, including photo sizes and how to hide a sold-out bottle without deleting its tasting notes.

A second session a month later

The second session is where training sticks. By then real questions have collected, habits have formed and small mistakes are visible on the site.

An hour is usually enough. Go through the questions, fix what has gone wrong, and correct the guide wherever it was unclear.

Put the date in the calendar at the first session, or it will not happen.

Logins and what is safe to touch

Give each person their own login rather than one shared by everyone. Changes can be traced, and access can be removed on the day someone leaves.

Most systems offer an editor role that can change content but not settings, themes or plugins. That is the right level for most staff.

Show which parts of each page are safe to edit and which hold the layout together. A site built so that the editable parts cannot break the design makes everyone braver.

When someone new takes over

The person trained at launch will not be there forever. A new manager inherits the site along with the keys.

The written guide is the handover. Add it to what a new manager is shown in their first week, and ask whoever looks after the site for a short refresher when it happens.

The counter-case

Some sites rarely change.

A five-page site for a professional firm, updated twice a year by its developer under a maintenance plan, needs a shorter session: how to change the hours and the phone number, and who to call for the rest.

And some owners would simply rather hand changes over. That is a sound choice, and it moves the plan from training to a clear way of asking for changes.

For any site the business means to update itself, though, training belongs in the plan: before launch, on the real site, written down, and repeated a month later.

In the project plan

1. Name the people who will edit the site.
2. List the changes they will make most.
3. Book the session for the week before launch.
4. Practise on a copy of the finished site.
5. Write a short guide to your own screens.
6. Book a second session a month after launch.
7. Give each editor their own login.

Step six is the one that gets dropped, and it is the one that makes the rest stick. The first month after launch is when habits form, and an hour spent then keeps the site from going stale.

Building pages that survive the owner's edits is covered in a page layout that breaks when the owner edits it.

Frequently asked questions

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.