Gawker’s recent launch of a new design may prove to be one of the worst redesign launches in the history of the internet. It not only sparked an outcry from users, but let to a massive drop in traffic for one of the internet’s most popular publishers.

In the face of what can only be described as an online publisher’s worst nightmare, Nick Denton, the outspoken head of Gawker, has been unusually silent. Until now.

In an email he sent to staff, he admits that “the transition was definitely more bruising for readers and our own staff than
it needed to be
” and discusses what is being done to rectify the situation.

The truth is that Gawker and Denton could have avoided their bruises. But Gawker’s pain is everyone else’s gain. Here are the eight lessons every organization can learn from Gawker’s missteps.

1: Don’t ignore Google

Gawker’s traffic plummeted following the launch of its redesign for one primary reason: SEO. Apparently, Gawker didn’t consider the SEO implications of its new design and has paid a steep price for it. Needless to say, a major design overhaul should always include an SEO analysis.

2: Client-side technology isn’t a panacea

Perhaps the most shocking thing about Gawker’s redesign technology-wise is the total reliance on JavaScript. As Scott Gilbertson at Webmonkey notes, “when a single line of JavaScript causes your entire suite of sites to fail you no longer have websites, you have, well, nothing.” Nothing indeed.

There are a lot of wonderful things client-side technologies like JavaScript can do, but there are limitations. In short, there’s no good reason to build a JavaScript-dependent site that can’t degrade gracefully if you want to run a successful web property.

3: Extensive testing is a must

To be fair to Gawker, its atrocious redesign wasn’t unleashed without any warning. Gawkerdid make available a beta version of the new site for some time. But making a beta version available is not in and of itself a real testing strategy.

On a property as large as Gawker, testing should always include focus group sessions throughout the design process and A/B or multivariate runs to obtain data from real-world usage across your entire audience, not just the subset which opts to try the beta.

4: Assumption is the mother of all…

One of the classics from Denton’s internal email is this:

We had thought mouse scrolling (via scrollwheels or trackpads) and keyboard shortcuts were enough for story navigation — an overly optimistic expectation to say the least. News web sites may indeed become more application-like and readers may grow accustomed to swiping instead of scrolling. But they’re not there yet, as the extensive criticism of the sidebar made clear.

Clearly, the people behind Gawker’s redesign were so focused on technology that they ignored fundamental user design best practices.

Assuming that you can get away with this simply because you have a ‘sophisticated‘, web-savvy audience is the type of assumption that almost always has a bad outcome. Bottom line: don’t rock the boat unless you’re prepared for it to tip over.

5: Be careful about outsourcing

Apparently, Gawker’s tech team is at least partially located in Budapest. Now, there’s nothing wrong with outsourcing (I’ve had very positive outsourcing experiences in the past myself) but outsourcing successfully — or working with remote employees/contractors anywhere — requires proper management.

Given just how badly Gawker’s redesign was fumbled, one has to assume that there was inadequate management of Gawker’s off-site tech team, even if that tech team basically did what it was told to do.

Tip: when working on something really, really important (such as a major site overhaul), bringing everyone together in one place may be advisable, even if it’s more expensive.

6: Only fools rush in

According to Denton, “…we thought that commenters could do for a few weeks without the fancier
functionality such as reply notifications.
” He thought wrong, of course, and moved ahead in taking away functionality from readers because “we had a rollout deadline to meet.

Taking functionality away from users is almost always a tricky proposition, and instead of rushing to get something launched, Gawker should have placed more importance on user experience than an arbitrary deadline. After all, there’s never a good reason to be in a rush to do something dumb.

7: Listen

Gawker’s beta testing of the new site resulted in an enormous amount of feedback, much if not most of it negative. Even if Gawker ignored every one of the five lessons above, it could have avoided tragedy by simply listening to that feedback. Instead, it apparently chose to hear no evil and see no evil.

8: Confidence is no substitute for competence

At an interview at a tech conference late last year, Denton expressed confidence that a long beta of the new design would mitigate the risks of a user backlash. He was also unconcerned by the possibility that someone else would copy the design. “Most organizations are way too sluggish to copy it,” he said.

Of course, the truth is now apparent: most organizations are way too smart to copy it, and Denton’s comment provides a somewhat humorous example of the limits of confidence when it isn’t backed up by competence.