Published: Mar 28, 2005
Imagine living in the same house for 10 years. Over that period, you've accumulated a lot of stuff.
To keep your house organized, you found places to put everything. Every place made sense to you. Most of the time, you have no trouble finding anything you want. Occasionally, there's something you can't find, like a tape measure, because you can't remember where you last put it, but with a little poking around (and asking your housemates,) you come upon it and all is well.
One morning, you wake up and the house is completely different. Not a little different–completely different.
Nothing is where it used to be. The glasses in the kitchen, the clothes in your closets, and the furniture are reorganized. Even the walls and windows are all completely rearranged.
Whoever rearranged everything didn't consult you. They didn't warn you it was coming. They just took it upon themselves to make it happen.
In this "new" house, nothing seems to be where you'd expect it. The coffee cups are stored under your bed. You find your pants on the bottom shelf of the freezer. Logic doesn't seem to be part of the organization scheme.
The worst part is that you still need to get to work on time. Usually, it only takes you about 45 minutes to get ready, so that's all you allotted yourself. After all, you didn't know this was coming, so why would you set your alarm differently? Nothing is where it's supposed to be, you're spending a lot of time trying to find everything, and the clock is running out–you're going to be late and it isn't your fault!
You wouldn't be surprised to find Rod Serling standing in the corner of your new living room, smoking a cigarette and talking to the TV audience. You're in the middle of a bad Twilight Zone episode.
That's exactly what happened at one of our clients' companies. They had an intranet site that had built up over 9 years. It grew organically, with various people adding new features and elements very slowly.
The employees had become accustomed to the intranet and knew how to find the things they needed. Even when an employee couldn't find something, there was always someone within earshot who could. New employees found complete support amongst the existing staff, making orientation quick and easy.
One day, last September, the employees came into work expecting things to be just like they'd been for 9 years, only to find that a brand new design had been launched. Not only were they not consulted on the radical changes, they weren't even warned.
The changes were dramatic. A new home page had new terminology and a new taxonomy for all the critical elements of the business. The intranet now sported a search function (something the old design lacked), but every query returned dozens of results, most of them seemingly irrelevant.
When the employees did find things, the logic didn't make sense. Because they couldn't understand why key elements were put where they were, they never could find them again. And nobody around them seemed to know either.
The organization's 1,700 employees were now all lost, simultaneously. And the business was expected to continue serving its customers without skipping a beat. It was a disaster.
In retrospect, it's easy to see how this happened, and why it would be such a problem. However, from the perspective of the company's IT department, every step in the re-launch and redesign made perfect sense.
The old intranet's technology, having never been planned or considered, was quickly becoming unmanageable. New technology (in this case Microsoft's SharePoint) promised to make things easy-to-manage, while also advancing the firm with new technologies, such as knowledge management, collaboration tools, enhanced messaging, and sophisticated content management.
Having never assigned anyone to the old intranet, IT quickly assigned two full-time folks to the new implementation. These two folks felt the pressure of getting the new system up, to support new features users needed. They converted everything they could, as quickly as they could, readying everything for a corporate launch.
While they thought that some training might be helpful, they knew that the employees were very busy. It's a high-powered business that moves very quickly, often responding to external deadlines beyond their control. There would be no way to train everyone in a timely fashion, so they bit the bullet and launched the best system they could. And that was day one of what has been a very stressful few months.
In a situation like this, it's easy to conclude that people just hate change. Since the new design was launched, all anyone has asked for is to have the old design back.
Over and over, the management hears complaints that the new system is much harder to use than the old system. It's not true–usability tests show both designs are practically the same, in terms of task completion–yet every user is pining for the trusted intranet of old, ready to burn the new one at the stake. "I'd be very happy if tomorrow we scrapped it and started over," one 14-year veteran employee told us as we were trying to figure out how to go forward.
Change isn't bad. It can't be. If it were, we'd never have any technology advancement and wouldn't be pleased with our iPods and TiVos. Yet people obviously resist some change. Understanding why change is sometimes embraced and sometimes resisted is critical to successfully introducing new designs.
We can look to our understanding of the Knowledge Gap to help us explain why users sometimes resist change. In our recent UIEtips article What Makes a Design Seem 'Intuitive'?, we talked about two points that were important in the knowledge space: Current Knowledge, which is what users know when they sit down at the design, and Target Knowledge, which is what they need to know to complete their task. These two points are essential to our understanding why people resisted the new intranet's design.
A new employee reporting to work on a day four years ago would have found the old design intimidating. However, supportive co-workers would have graciously helped that new employee become accustomed to the design.
In terms of our two knowledge points, that employee's first day of work is also where Current Knowledge is farthest from Target Knowledge. However, thanks to fellow employees' helpful assistance, Current Knowledge moved closer and closer, until the gap between the two points was barely noticeable.
Everything changed on the day of the new design's launch. All of a sudden, everyone's Current Knowledge was shifted back–almost to the point of a brand new employee. Not only did it affect each individual, but it decimated the support network that was engrained in the culture.
Suddenly, the knowledge gap was huge for everyone, with no warning, and no justifiable reason as far as the employees were concerned. Their jobs are now substantially harder and they don't see any benefits. It makes perfect sense that they'd resist any change that ends up like this.
Change is possible, even desirable. Even for these employees, the old intranet was not static for 9 years. It changed almost every day. But never in a substantial way. The changes were small, never really affecting the Current Knowledge point. They were accepted, even wanted.
Our theory says that change that doesn't widen the Knowledge Gap will be embraced, while change that does will be resisted.
What this tells us is that we need to understand how we're going to introduce the changes in a way that keeps the Knowledge Gap from expanding and plan accordingly.
This is exactly what eBay has learned to do. Having had bad experiences with sudden, drastic changes that fermented virtual user revolt (even as simple as a background color change), they now take change in a more considered way.
As they introduce a new feature, say a new form for posting items to sell, they allow users to choose to "switch" over, simultaneously supporting both methods. Early adopters switch and give feedback, allowing eBay to make improvements. The community slowly grows accustomed to the new design, allowing the support network to build. When critical mass is reached, the new design becomes the default, with the old design still out there for those "die-hard" users to still have time to adapt. (See The Quiet Death of the Major Re-Launch)
Of course, this approach doesn't lend itself to large, full-scale changes in technology. But most technology today can be phased in, without the complete and total change that got our client into such big trouble. It's not easy, but, in hindsight, the results look as if it might have been substantially less costly–both monetarily and emotionally.
To design for embraceable change, the design team has to be well aware of the existing Current and Target Knowledge points, as well as the new points. Field studies are the ideal technique for learning the existing points, whereas usability testing will give a detailed understanding as to whether the new design has an acceptable knowledge gap. These two techniques are essential for any team who needs to tackle this difficult problem.
It's not that people resist change whole-scale. They just hate losing control and feeling stupid.
When we make critical changes, we risk putting our users in that position. We must take care to ensure that we've considered the process of change as much as we've considered the technology changes themselves. Only then will we end up with changes that our users embrace.
Read related articles: