Originally published: Aug 30, 2007
Lately, we've had a flurry of clients contacting us about their latest redesign project, wanting to know what advice we can give them. We talk to them, discussing their team's needs and what is driving the redesign effort.
In many cases, we discover the team is thinking only in the short term. Of course, because they have immediate deadlines and resources to manage, they need to focus on what's happening right now. The short term, after all, is where we all live day-to-day.
We've spent the last five years studying teams involved in major redesign efforts. Some teams regularly produce innovative, user-satisfying enhancements to their sites. Other teams work hard, but their efforts result in expensive changes that, after all is said and done, don't really enhance the user's experience or help the business.
As we analyze the difference between these two types of teams, we've noticed a pattern: teams who focus on the long term are far more likely to create designs that really pay off for the organization. Short-term thinking gets the design done, but the team ends up doing it all over again months down the road. Long-term thinking deals with the inevitability of changes and turns the site into a living, breathing entity that grows with the organization's needs.
In our research, we've uncovered seven essential long-term components to reach a successful redesign project.
We suggest clients look five or ten years into the future and ask the question, "What will using our site be like on that date? What experience will the user have?" Team members from the best organizations can answer this question. They have a consistent, clear idea what the user's experience will be like in the future. Having a clear vision lets the team chart a direction for their design, helping identify if any design idea is moving them closer to the vision or farther away.
It's critical the vision not focus on future technology but instead on future experience. What are the steps in today's process that makes things cumbersome or frustrating? How could the experience become more delightful?
One of our financial services clients constructed a vision where banking clients easily manage all their money and credit from a single screen, or can simply check their financial forecast from their mobile phone when, say, deciding if they can afford that new car, while simultaneously getting competitive quotes for insurances and car loans from their primary institution. While it would be impossible to do this with today's legacy infrastructure, it's possible to see something like this 10 years from now. The design team, using this vision, can then work in baby steps to getting as close to it today as the technology will allow. As the technology improves, they can get even closer.
To successfully redesign, you need to know who is using your site and what they are doing with it. You need to know what is currently working well and what is broken.
The number of established web sites embarking on a major redesign, whose designers have never watched any users actually work with their current design, constantly surprises us. Add that to the number of relaunched sites we see where the designers are surprised by the negative reaction of their users. What you get is a group of organizations that need to spend more time with their users.
When preparing for a redesign of their site, many teams have no trouble spending hours in meetings to talk about what the new design should do. Our recommendation is those teams make sure they spend the same amount of time sitting with users watching them work with the existing design. Teams that do this produce substantially better results.
Some teams struggle to make significant changes to their sites, while other teams regularly push out enhancements with ease. Probably the most striking difference is how big the projects are.
The most successful teams know to keep their projects small. They don't attempt to redesign everything about the site in a single launch; instead, they work on one small section at a time.
When the team tackles a large project, they end up with complexity at all angles: the scope of functionality is larger, the number of stakeholders is larger (each with their own concerns), the number of personas the team is designing for is larger, and the risk is much higher. If things don't go as planned, it's a huge problem for everyone, often with more visibility in the organization than the team would like.
Teams that only focus on a small portion of the site at a time reduce the number of stakeholders, thereby making it easy to satisfy their needs. They reduce the number of personas, thereby giving them the time to ensure they've covered the edge conditions -- those details that make or break a design. And, they substantially reduce the risk -- if things don't go well (and they frequently don't), it's easier to roll back to the previous design.
Reducing scope has another advantage for these teams: they see results faster. New designs can pop up in just a few weeks, giving immediate feedback on what works and what still needs effort. The team immediately applies what they just learned into the next little bit, making each part of the overall redesign smarter and better with every new portion.
Another striking difference we see in our research results: the best teams are less likely to hire outsiders to do their designs. Instead, they work hard to ensure they have the right skills in-house.
It may sound great to hire a top-notch design firm, but what happens once the project is done? Will they continue to make the millions of little changes required to keep a production site working? Who will make the inevitable changes, updates, and enhancements?
It's usually too expensive to keep using outsiders for the continual care and feeding a quality web site requires. Yet, the unsuccessful teams typically don't have internal resources to help with making changes and enhancements. In the long run, the site begins to decay and becomes a liability to the organization -- something everyone is embarrassed to send customers to.
In a strange irony, the pattern we see from the struggling organizations is their solution to a decaying web site is to repeat the process all over, doing exactly what they did last time, hoping it will be different this time. The successful teams look to their long-term needs and invest the same money into having the skills on site, giving them the flexibility to constantly update the site as the business grows. They only use outside firms as an extra set of hands, to make the larger changes faster.
The CSS and xHTML standards are the successful teams' best friends. Careful application of the standards can dramatically shorten the time it takes to make changes down the road, because radical design enhancements can happen by only tweaking the definitions of the styles.
Even if a site didn't start out as standard-compliant, it's worth the effort of slowly converting it. As areas are redesigned (in little bits, remember), changing them over to be standards-compliant is an effective approach. Every new redesigned area helps improve the team's skills in using standards, thereby making the next area even easier to convert over.
Most teams we talk to have an internal plan for changing to the new design. They think about what servers will need updating, which internal processes will change, and how they'll break it down into a manageable launch process.
However, we've found only the successful teams give as much thought (or more) to how the users will experience the change. Will they just log in one day to find an entire new experience or will the change slowly happen over time, almost imperceptibly?
Yahoo! Finance, for example, has been slowly converting users over to their new chart functionality. The new charts are greatly enhanced and users love them. Yet, many existing users, visiting the site multiple times a day and busy with their goals, can't easily stop and learn the new charts. For them, they can continue to use the old functionality for a while. In time, Yahoo! can assess the risk of changing the functionality out from under these users versus the cost of supporting both interfaces.
In a conversation we recently had with Gerry McGovern, he talked about his experience working with many teams in the redesign process, which matched our research results. He noticed many teams approach the redesign process much like they'd approach the design of a brochure.
Designing a brochure has the advantage that, at some point, it is printed and delivered. Once that happens, it can't be changed -- it's done. The only thing is to start over with a new brochure.
Gerry noticed in his travels this attitude, when applied to web sites, is what got many teams into trouble. They thought they could think about a new design, implement it, then pay attention to other business, not giving the site any further attention.
Unfortunately, both Gerry's experience and our research show that strategy won't work. The most successful teams know it. Those teams consider, in the planning stages of the project, what the long-term internal processes will be for updating the site after the design changes. How will they add new content? When do they remove outdated content? Who will edit content before it goes live? Who will review changes? Who will decide about changes to the user's experience?
Understanding how the organization will handle the continual site changes shortens the time it takes to make improvements, reducing the need for a risky major relaunches.
All the evidence points to the simple fact: Careful consideration of long-term factors dramatically increases the odds a team will produce ongoing results that have considerable business impact. Teams ignoring these long-term components may get a new design launched, but will likely find themselves reliving the difficult experience again in just a few months.
Send us your thoughts on this article on the UIE Brain Sparks blog.
Read related articles: