You often hear design team members (or their management) say, "We need a fresh design." This usually gets redesign projects off on a wrong footing, with the wrong goals and strategy.

Typically, a fresh design will be a worse design simply because it's new and thus breaks user expectations. A better strategy is to play up familiarity and build on users' existing knowledge of how a system works.

Why Insiders Want Fresh Design

You stare at the thing all day, years on end. Of course you think the UI looks tired. Count the number of "exposure hours" you've had to your own design. If you've worked on the same design team for a few years, those hours likely reach into the thousands.

In contrast, your typical user has probably spent only a few hours looking at your design over the last few years. Remember Jakob's Law of the Internet user experience: users spend most of their time on other sites.

People usually spend no more than 2–3 minutes on a website, so even if they visit your site daily, they'd run up only 30 exposure hours over 2 years. More commonly, even loyal customers will spend less than 5 hours on your site each year. With so little time spent looking at the design, customers won't tire of it anytime soon.

Why Users Want Familiar Design

The most important reason? Users don't care about design for its own sake; they just want to get things done and get out. Normal people don't love sitting at their computers. They'd rather watch football, walk the dog — just about anything else. Using a computer probably rates above taking out the trash, though.

When people are visiting websites or using applications, they don't spend their time analyzing or admiring the design. They focus their attention on the task, the content, and their own data or documents.

Thus, people love a design when they know the features and can immediately locate the ones they need. That is, they love a familiar design.

In fact, anytime you release a redesign, prepare for a flood of angry email from customers. It's a law of nature that users hate change, and they'll complain every time you move anything around or otherwise reduce their ability to just do what they've always done.

(Having users complain about a redesign doesn't necessarily mean that it's bad; if the new design actually has better usability, people will eventually grow to like it. Customer complaints are thus not a reason to avoid all redesigns; they're simply a reason to avoid changing the design purely to "stay fresh.")

Frequently Used UIs

If you run an intranet, develop applications, or have an extremely popular site, users might in fact accumulate more than a few minutes' exposure to your UI per week. In such cases, you'd think that customers would clamor for a fresh design — but no.

People who regularly use a UI become experienced users and their user experience is dominated by skilled performance. Designing for novice users vs. expert users differs in the relative importance of key usability attributes such as learnability and efficiency.

The more that people rely on skilled performance, the more they depend on having routine behaviors automated. Thus, high-frequency users also prefer a familiar design.

Ultimately, the difference between the design team and users comes down to looking vs. using. You look at the design over and over again, and endlessly debate its smallest elements. Customers might use the same features repeatedly, but their mind is on the task. Because users are focused on something external to the design, it doesn't register as strongly for them.

When To Refresh Designs Anyway

Generally, it's best to evolve a UI with gentle changes rather than offer a totally fresh design. I thus strongly recommend getting the basic design right in the first place, before you launch, so that it can live for several years with minor updates. Before you release anything to customers, use techniques such as rapid iterative design and Agile paper prototypes to thoroughly explore the design space and polish the usability.

This approach contrasts with that of simply "throwing something at the wall" to see what sticks. Indeed, some people advocate just releasing your best guess, because the beauty of the Web is that you can always change it if you're wrong. This is true, but you'll be unpopular, because

  • you'll be mistreating users by subjecting them to a flawed design that you could have fixed with just a few days of pre-release user testing; and
  • you'll antagonize users by making them suffer the very changes that we know they hate.

In general, get it right, and then change slowly. Still, there are two cases in which a more radical approach is appropriate:

  • If you have almost no current users and expect a major design improvement to dramatically expand the user base. In this case, the business loss from punishing your current customers is small enough to be worth taking. Of course, it's still a gamble that you'll actually be able to attract a vastly bigger audience. Remember the old adage: a bird in the hand is better than two in the bush. Unless you're sure that there are millions of users in that bush, you might not want to go there.
  • If your old design has incrementally evolved for so many years that the overall user experience has become overly convoluted and lost any sense of a unified conceptual structure.

As an example of the second point, let's consider Microsoft Office. The suite was introduced in 1989 as an incremental packaging of older stand-alone apps like Word (from 1983) and Excel (from 1984). By 2000, the underlying UI architecture was 17 years old, and MS Office was creaking at the edges. I frequently complained that the old approach was a muddled set of thrown-together features — and that the ever-more complex set of menus and dialog boxes made it hard for users to find most of them.

While I criticized MS Office's growing usability problems, I also said that, if I were Bill Gates, I wouldn't necessarily go for a radical redesign. My thinking was that, while a new design would be better for users, it might be bad for business: it's easier to sell an incremental upgrade than a totally new UI. Sure enough, Office 2003 shipped with a bit of shoeshine applied to the same 20-year-old UI.

Basically, though, the old design was indeed too old, and the humongous amount of accrued functionality needed a totally rearchitected user experience. This was finally introduced with Office 2007. Now, having used the new UI for 2 years, there's no way I'd go back to Office 2003 or its predecessors. The new design is superior. When it launched, however, there were plenty of complaints: users don't like change, and a new UI takes time to get used to.

So, unless your existing design is an overgrown mess of bolted-on features that needs a new architecture, it's best to stay with the familiar design that users prefer and avoid the temptation to go with a novel design that only you'll appreciate.