When it comes time to completely redesign a website, there are several phases every team goes through. There’s the initial excitement created by the promise of old headaches being resolved and new opportunities created. There’s the spark of creativity as new ideas are proposed. There’s the heightened camaraderie as teams come together to complete the work. And there’s the exhaustion and stress that comes from the inevitable rush in the weeks before launch. Then, all too often, there’s the intense disappointment that comes when the new design underperforms expectations—or even old designs. After passing through the process there’s considerable fatigue with the latest version of the site and, as a result, what was meant to be new already feels old.
There is an alternative to this all-too-common approach to redesigns. Instead of making arbitrary decisions based on design fads, internal preferences, interdepartmental politics, and unsatisfying compromises you can test into a redesign—evaluating the performance of each new element individually before it is incorporated into the final design. We all know this is the “right” way to do a redesign, but often the approach is rejected as being too resource intensive and time consuming.
Before such criticism is accepted, however, it’s important to think about this: If you don’t have the resources to do a redesign the right way the first time, where will you find the resources to fix problems after the launch?
At the very least, learning from tests on the existing design should be compiled and reviewed as part of every redesign brainstorm. Using this library of knowledge and experience can help you focus redesign efforts on the most important user behaviors and the page elements that impact consumers most directly.
Even better, key design changes—those that most significantly change conversion flows or user behavior—can be tested during the development process. Since these elements will have to be built and tested for functionality by the product team anyway, it makes sense to test them for performance with live customers as well. By encouraging the use of prototype code and utilization of a test QA process that meets the requirements for implementation, you can help build support for this type of testing among product groups and IT since it effectively supports to their development process.
Generating enthusiasm at the beginning of the redesign process can be difficult—typically, teams are excited to jump into the fun part of the process involving brainstorming and creating a new site. But by aligning testing efforts with redesign efforts early, you can help inform the ultimate design in a way that is supported by data, backed by verifiable results, and is more closely attuned to consumer needs. It’s not a matter of trying to find a way to fit testing into the redesign process; it’s more a question of how you’ll be able to respond to unexpected reactions to the redesign if you don’t. Testing through a redesign doesn’t guarantee a problem-free launch but it certainly reduces the severity of problems—and the cost necessary to fix them—when they do arise.