Consider the dashboard of your automobile.
Aside from a number of extras that have crept in over the decades, it's essentially configured the same as the dash of the car you drove as a kid.
In fact, the design of the automobile's critical controls hasn't significantly altered since the Model T Ford. It's worked for more than 100 years, and we love it.
What if the next vehicle you took for a test drive looked like this:
Seriously, would you buy this car?
Yet as the users of Web sites, we face this sort of interface mayhem all the time. And as Web developers, many of us have sprung these same massive redesigns on our users again and again.
Major Web site Re-Launches, or Big Rollouts (see Jared Spool's article The Quiet Death of the Major Re-Launch) largely have their roots in the world of paper publishing, where it is comme il faut to push out new editions of publications in toto at various time intervals. Just as organizations crank out the Annual Report on a different kind of linen paper in some interesting new geometrical shape each year, so shall the Web site recieve a "refreshing new look" so that appears to be part of "our family of publications."
Big Rollouts also echo the mantra of massive software rollouts: Windows 95... Windows 98... Windows 2000... In the mid-1990s, when I first began administering Web sites, the going wisdom was that all sites should undergo thorough reevaluation and redesign every six months(!)
This madness is coming to an end, thank goodness. The Web development community is learning to let go of design for design's sake and focus on accessibility and usability. Perhaps more important, we are beginning to convince our clients that this is the preferable approach.
To begin with, big rollouts (especially frequent ones) send the wrong message:
Big rollouts drive users crazy. See, there's a little thing that goes on among Web site users: they help each other out. The novice users ask a lot of questions. The experienced users show the novices around. The first time I sold something on eBay (it was a 1973 Ford Galaxy, by the way), what did I do? I talked to a bunch of guys who sold cars on eBay.
Take a site and run it through a major redesign, and this is what happens: Now the experienced users are just as lost as the novices. Everybody has to start all over. Run it through a major redesign again in a year or so, and the whole mess repeats.
Big rollouts also take their toll on the institutions perpetrating them:
A major site re-launch can almost always be avoided. About the only case in which it is truly necessary is when a site is in such disarray that every layer - architecture, technology, organization, navigation, content - needs to be burned to the ground and resurrected.
Fortunately, the underlyng technologies that drive the Web, along with the skills and ethos of Web developers, are maturing to the point where there is an alternative that serves everyone, internal and external stakeholders alike.
Stay tuned for Part Two of this article...
Aside from a number of extras that have crept in over the decades, it's essentially configured the same as the dash of the car you drove as a kid.
In fact, the design of the automobile's critical controls hasn't significantly altered since the Model T Ford. It's worked for more than 100 years, and we love it.
What if the next vehicle you took for a test drive looked like this:
Seriously, would you buy this car?
Yet as the users of Web sites, we face this sort of interface mayhem all the time. And as Web developers, many of us have sprung these same massive redesigns on our users again and again.
Major Web site Re-Launches, or Big Rollouts (see Jared Spool's article The Quiet Death of the Major Re-Launch) largely have their roots in the world of paper publishing, where it is comme il faut to push out new editions of publications in toto at various time intervals. Just as organizations crank out the Annual Report on a different kind of linen paper in some interesting new geometrical shape each year, so shall the Web site recieve a "refreshing new look" so that appears to be part of "our family of publications."
Big Rollouts also echo the mantra of massive software rollouts: Windows 95... Windows 98... Windows 2000... In the mid-1990s, when I first began administering Web sites, the going wisdom was that all sites should undergo thorough reevaluation and redesign every six months(!)
This madness is coming to an end, thank goodness. The Web development community is learning to let go of design for design's sake and focus on accessibility and usability. Perhaps more important, we are beginning to convince our clients that this is the preferable approach.
To begin with, big rollouts (especially frequent ones) send the wrong message:
- We're more interested in changing designs than addressing user needs
- We're more interested in changing designs than providing good content
- We're basing our designs on internal decisions, politics, and whims rather than on user requirements
- We're treating our Web presence like print media
- Our priorities are constantly shifting
- We're not exactly sure what to do with our Web site.
Big rollouts drive users crazy. See, there's a little thing that goes on among Web site users: they help each other out. The novice users ask a lot of questions. The experienced users show the novices around. The first time I sold something on eBay (it was a 1973 Ford Galaxy, by the way), what did I do? I talked to a bunch of guys who sold cars on eBay.
Take a site and run it through a major redesign, and this is what happens: Now the experienced users are just as lost as the novices. Everybody has to start all over. Run it through a major redesign again in a year or so, and the whole mess repeats.
Big rollouts also take their toll on the institutions perpetrating them:
- They tend to become unweildy and disjointed over time.
- They take months to accomplish - often well over a year.
- Because of this, they're likely to become obselete even before the launch date.
- They consume vast quantities of resources.
- They frequently require content freezes.
- OR they require the simultaneous maintenance of the same content on two parallel sites.
- Because they are huge and expensive projects, they naturally become high-profile. Among other dangers, this can lead to a deadly case of Design by Committee.
- They bog down Web teams, diverting them from issues that deserve immediate attention.
- They can lead to a proliferation of sitewide mistakes.
- They're hell to manage.
- They're hell to troubleshoot.
- They're hell to document.
A major site re-launch can almost always be avoided. About the only case in which it is truly necessary is when a site is in such disarray that every layer - architecture, technology, organization, navigation, content - needs to be burned to the ground and resurrected.
Fortunately, the underlyng technologies that drive the Web, along with the skills and ethos of Web developers, are maturing to the point where there is an alternative that serves everyone, internal and external stakeholders alike.
Stay tuned for Part Two of this article...