Menu Search
Jump to the content X X
Smashing Conf New York

We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. upcoming SmashingConf New York, dedicated to smart front-end techniques and design patterns.

The Lost Files – The Ultimate Web Design Questionnaire And Checklist (part 8 of 8)

Advertisement

← Bug Test, User Test… Just Plain Test (7/8)51TOC6273

Stage 8: Launch

It’s launch day. Are you ready? Before launch, check that the domain and hosting space are set up properly (setting up a quick landing page will confirm this). If the client has a dedicated systems person, liaise with them a few days prior to discuss the launch plan. They should be available in case anything goes wrong.

If you’re in charge of the launch, make sure you have access to the files online and that you know what to do.

Are you backed up? Before launching, store back-up copies of the old website (if there is one) and the new website. You never know when the client will need some old material. Also, should something bad happen to the website, having a back-up would be a lifesaver.

When to launch? Ideally, you should launch after all of the testing has been completed and you have had at least a day to put out any fires. For many, this means never launching on a Monday or Friday (although this is never a consideration for the weekend code warrior) and definitely not the day before a vacation.

If it’s a high-traffic website, identify the quietest time (usually early morning) so that you lose the fewest visitors possible.

Website’s up! Party time, right? Not quite yet. Once the website is up, it’s time to test again. In content management systems, sometimes the URLs still point to the test website. Also make sure that all of the pages and functionality work. And delete any test data that you created while building the website.

Is the client happy? Everything’s up now. It’s time to go through the website one last time with the client. Summarize where you’ve stuck to the specifications and where you’ve added little extras. Go over with them the testing and analytics. If they are impatient to start the next step, then explain the reason for the delay (which is that you have to see how the website performs).

Do:

  • Pick a date and time to put out fires
  • Put a back-up in place in case everything goes wrong
  • Give the client a precise ETA but with some margin for error
  • Reward your team for a job well done

Don’t:

  • Go on vacation on the day of the launch
  • Ignore the client because they’re driving you insane

Launch Checklist

This is it. One last run-through to make sure you haven’t missed anything. If you miss any of these items, there will be repercussions. Remedy any outstanding issues as soon as possible.

  • Check the usual suspects: for example, are you using the right DOCTYPE?
  • Is the right character set defined?
  • Does every page have a page title?
  • Have you gotten rid of unnecessary class and id names?
  • How semantic is the code?
  • Any JavaScript errors?
  • How does the website look on mobile devices?
  • Do the print style sheets work?
  • Does the website work in smaller browsers?
  • Have you included 404, 500 and 503 pages? Do they provide a feedback mechanism?
  • If required by law, do you provide terms and conditions, a privacy policy and a refund policy?
  • Can you return to the home page from every page?
  • Are links and non-links easily distinguishable?
  • Is a link’s visited status obvious?
  • Does the website work with and without the www?
  • Do you have a favicon?
  • Is the domain ready? Changes can take as long as 24 hours to propagate, so give yourself at least this much time to fix problems.
  • Have you set up the database properly? If you have ported it from the test environment, have you changed the URLs?
  • Have you backed up the old website?
  • Have you removed all test data?
  • Have you fixed all broken links? Broken links not only annoy users but can affect search engine ranking.
  • Are the page sizes small and the loading times fast.
  • Will someone look through the website as soon as it’s up?
  • Have you submitted the site map to the major search engines?
  • Have you installed analytics?

For a more compact checklist, check out the “Ultimate Website Launch Checklist4”, created by the folks behind BOX UK Design agency.

Conclusion

Making a client happy is hard work; you’ve got to almost take on the role of a project manager to do it. Many of us have skipped steps because we couldn’t be bothered, and sometimes the websites have turned out fine. Most of the frustration with clients comes from a lack of communication: you have either not listened to them or not explained how the Web works and how you work.

Ask the important questions, and don’t be shy to talk about money. Your client is running a business, too, and that’s how business is done.

Be conservative with your time estimates (everyone gets it wrong after all). If it takes less time than you anticipated, you can always add more detail and joy. If it takes more time, then you’ll just have to burn the midnight oil. You are responsible for delivering on your promise (and hopefully next time your estimate will be more accurate).

If features are added, then adjust the time frame and budget right away; expecting you to do more work for free would be unfair of the client. It also wreaks havoc on your schedule, and you could end up having to push back a project with another client if you don’t get the feature creep under control.

And even if you do everything right, there’s no accounting for bad clients. So, get everything signed and get your down payment. Having to fire a client is unfortunate but sometimes necessary. Always be professional, and protect yourself.

“Forgetting” the details is easy with awful clients, too. Just remember that the details reflect on you. Whenever you create elegant URLs or write flexible code for mobile devices or design beautiful error pages, you are saying to the world, “I care about doing a good job.” Continue to strive for accessible, beautiful design, always.

← Bug Test, User Test… Just Plain Test (7/8)51TOC6273

Footnotes

  1. 1 https://www.smashingmagazine.com/the-lost-files/the-ultimate-web-design-questionnaire-and-checklist-part-7-of-8
  2. 2 https://www.smashingmagazine.com/the-lost-files
  3. 3 https://www.smashingmagazine.com/the-lost-files/interviews-expert-tips-from-renowned-designers-part-1-of-4/
  4. 4 http://www.boxuk.com/blog/the-ultimate-website-launch-checklist
  5. 5 https://www.smashingmagazine.com/the-lost-files/the-ultimate-web-design-questionnaire-and-checklist-part-7-of-8
  6. 6 https://www.smashingmagazine.com/the-lost-files
  7. 7 https://www.smashingmagazine.com/the-lost-files/interviews-expert-tips-from-renowned-designers-part-1-of-4/
SmashingConf New York

Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf New York, on June 14–15, with smart design patterns and front-end techniques.

↑ Back to top Tweet itShare on Facebook

The Smashing team loves high-quality content and cares about the little details. Through our online articles, Smashing Books, eBooks as well as Smashing Conferences, we are committed to stimulating creativity and strengthening the web design community’s creative forces.

Advertisement
  1. 00

    No comments have been posted yet. Please feel free to comment first!
    Note: Make sure your comment is related to the topic of the article above. Let's start a personal and meaningful conversation!

Leave a Comment

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that all fields are mandatory, comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or else it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

You may use simple HTML to add links or lists to your comment. Also, use <pre><code class="language-*">...</code></pre> to mark up code snippets. We support -js, -markup and -css for comments.

↑ Back to top