Launching a new website – seven reflexions + suggestions

When I decided to write about some things to consider more generally when launching a new website or a redesign, it seemed like good timing because SDG was preparing to launch a completely revamped site as a multi-phased rollout over the next three to six months. The first phase proved to be more challenging than I anticipated due to some proprietary third-party technology we have been beta-testing. And that leads us to lesson #1.

Defend your calendar.

When preparing to launch a new site, avoid scheduling anything else. This may include saying no (or wait) to family and friends or that writing project you thought you would take on. (Following this tip could have saved me some extremely late nights this month.) It definitely should include postponing any new design projects, even though it’s tempting to think that since you’re already surrounded with graphics and code, it will be rather efficient to add a bit more to the stack. Beware! Despite having come a long way in the past five years, glitches and minor annoyances are common with today’s web browsers, not to mention the host of technologies you may be mashing up with your new site.

Line up additional eyes and ears.

Prompt a team of people to be ready to give you feedback as you near your launch. Fresh perspective is critical as you tweak and polish your site and content for a public launch. If it’s convenient, set up an email list or a group in your address book so you can fire off quick emails asking for feedback on your development site. Make this as simple as possible for you and for them. If you have the time, consider scheduling a face to face review where you can demonstrate the site using a projector or large screen and get immediate feedback before going live.

Use public notice templates.

Have some simple but elegant “public notice” templates in place in case you need to temporarily take down your site or “hide” certain portions of the site while the rest of it is live. Hold onto them because you may need to use them as you continue to tweak and polish the site. One of the most common reasons for launching a redesign is that the previous site is significantly outdated. If this is the case, consider putting together a very quick and simple site that keeps mission-critical information available, but also points to the coming redesign. Offer people a chance to contact you in multiple ways (email, phone) and consider putting a notification subscription box on the page so that site visitors can “sign-up” to be notified when the site goes public. Since I mention TypeKit in a slightly negative light later, here’s a great example of the kind of page I’m talking about. TypeKit has done nicely here.

Be willing to push back the launch date.

Unless there are compelling reasons to launch a site on a particular date, be willing to be flexible and communicate that possibility to your client throughout your development phase. Some site launch dates cannot be flexible. You have to know ahead of time the degree of flexibility inherent in your project. Do some risk assessment as early as possible (preferably before solidifying your project timeline). If a small project represents 20 hours of work, for instance, consider the possibility that deploying that third-party API could present an additional 20 hours of scrambling to smooth over integration glitches. Hopefully, all goes smoothly and the API integration only takes the five minutes you thought it would… but be prepared if it explodes on you.

Separate your essential features from your preferred ones.

If you know which features are absolutely essential to the launch and which ones could be implemented in the days and weeks that follow, you’ll be in a better place to handle unexpected diversions in your project’s roadmap. For instance, the new SDG site was slated to include TypeKit integration of the @font-face specification. However, the font rendering from TypeKit’s servers did not seem to work well or consistently across our site. It’s possible this is due to a limited understanding of how to properly integrate TypeKit, which is a new service released in beta right now. It’s also possible that the font files we chose from TypeKit are not properly formatted for consistent rendering. We searched for guidelines and contacted TypeKit for assistance, but in the end we had to pull the service and fall back on standard web fonts for the launch. TypeKit are clearly improving quickly, as this blog post demonstrates, and we hope to reintroduce TypeKit at SDG in a future phase. (Aside: I’m convinced that TypeKit has a very bright future for web designers and I’m grateful for their dedicated work in making the web a more beautiful place.)

Prepare your publicity channels.

Consider ahead of time who needs to hear about the launch and how that message can best reach them. If your communication collateral is ready to go at launch, then pulling the trigger on the site should cascade a series of communication triggers that will encourage people to pay attention (at least for a moment). Consider ways of capturing their ongoing attention with ways they can sign up for updates or news (or subscriptions to RSS feeds and podcasts) when they first visit. Those regular prompts will keep them coming back. In the case of the new SDG site, our primary publicity is tied to a future phase and not incorporated in the first launch. This is strategic for us, but probably not ideal for most projects.

Celebrate.

Find some appropriate ways to celebrate a launch, even if it is a quiet one. Gather some friends and family, your team, complete strangers and enjoy the fact that the web is now a more beautiful place than it was yesterday.