Designing Embraceable Change

By Jared M. Spool

Originally 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.

The Intranet Re-Launch from Hell

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.

Hindsight is 20/20

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.

Why People Both Embrace and Resist Change

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.

Mind the Gap

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.

Thinking About the Process of Change

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.

Designing Embraceable Change

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.