Originally published on The Pastry Box October 3, 2015.
Six to eight weeks.
When I worked in tech support, that was the magic number. Six to eight weeks after the software upgrade, the support calls would drop off. Six to eight weeks after the elevation, the users would understand most of the navigation and tools, adjust to the typography changes, and understand the new processes. Six to eight weeks after we went live, we’d finally get to take a breath.
We’d catch the worst show-stopping bugs in elevation, maybe as late as a two-week warranty, but it still took six to eight weeks for the calls to die down.
Call it a reverse honeymoon period, if you will: the first 6-8 weeks after launch all the users hate everything. New logo? Childish. New navigation? Confusing. New font? Hard to read. New imagery? Asinine. The concentration of “your website sucks” messages during that time period is 10x that of a normal day.
People hate changing.
(They don’t actually hate change. Well, they don’t hate change that affects *you*. They hate change that affects *them*. They hate changing.)
After the reverse honeymoon period, something amazing happened: all the adjustment complaints melted away and the tech support calls that were left were all real problems. Usually not showstoppers. Usually subtle annoyances we overlooked when we were heads-down in the project. Usually easily correctable. But lost in the shuffle of the complaints and frustrations of the previous six to eight weeks.
***
As an industry, we used to elevate big changes once a year, and some companies still do. Apple releases one OS. Microsoft releases one version of IE. Everything else is bug fix.
The web world has moved from one major launch a year to one a quarter to one every sprint. Maybe not the same functionality – even the best designers take weeks to rebuild a wacky purchase process – but *something* goes up every few weeks.
We have an unprecedented ability to find mistakes, fix them, and elevate repairs, whether they’re in the requirements, the design, or the execution of the code. As soon as we hear of an issue, especially a hot issue, we can be on top if it.
That’s great! Except that our users haven’t scaled with the times. It still takes them six to eight weeks from launch until they relax into a new design, and during that time, they’ve got all the vitriol and panic necessary to convince a product owner that the launch is a disaster and everything needs to change right now.
A few years ago, the product owner would call and say “OMG THE FONT THEY HATE IT CHANGE IT RIGHT NOW,” and we’d say, “Well it’ll have to go up in the next elevation in three months,” and by the time we got around to actually coding the change, the users had relaxed, the product owner had relaxed, and hey, this really wasn’t such a bad after all, it was much more readable than the old one.
Today, we don’t have the luxury of the inflexible waterfall process to stop us from making reactionary changes. So we can change the font again, and again, or first the font, then the buttons, then the spacing…. because there’s nothing to stop us from constantly reacting to our feedback.
So I suggest this: heed your reverse honeymoon periods carefully. Remember your six to eight weeks. If silo A of your product is being upgraded, then as soon as that launch starts, move your development team to silo B, and stay there for at least 6-8 weeks, so that when you launch B’s changes, A has had enough burn-in that your tech support folks know what’s really wrong. Let your representativess do their jobs before you try to address the noise. Let everyone get through the 8 weeks of silo A’s problems before you launch silo B’s new upgrade, so no one’s taking a trip on two reverse honeymoons at once.
Respect your users enough to give them time to change.
And then when you’re done, buy those tech support folks some pizza or something. They’re getting yelled at about everything you screwed up, after all. And they’re doing it for six to eight weeks.