I can speak from recent experience, as the website I work for has undergone a radical front end redesign and in my past life as a Product Manager, and general internet monkey before that, I have been in and around websites undergoing radical front and back end redesigns as well as some new product launches to boot.
Now for the truth. They’re rather horrible experiences.
If the experience doesn’t in any way feel traumatic to you, you either believe too much in yourself/your product and you don’t care enough about your website.
The least traumatic of these possible experiences would be if you are launching an entirely new website from scratch. You don’t have an existing user base and you have nothing that currently works to break.
But, somewhere you will muck it up. It is a given, it is as inevitable as an England World Cup failure.
How big an issue this definite error might be will be down to some of the factors that I will expand upon below, and how you deal with that problem will entirely be down to your processes you have put in place prior to the site launch.
Hopefully some of this sinks in and you can avoid unnecessary stress and strain.
Know when the time to launch is right
One of the hardest parts of launching a new website will be knowing when exactly to release it out into the wilderness.
Just be certain that when the time is right, you will still never be 100% happy with your website.
If you are completely happy with your website, you are in the wrong job.
Working on a website should be full of doubt and unhappiness at the state of your site. If you are striving daily to improve your website in some form or other, then you are in the right job. You cannot simply stand still.
So with that mindset, knowing when to launch becomes difficult. There may be that button that irritates you, or even a bug that has somehow slipped through the net and is irritating you to the high heavens.
You need to weigh it up. Nobody can say “you should expect x amount of bugs and x amount of formatting issues”. Launching should be entirely qualitative.
These things may be so irritating to you that they make you want to pop to the toolbox and commit severe harm on your computer screen. But take a step back. one man’s irritant is another’s ignorance.
When launching our recent redesign I had a set goal that I wanted the basic functions of the site to perform to a satisfactory standard. Which is about as ambiguous as you can get, but also realistic.
If I could purchase a product through our website, thus completing the registration process at the same time, and found that it worked with minimum agitations from start to finish, then we were ready to go. Obviously it wasn’t that simple, but it sums up the thought process.
I am fortunate enough to say all of this sitting on a throne of digital luxury, not at one point did I have anybody apart from myself putting pressure on the job being finished.
The crowning glory to this is that I also had no other departments to contend with. Usually in these processes there is a sales team or an editorial team crunching their knuckles and rubbing them menacingly in your vicinity making sure that their issues are dealt with before launch.
These factors can really make a product launch incredibly difficult and I don’t envy anybody who is contending against these issues. The ability to manage multiple expectations successfully is a true gift, and if you have it please bottle it up and put it for sale on your brand new totally satisfactory, stress-free website. I’ll be the first in the queue.
A clear objective
You need to have a clear objective for what you want from your relaunch or launch and be realistic with it. You can’t have it all from the outset, it is definitely best to launch with a base to build upon.
I managed this by maintaining a simple spreadsheet of what issues were pre-launch or post-launch fixes based upon the fact that I wanted a purchase to be as easy as possible. It is such a simplistic methodology, but it puts things into black and white and makes you a bit more severe with what issues can wait.
There was a time when I worked with the MoSCoW method where a list of fixes are distributed to all relevant departments and each issue allocated a value of Must, Should, Could or Would.
It doesn’t take Gary Kasparov to work out how that one ends up.
Each department assigns any issues relevant to them as musts and shoulds. Anything involving external parties tends to be allocated a could or would.
Finally, a big meeting occurs where nobody leaves happy, the digital team have too many musts and every department feels they need more.
Funnily enough the best advice I got during the whole thing was right near the end when a friend of the company (a retired mechanic from Italy, in his 70s) summed it all up in one simple sentence.
Old vs New:
“If it’s better than the old one, then what are you afraid of.”
How right he was. In the digital world we often get too wrapped up in the tiny detail of it all.
Test, Test again. Then test it all over again
You’re probably expecting me to say that there is no excuse for launching a website with any bugs, but that would be impossible (if you have achieved this, please place for sale on the same page as the managing multiple expectation tonic).
What you should be aiming for is to launch without any bugs that you don’t know about. This goes firmly hand in hand with Step 1. Bugs aren’t always critical, if it doesn’t affect the main goal or goals of your website, then it can wait.
It seems ambiguous to say you should know about every bug, but if you have tested your site as thoroughly as you should then you should be aware of most of them.
If you employ a QA to test your site, don’t rest on your laurels, a QA is generally a technically minded being who doesn’t necessarily understand the day-to-day business of your site. You do. Therefore you should be testing too.
One of the toughest things to contend with in the testing stage is the huge amount of diversity in web accessible technology. Pick those that are relevant to your users and test against all the significant combinations.
If you don’t know how to find this information then please get yourself stuck further into your analytics package – don’t expect to know it off by heart, but use it to help make testing decisions.
Knowledge of browser user and popularity can make your job easier. If there is a bug you find in testing that you feel could hinder the launch you can refer back to the amount of users it would affect and potentially downgrade it to a post-launch fix.
We had a predicament with Chrome on mobile devices, initially it was disruptive to the purchasing process and panic set in as it seemed large enough to affect launch.
A quick bit of investigation into our analytics showed that we were looking at a really small set of our users, and further investigation found that this issue was actually already occurring on the current site.
From there we decide a quick fix of CSS changes and some relevant wording in case of the issue popping up were a sufficient solution in the interim. Rather than delaying the launch we actually managed to create a workaround to an old bug and park it for a later date.
It is really important that you don’t go into testing thinking that Internet Explorer 10 covers testing for your older/newer IE version users.
Sadly, older versions of Internet Explorer can throw up completely different results to each other, a massive oversight from Microsoft in not making upgrade compulsory.
If you want evidence of this fact I’d like to hazard a guess that your IE10 user base is much smaller than your IE11 userbase, the first time automatic upgrades came into effect.
In summary, if you aren’t sick of doing the same processes on your new website then you haven’t tested it hard enough. I can now purchase switches and sockets in my sleep, but thankfully its helped avoid the nightmares.
Take a look at this custom browser report for Google Analytics to help you spot how influential each one is for you.
When I see mistakes on other new sites I tend to be much more understanding in the early stages, however find it baffling how large companies (hopefully with large digital teams)do not spot them sooner, and if they stay unresolved for a while, why somebody isn’t fixing them.
Homebase is a really good example, they have a new website which is clearly geared towards the 2014 school of flat, responsive design.
A huge flaw I spotted on first use of the website is that the page navigation on product listing pages is extremely temperamental. Sometimes I can get to a different page of results from the first page, sometimes not and even when I’ve successfully gone from the first page to another I can’t get back again.
I’m not to know the inside workings of Homebase, somewhere a decision has either been made to fix it at a later date or the issue hasn’t been picked up on yet.
There could be a multitude of reasons for this not being fixed yet, but to me it screams of a lack of knowledge of the site and a lack of testing as it is enough of a barrier to sale for a launch delay.
Nice new site, malfunctioning new navigation.
Think of it this way, you have 50 products to sale in a category and the user can view only 25 of them. You’ve halved potential sales already.
Throw in the fact that a user has a high chance of exiting your site. They’re trying to navigate further because they haven’t found what they’re looking for. They may as well navigate to a competitor who can provide them more choice.
Initially I tested this on an Apple Mac. If we were to have an issue like that on our site, then we’d be running the risk of that bug affecting 90% of Apple Mac users on our website.
Surprisingly they only make up 10% of our users, however they also make up 20% of our purchases and are our highest converting users. This trend isn’t a surprise.
Frighteningly after further testing I found that this occurs on Chrome on Windows 7 too. You can safely assume that, after some quick and easy testing, at least 25% of users can’t navigate through product listings pages sufficiently.
Homebase has roughly 330 physical stores, this is the equivalent of going to 83 of these stores to find you can’t see half of their products.
When finishing testing, if you’re not sick of doing the same processes on your new website over and over again then you haven’t tested it hard enough. I can now purchase switches and sockets in my sleep, but thankfully its helped avoid the nightmares.
You know nothing. Everybody you work with knows nothing
Obviously in your head you know everything, whilst the second statement still applies.
When it comes to site design you really don’t know anything until it gets released.
I know nothing!
Of course you will need to use hunches and common sense, and if you are relaunching you must be decision making based on data from the current version of the site. If you are building an entirely new being then that becomes much trickier.
Until the product is out in the wild you cannot be vindicated, or proven wrong, until the users have had their say.
As a product owner the more diplomatically you can convey this fact, the easier your job becomes – and the more development friendly too.
If you have the resources then you should be testing with a select group of users before hand, but even that comes with its pitfalls.
On an old project we set up a group from the community to test a mobile website, from their feedback at the wireframe stage went and developed the tangible product in beta form.
Only then did they suggest that it wasn’t right and not very user friendly. They were absolutely right, but there was huge frustration from that fact not being picked up at an earlier stage.
We were led to believe that the product was suitable for the hardcore users of our website when the reality was different.
I personally feel that this was down to the face-to-face interaction during the first stage of testing, we learned some valuable lessons but we didn’t get that honesty we got once users were back behind their screens. On a positive note we had the guts to start all over again and get it right.
Before this latest refresh, when asking for feedback internally I was brutally honest – you know nothing, I know nothing, we will only have answers once the product has gone live and our users have spoken.
It may sound like passing the buck, but the users are the ones you are building the website for, there is no point pandering to internal pressure to make it the way somebody perceives the right way of doing something.
It is also a fantastic kill switch for those “i think this button should be a bit redder” kind of requests that come up.
You need to know everything
This is isn’t really a survival tip for launch, but good preparation for the difficult and tense period just after deployment. You must have analytics tagging on everything, everywhere.
If you can’t find out the answers to any possible user interaction, then think about holding off with deployment. These kind of jobs are always the ones which development teams see as minor and manage to push to the back of the queue for larger tasks.
If you are to develop and grow your website in the future you cannot do it based on guesswork and fingers in the wind. Analytics tools are your friends, and they should be your best friends, because your best friends don’t keep secrets from you.
Moving from an old iteration of our website, which to be fair was tagged to a good standard, allowed me to tag up some areas of the website we had never previously tracked.
Take our homepage slider, which in development took up a large segment of time owing to its prominence and screen real estate.
The sensible option here would’ve actually to have spent the couple of hours it would have taken to add tagging to the current (now old) home slider and learned about its importance to the user. It harks back to my point before, I clearly know nothing.
Now it is all tagged up the reality is that interactions are minimal and the real estate and prominence don’t influence traffic to those highlighted areas as I would’ve hypothesised.
It doesn’t mean that I wasted time, it just means that we need to think about that area of the site and its use in the future. Something we would’ve known earlier had we tagged it up earlier…
Know when the time to launch is right
By the time you have reached this point I imagine you think that I’m merely going mad and repeating myself. I’m not.
Knowing what time to launch isn’t simply about ticking a load of boxes.
Once you have gotten to a stage where you are only slightly irritated by the imperfections you need to have a serious thought about what time and day you should deploy.
This is a very simple one. Research which day and time will cause the least disruption to your users.
Please don’t think that launching at your busiest time will be the best idea because you can really test the capability of your site against the severest of conditions.
Whilst you want to scream and shout about your new website, most people really won’t care about it. Especially your new visitors as they won’t have a clue what the old website looked like.
Our best time for launch was 10pm on a Friday night. We made sure that traffic was at a minimum and we hit the big red button (which we had to picture in our head as we couldn’t source a big red button in time).
This allowed us a couple of hours that evening to fix things we had put at the top of our post-launch fix list, and the grace of Saturday morning to fix even more.
I have touched upon the unsuccessful launch of a previous product before, with that we had the ignominy of launching just before lunch. The busiest time of day with thousands of active users live on the site.
Its a lesson in bravery and is fantastic for weeding out as many bugs as possible in the quickest time possible, but that’s not actually what you want. This helps to create an unmanageable situation.
Add to the fact that the site was hugely unpopular externally, something to do with the extremely partisan users, and was also functionally poor at first launch it really was a rather stressful situation to be involved in.
Fortunately, at second launch mistakes were still made but we learned a hell of a lot from the first experience and managed to come out of a throughly difficult time.
If you are in charge of a digital team, I seriously advise you to allow them days in lieu to work through the quieter periods and launch then. Pizza also works well.
Expect the unexpected
You’ve followed as many “10 tips on launching a website” articles and read this one through and hopefully taken heed of some of the points.
It’s still going to go wrong somewhere.
Even if you have tested, tested again, started over and tested all over again.
You can never recreate every possible user set up, you are competing with the fact that there is so much diversity in hardware used to access the internet, let alone the actual browser possibilities that are even harder to mimic.
Add to the equation settings differences, extensions and add-ons, then it becomes a lot easier to understand why you or your digital team didn’t spot something first time round.
For example, on one relaunch we found that people using ad-blocker weren’t seeing images for products for sale on the site, simply because we included the word advert in the image filename. None of us used ad blocker internally, and we only found this post launch.
For a simple extension to be able to cause such issues causes an almost impossible replication scenario.
On this launch we were made aware of an issue with payment where our mobile friendly number input for security codes managed to remove a leading zero in cases where the security code began with zero.
A frustration as it affected the most important part of the site – the bit where we take our users hard earned, but understandably missable and something we still couldn’t replicate. Thankfully the internet is full of benefactors of knowledge, and people who have shared experiences, and we managed to resolve it easily.
There’s no such thing as over
That’d actually be a good title for this mammoth piece.
In all seriousness though, if you release your website and are sitting back thinking that you’ve done your job then you are seriously wrong.
A product launch or a site relaunch should be seen as a base to advancing towards bigger and better things.
At the start of this blog I suggested that if you are 100% happy with your site then you shouldn’t be. That extra percent of doubt or unhappiness is what you should always be striving to complete, whilst knowing that you will never achieve it.
I didn’t particularly plan on redesigning the website initially but we had some outside help from a company friend who offered to mock up a potential new look for our ageing website.
At this time I was A/B testing on the old platform and decided to pack it in entirely. This was because I knew that with the redesign I’d have a better base to test from.
You should always be thinking of how you can develop your site further.
Sitting still gives the competition an edge, honing what you’ve got keeps you in touching distance of the next site just like yours that is either launching or refreshing. You must A/B test. It’s a wrench because you’ve spent so long designing and developing your site only to go away and change it again – but the site isn’t yours, it is your users. Do it for them!
If like me you are working on an e-commerce site then you have it easy, we have that one simple KPI of selling products to keep us going.
People who have advertising revenues and editorial targets to think of have a much more difficult job. From experience in this scenario I’d say please don’t rush into adding a huge range of new sections to your website, develop what you have and make them the top of their pile.
This is now actually over…
Hopefully you’ve made it this far and digested some of the suggestions.
I’m fully aware that there are many mitigating factors in every single website launch or redesign, and many things to compete with. I also know that whilst I profess all these maxims I am running a website which contains many flaws.
But that’s how my website needs to be, if I’ve got nothing to improve upon then I may as give up now.
Comments