A year ago, my firm launched its long-awaited third generation website (www.gfrlaw.com). The project, majorly derailed halfway through for an intensive strategic planning exercise, took nearly a year and a half to complete. Our team was beyond excited to finally “go live,” but not without first thoroughly considering all of the things that could go wrong upon launch.
Here are seven tips when working through the quality control (QC) process and executing the launch that I've gathered from my own experience.
1. Check, check and check again.
When preparing for launch, quality check everything. As content is migrated from your existing site to your new site, strange things can happen, or things simply don't transition smoothly from one design to the next. Have a system for recording issues and tracking the resolution process. There are tools, such as InVision which allows users to flag issues directly to a staged prototype of the site and Bugify which tracks issues through the resolution cycle and provides updates, that your web vendor may use to assist with this process. We learned the hard way that it's easy for things to be lost in translation between your team internally, your account rep and the various designers and coders working on your site. Be clear and specific in your communications as you seek to resolve any issues you’ve encountered.
2. Bring in backup.
Recruit someone else from your firm who isn’t as in the weeds to take a look with fresh eyes. They are more likely to see the little things, such as minor formatting issues, and the big picture things, like navigational challenges from a user experience perspective. Use tools to assist with the QC process. We used a free online broken link checker to check for broken links and Typosaurus to check spelling.
3. Check your connections.
Make sure you have an analytics system, such as Google Analytics, connected to your new site. This may seem like a no-brainer, but it's easy to overlook, particularly if you are switching from one web vendor to another like we did. Our previous vendor tracked our analytics and had set up a separate Google account to do so. Naturally, that account was no longer active when we terminated that contract. It took us a couple weeks post-launch to realize that we were no longer capturing user data. Make sure this, along with any other outside services you may employ in conjunction with your site, are connected and ready to go upon launch, so you don't miss out on valuable data like we almost did.
4. Get on the same page, literally.
Our web vendor developed our site in Google Chrome, but we did not have access to that browser internally. We quickly learned that not all browsers are created equally, and, much like mobile apps launched with different operating systems, sites need to be tweaked for different versions of each browser. While I wouldn’t personally recommend Internet Explorer, we knew that our toughest critics, the attorneys in our building, would be using it to view our new, highly anticipated site for the first time, and we needed to make sure it was working perfectly on that browser. Tools, such as CrossBrowserTesting, can help you and your website vendor make sure your site is functioning optimally in all of the major web browsers and on mobile devices prior to launch.
5. Keep calm and clear your caches.
As you and your web vendor work through the QC process, remember to clear your caches often and before checking for updates. You’ll be on your site constantly, which means your web browser is constantly caching your activity. Before you freak out because your web vendor has yet again claimed that they’ve fixed a tough ongoing issue and you still don’t see a resolution on your end, take a moment to clear your caches. Chances are, that’s all it will take to see results.
6. Plan for ongoing updates.
Set money aside in the budget for ongoing maintenance. If your website vendor offers a monthly retainer, often at a discounted hourly rate, seriously consider it. Depending on how much maintenance is built in to your contract, chances are, you are going to need some additional work post-launch. Drupal, WordPress and other popular open source CMS platforms from which many custom sites are built are constantly updating. Think iOS updates on your iPhone. Now, hopefully these ongoing updates won’t cause glitches as drastic as the “A [?]” fiasco, but you should be prepared for something to go awry over time.
7. And even then, expect the unexpected.
We were lucky to have an amazing partner, idfive, to walk us through the launch and all of the above processes. However, as fate would have it, the day we launched, Amazon Web Services, our previous host, went down. I know what you’re thinking. How could Amazon Web Services go down? It happens – not often – but it happens. On the day of your launch, make sure you and your web vendor have resources on standby to quickly resolve any unforeseen issues.
Beyond these steps, your web vendor should have their own checklist that includes speed testing, spot checking for SEO-relevant tags, setting redirects where necessary, archiving your old site and more. To discuss these or other aspects of the website development project not included in this article, feel free to reach out to me at firstname.lastname@example.org or on LinkedIn.
By Ashley Smith Rosenblatt, Marketing Coordinator, Gordon Feinblatt LLC for the First Quarter 2018 LMA Mid-Atlantic Region Newsletter