"It had been a difficult few months for the team. Not the usual we-busted-our-butts-and-finally-shipped difficult -- that had happened months before.
No, this was a different type of difficult. Let's just call it a we-launched-and-our-company's-revenue-dropped-thirty-percent difficult.
The team took a gamble with a radically new design, something that was supposed to dramatically improve the shopper's experience. It didn't. It made it worse. Now, they were paying the price.
Is Failure Always Bad?
It's easy to conclude that teams should avoid failure at all cost. After all, nobody wants to the be the ones who sit alone in the cafeteria, hearing the whispers of "those are the Ones who messed up."
However, if you look at all the great innovation that's occurred over the centuries, one pattern quickly emerges: failure played an integral role. We need to fail to learn.
When we succeed, we usually know we've succeeded, but we can't pinpoint why. Which step or element was the key to our success? It's very hard to learn from success. Especially the how-do-we-do-that-again lessons that are essential to long-term growth.
Failure helps us hone our skills much better than success. When we fail -- and take the time to learn from our failures -- we discover what we need to improve. As the saying goes, the largest room in the world is the room for improvement.
We want to fail. We just want to do it in a way where we've minimized the risk.
The Slow-And-Steady Approach
Amazon.com recently made a huge change to their system, one that could have had catastrophic consequences, had they not controlled the risk. Amazon sells almost $12 billion each year. A design change that doesn't go right, even for a day, could be worth millions of dollars to them.
When the designers at Amazon decided last summer to launch their new navigation system (finally ditching the tabs they’ve had since they first launched), they were naturally cautious. All eyes were on the numbers and nobody wanted to see an "improvement" sink the company.
What resulted was one of the most conservative design launches we'd ever seen. It started by identifying the "least risky" customers. They picked folks who weren't known to the system, because they didn’t have a cookie for the site. (Users with cookies get Amazon's trademark personalized welcome message.)
When the team was ready to launch, they let only a small portion of the non-cookied visitors see the new navigation. Once they felt comfortable that these people were succeeding with the design, they slowly opened the valve, giving more visitors that were non-cookied access to the new navigation.
After weeks of only non-cookied visitors, Amazon started to slowly give access to the more loyal (and cookied) customers. Even here, they didn't rush, taking several weeks to make the entire transition.
While it took time, the Amazon design team minimized their exposure by slowly rolling out the new navigation. If a failure were to result, they could contain it early. Only when they were comfortable, did they open it up to more users.
A slow rollout is one way to mitigate risk. There are other ways too.
For example, paper prototyping is a great technique. By building the interactive model out of paper and trying it out with potential users, you collect solid feedback about the design early in the process. Here, the risk is building something you're going to throw out or spending time on feature implementation that ends up not being important.
A fast iteration process is another risk mitigation technique. When done well, each iteration produces information about the users and their needs, which the team then feeds into the next version of the design. The faster the team goes, the sooner the design evolves into something the users will love." (Continued via UIE, Jared Spool) [Usability Resources]