Jakob Nielsen's Alertbox, April 2, 2000:

The Mud-Throwing Theory of Usability

It has recently become popular to design new websites and innovative Internet services with the idea to throw it at the wall and see if it sticks. The metaphor of treating design like mud supposedly leads to shorter time-to-market and thus faster success in growing the business.

The assumption is that speed is everything. If the initial design has weaknesses (i.e., drops off the wall), then they can always be fixed in the redesign.

Well, speed is indeed important, but it is not everything. Customer satisfaction is everything. Launching a bad site with poor usability is a guaranteed way to waste money since it will have to be redesigned more or less immediately.

Launching a site that is difficult to use will deprive the business of its best customers: those that are so eager to use your service that they will visit the site as soon as they hear about it. If these users get a bad experience, they will not only be lost to you as customers, they will also be lost as potential future advocates for the site. In fact, any hopes of viral marketing will turn into a bad fever as infected users warn others to stay away from the site.

Once a user has had a bad experience on a website, it is very difficult to convince him or her to come back. Resampling is one of the hardest sells and will cost your marketing budget much more money than the modest cost of getting the website right in the first place.

Even though speed isn't everything, I agree that it is important in the fast-moving environment of the Internet. But it does not take very much time to dramatically increase the usability of a website:

As explained in my previous Alertbox, you only need to test with very few users in order to gain the vast majority of insights into the usability of a design.
With paper prototypes, you can get usability feedback at a very early stage of the design where nothing has been implemented yet and you have nothing but a few sketches of your proposed new service. So the testing does not need to delay the implementation.

In fact, testing with an early prototype of a future site will sometimes speed up the project and save you time as you discover that certain features are unnecessary or that things should be done in simpler ways than you originally thought.

In the traditional world of software design, it is a common lesson that it is about 100 times as expensive to make a change in the next release compared with the cost of making the change at the beginning of the project. On the Web, the theory goes that the cost of post-launch changes is smaller because of the lack of physical media (i.e., no need to ship new CD-ROMs to all the customers). This is true, but the cost of the added marketing to win back lost customers is probably much higher on the Web where users are more fickle and have more choice.

Other problems with the idea of "fixing it after launch" are:

You may not get around to fixing all the problems as new priorities take over: since it is so much more time-consuming to fix design flaws after they are implemented, the resources are often not there.
Users hate redesigns: even if the original design was miserable, those users who have suffered through the pains of learning it will rather continue to use what they already know than learning something new.

Instead of throwing mud at the wall, I prefer to gain some knowledge before the initial launch: this only takes a few days. Then fix the worst usability problems: this also doesn't take long if you have found them before you started implementing anything. The project will hardly be delayed, you will save hugely bigger costs of making changes later, and you will not scare off your best customers.

The Mud-Throwing Theory of Usability

See Also