User-Centered Design Stories. Real-World UCD Case Files

656 Pages·2007·8.803 MB·English

by  Carol Righi and Janice James (Auth.)

Foreword
There once was a young man who wanted to become a jade merchant. He approached
a master craftsman and asked if he could become an apprentice to learn about the semi-
precious stone. The master agreed. On the apprentice’s fi rst day, the master gave him a
piece of jade to hold and then told him stories for an hour. None of the stories had
anything to do with jade. The apprentice was puzzled but returned the next day to a
different piece of jade and more stories. Each day it was the same. After several days the
apprentice’s impatience was mounting. He arrived at the master’s shop that morning
intending to confront the old man and demand to be taught about jade. But the moment
the master put the piece into his hand, he immediately cried out, “This isn’t jade!”
We instinctively recognize the power of stories when teaching children about the
world. But stories are relevant for adults as well. Kevin Brooks, the only person I’ve ever
met with the title of “Technology Storyteller,” sums it up: “The human animal is a nar-
rative animal. We are made of stories.” Unfortunately, as our formal education progresses,
we often lose touch with storytelling in favor of methods that are sometimes more effi -
cient, but lack contextual richness.
I assume that everyone with an interest in this book already understands the impor-
tance of user-centered design (UCD) methods, so I won’t preach to the choir. Instead,
let’s talk about how to learn a new skill. There are many ways. One way is to just try
doing it, make mistakes, and fi gure out what works. Often a memorable way to learn,
but perhaps too time-consuming or impractical in the business world. Another way is to
seek advice from people who have done it—hear them describe what worked well and
what they would do differently. Professional meetings and conferences are good venues
for this, but opportunities to attend them may be few and far between.
Textbooks are also a fi ne way to learn, but they have their drawbacks. As my friend
Jared Spool is fond of saying, “In theory, theory and practice are the same. But in prac-
tice, they’re not.” Most books describe theory—the way a process is supposed to work.
The practice is often quite different, full of distractions and detours. The schedule slips
by a month. Legislation is passed that affects your industry. Your new manager walked
straight out of a DilbertTM cartoon. As Dwight Eisenhower said, “Planning is essential,
xv
FFMM--PP337700660088..iinndddd xxvv 33//1122//22000077 1111::5577::2233 AAMM
xvi
Foreword
but plans are useless.” The challenge for usability practitioners is to be ever-prepared to
come up with a Plan B, because what actually happens to your project will never quite
match the way it was supposed to work.
And then there are stories. This book is about the practice of user-centered design,
and it’s written in a unique way. Each chapter is a case study about a situation where a
user-centered design method or process was used (or, in some cases, mis-used). Some
chapters are about particular methods—card sorting, personas, remote evaluations, etc.
Others discuss various challenges of running a UCD program—promoting it, estimating
projects, outsourcing, etc. All the case studies are set in a realistic context of politics,
tensions, and ambiguity, because these stories are real. They describe real events that
happened to real people, though some details have been disguised. Not every story has
a happy ending, but there are lessons aplenty.
A dozen years ago, a friend recommended a book about management. The Goal: A
Process of Ongoing Improvement by Eliyahu Goldratt and Jeff Cox is actually about the
theory of constraints. But it’s told as a story about Alex Rogo, the manager of a manu-
facturing plant. Both the plant and his marriage are foundering, the former despite his
overtime hours and the latter because of them. With the help of an enigmatic former
professor, he discovers something called the theory of constraints and applies this knowl-
edge to their manufacturing process. Each time Alex fi nds a bottleneck and fi xes it, new
and more subtle problems emerge. But in the end he saves both the manufacturing plant
and his marriage.
As a novel, The Goal would never make the best-seller list—a manufacturing process
doesn’t make for compelling drama. But it works quite well as a story about how the
theory of constraints can be used to analyze and improve a process. It’s certainly much
more engaging than the theory of constraints served up in a vacuum. Years later, I daresay
that I recall more of what I learned from The Goal than from any class I took in business
school.
Here’s an example closer to home. In 2005 I participated in a Usability Professional
Association workshop on “Reporting Formative Test Results.” The goal of the work-
shop, which was part of a larger ongoing effort, was to develop a template, guidelines,
and best practices for reports of usability tests. A bunch of us sat in a room and described
how we wrote our reports. And there was plenty of controversy—I think the only report
element we all agreed on was page numbers. Each time one person tossed out a state-
ment like, “Surely you wouldn’t write a report without including recommendations,”
three others would pipe up with real situations where recommendations hadn’t been
appropriate.
Those discussions were valuable because people explained not just what they put in
their reports, but also why. Often it had to do with the composition of the project team
and the relationships the usability practitioner had with them. For instance, one person
FFMM--PP337700660088..iinndddd xxvvii 33//1122//22000077 1111::5577::2233 AAMM
xvii
Foreword
might say, “I’m an integral part of the team, and they ‘get’ usability testing. I don’t have
to explain it in my report.” Someone else might say, “I’m an external consultant. I never
know who might be reading my report down the road, so I always document my methods
in writing.” Those are two very different situations, each with many implications about
the “right” way to write a report. By comparing my situation to other people’s, I could
decide whether it made sense for me to do the same thing they did. Stories hold the
kind of contextual richness that helps us make these decisions.
There are several ways you might use this book. One is to be like the apprentice
and simply read it cover to cover as a collection of stories, trusting that your subconscious
is absorbing wisdom that will appear when you need it. Another way is to consider each
chapter an extended example of how a particular method works in practice, and read the
ones that are most relevant to you.
A third way is to put yourself in the shoes of each protagonist and consider what
you would do, before you read what they actually did. There are questions embedded in
each chapter to help you to do this. It’s OK if your answers are different than the authors’,
because part of your brain will engage in interpreting the situations based on your own
unique experiences. In other words, you’ll naturally start thinking about how to apply
the lessons to your own life. You might even want to take this a step further and have
a colleague read the book along with you, especially if you are planning a similar
project.
One way or another, this book lets you vicariously relive the experiences of others
and assimilate their lessons sans the fi rst-hand pain. The authors are professionals of
stellar reputation, with collectively about a gazillion years of experience. The editors
are cut from the same cloth, plus they had the vision and drive to make this book a
reality. Thanks to all for sharing your stories. What you’ve given us is not your typical
textbook, but a learning process that is much more memorable, thought-provoking, and
enjoyable!
Carolyn Snyder
Usability Consultant, Snyder Consulting
FFMM--PP337700660088..iinndddd xxvviiii 33//1122//22000077 1111::5577::2233 AAMM
Preface
Those of us who have been in the Usability Engineering industry for more years than
we wish to count, have learned many valuable lessons from the real-world stories that
professionals both inside and outside our industry have shared with us. The ancient art
of story telling is an essential vehicle to communicate what’s really happening—both in
our world and in our minds as we work through our real-world problems.
In this book, the authors have used the art of story telling, drawing from the tradi-
tion of the Harvard Business School case studies, to provide a glimpse of the various
real-world situations in which usability engineering and user-centered design meet busi-
ness and bottom line reality. The purpose of the case studies is to involve the reader at
a more personal level by drawing them into the story and details of the various players
as they are driven by their corporate roles, project needs, and other infl uences, including
of course, the users. We hope this more personalized approach allows the reader to come
away with a more practical perspective on the real-world challenges we commonly face
as UCD professionals.
All of the case studies are based on real events, real people, real companies, and real
UCD challenges. Of course the names of people and companies have been changed to
protect ourselves, as well as the innocent.
Is This Book for You?
If you are a current, or aspiring, UCD professional responsible for developing or enhanc-
ing products to enable end users to accomplish their tasks more effectively, more effi -
ciently, and without undue pain, and even pleasantly, then we are confi dent you will
benefi t from a thoughtful reading of this book. Where else can you be a “fl y on the
xix
FFMM--PP337700660088..iinndddd xxiixx 33//1122//22000077 1111::5577::2233 AAMM
xx
Preface
wall” at such a wide variety of real life UCD experiences without leaving the comfort
of your living room?
The case studies in this book assume a basic level of knowledge about UCD, whether
derived from a few college courses or a year or so of work experience in the UCD fi eld.
The more seasoned UCD practitioner will no doubt recognize many of the scenarios and
possibly benefi t even more so by reinforcing his or her own experience, and by learning
alternative ways to approach and solve commonly experienced problems.
A few of the case stories are didactic in nature, containing a good deal of “how to”
guidance, while others are oriented more toward exploration and discovery, requiring the
reader to examine the specifi c facts, understand the motivations and roles of the characters,
and search for creative solutions.
How This Book Came to Be
This book is the brain-child of Carol Righi. She envisioned a book of user-centered
design case studies that would provide even the most experienced practitioner with insight
into the problem solving required for the everyday practice of UCD. She was also smart
enough to know that the production and creation of such a book would be a lot of hard
work, so she cleverly invited me to join her.
The authors we successfully enlisted to contribute to this book are some of the most
knowledgeable, skilled, and well-known usability engineering practitioners in the industry.
Their corporate, university, non-profi t, and independent consulting UCD stories are, like
real-life, sprinkled with both positive and negative events. There are no simple answers
to every problem that is posed. But in every case, there are valuable real-life lessons to
be learned and insights to be gained that no standard textbook can teach. These lessons
are, in effect, the teachings of experts from the fi eld.
We hope this book is one that you will return to time and again as a reference to
gain insight, or inspiration when facing the more diffi cult challenges of UCD.
Because all of these case studies are based on actual projects, the problems posed had
actual solutions. We encourage readers to provide their own answers—think through
how you would analyze the problem, and posit what you would do if the situation pre-
sented itself to you. Not everyone would solve all the problems the same way; in fact
multiple solutions are possible. Then, once you have worked through the problems, you
can fi nd the solutions provided by the authors by downloading the fi le at www.mkp
.com/UCDcasebook.
Janice James
FFMM--PP337700660088..iinndddd xxxx 33//1122//22000077 1111::5577::2233 AAMM
Acknowledgments
Creating a book such as this could not have been done without the support of many
people.
UCD is iterative by nature; we wouldn’t expect that writing a book about UCD
would be any different. We would like to thank our chapter authors for agreeing to take
part in this venture, and for taking the time, care, and attention to endure several rounds
of edits and reviews. Their desire to share their stories, and to do so with high quality
and good humor, helped make this task much less daunting and much more fun. We
are indeed fortunate to be associated with such a talented group of professionals.
A special thanks goes to Carolyn Snyder, Deborah Mayhew, and also, Catherine
Courage and Susan Weinshank, for lending their time and considerable talent to help
review these chapters. Their insights and recommendations were extremely valuable and
most welcome by all.
An extra Thank You goes to Carolyn Snyder, who was kind enough to contribute
a wonderful Foreword.
We’d like to thank our colleagues at Perfi cient for their help and support, especially
Danielle Marlow and Sarah and Ethan Righi Ripperdan for their unending love and
limitless support through a very long and focused process.
Carol and Janice
xxi
FFMM--PP337700660088..iinndddd xxxxii 33//1122//22000077 1111::5577::2233 AAMM
CASE 1
Changing Products Means
Changing Behaviors
Jon Innes, Intuit
Senior staff and management recognized that they needed to differentiate
themselves in the market space by becoming better at designing usable products.
They needed someone who could help justify a UCD mission within a company
totally unfamiliar with the concept.
A group of very smart and talented engineers founded JMC Technology.
They had designed an elegant and powerful solution to integrate the various
enterprise software packages used by midsize to large businesses. The solution
kept things like sales orders and accounting packages synchronized in real
time, allowing companies to better manage their money. Their software was
scalable and could be adapted to work with almost any enterprise software
package to streamline business processes. At the time this was a quite a feat,
and JMC initially had few competitors. The company grew quickly and held
a successful initial public offering.
Soon competitors began to copy JMC’s ideas and make similar software.
At fi rst the founders mocked these cheap imitations, but alarmingly the com-
petitors soon started gaining market share. What was happening? Debate
raged, but one thing management agreed on was that users believed JMC’s
products were overly complex and hard to use. Feedback from win/loss
analyses and market analysts showed a clear trend. JMC’s competition was
perceived as being more user-friendly. The sales and marketing teams, as well
as prospective customers, raised complaints that JMC’s UI (user interface)
looked sloppy or it “lacked fl ash.”
3
CCaassee0011--PP337700660088..iinndddd 33 33//1122//22000077 1111::3366::0000 AAMM
4
CASE 1 Changing Products Means Changing Behaviors
In addition to addressing the direct competitive threat, JMC wanted to
expand their business and develop new applications that leveraged their
middleware to further differentiate themselves in the market space. Senior
staff and management recognized that this would require becoming better at
designing usable products, as they would be starting to compete against “GUI
(graphical user interface) companies.” Management began searching for a
solution. They needed someone who could understand their complex
technology and make it easy to use. They decided to hire a full time “UI
guru.”
The Advocate
Jack Chu, the senior vice-president in charge of engineering, had recently
hired Mark Ashby as vice-president of applications at JMC. Mark’s task was
to execute a new strategy to help fend off the emerging competition. Mark
was to develop a series of applications that would leverage their existing
technology and serve as demonstrations of the “unique capabilities of their
core technology.” Mark had many years of experience managing software
projects and had worked with user-experience professionals before. He quickly
realized after starting at JMC that they had a problem with usability. Mark
could see that products were not designed with the end user in mind. It was
clear from casual observation that the UIs used inconsistent layouts and ter-
minology. This made the products overly complicated and hard to learn. He
was one of the strongest advocates of hiring professional help in this area
because he viewed effective UIs as key to his team’s success. Mark knew
there was no way the new line of applications he was charged with building
would be successful without the help of a professional. Mark convinced Jack
that this effort would align closely with Jack’s initiative to drive more rigor
and discipline into the overall engineering process at the company. As the
key advocate for the position, Mark was chartered with fi nding and hiring
the UI guru.
Mark asked members of the user experience team at his prior company
if they knew of a good candidate. He wanted someone who could relate to
the development teams. Otherwise, the candidate would never be accepted
at the company. After some searching he found Jim. Jim was working at a
large software company managing a user experience team working on appli-
cations design. He seemed like a good match, because he had worked on
very technical products and had experience starting teams and designing fi rst-
CCaassee0011--PP337700660088..iinndddd 44 33//1122//22000077 1111::3366::0000 AAMM
5
Analyzing the Situation
release products. Mark listed the skills he believed Jim should have to be a
good fi t for the job.
Questions
1. What skills and experiences does Jim need to be a good fi t for the
job?
2. What should Jim do to determine the organizational needs for user
experience after he starts?
Analyzing the Situation
After some discussion and several rounds of interviews, Jim agreed to join
JMC and lead a company-wide initiative to improve the product design
process. From his prior experience, Jim knew one of the fi rst things to do
when starting a new job was to analyze the organization. Product designs are
often refl ections of the organizations that create them (Christensen, 2000),
and changing the products requires changing the behaviors of the people
involved in the product design. Very few managers hiring user-experience
professionals realize that the person they hire will need to change the process
of producing the product to have a true impact. Mark understood the job
was largely a change management challenge, which was one key factor in
Jim’s decision to join JMC. After joining, Jim began his analysis of what
needed to be changed, promising Mark he would come up with a high-level
plan for how to improve the usability of the products within the fi rst
month.
Jim started his analysis by getting introductions to the key people working
in the various functional areas of the company (e.g., marketing, product
management, sales, support, professional services, etc.) and getting their per-
spectives on what was wrong with the current processes. He also asked them
what was working well. Mark and his boss, Jack, were very helpful with the
introductions because they had regular interactions with everyone and knew
most of the key people well. At fi rst, Jim started drawing traditional organiza-
tion charts to help him keep track of who did what, but he soon realized
that a crucial dimension was missing: level of infl uence. The offi cial structure
did not matter as much as the ability of the group to infl uence the way
products got developed. Not surprisingly, the size of a group was highly
related to its infl uence on the company culture. Although this may not always
CCaassee0011--PP337700660088..iinndddd 55 33//1122//22000077 1111::3366::0000 AAMM
6
CASE 1 Changing Products Means Changing Behaviors
Marketing Sales
Alliances
Engineering Professional
Product Services
Mangement
Support
Figure 1.1. Relationships of the functional groups infl uencing product design.
be the case, most often the largest teams are usually the most infl uential. Jim
sketched out the diagram shown in Figure 1.1, using differently sized circles
to indicate each group’s ability to infl uence the quality of the product
design.
By looking at the diagram, it was clear JMC was a classic example of an
engineering-oriented culture. The engineers were defi nitely in charge. Jim
noted that due to this strong engineering culture, product management was
a bit unusual. At other companies where Jim had worked, product manage-
ment was often responsible for project planning and managing the engineer’s
interactions with others in the company. This was not the case at JMC. The
product management team was struggling because of the historically fuzzy
relationships among product management, marketing, and engineering roles.
Many of the product managers had a development or IT (Information
Technology) consulting background, but few had been product managers
elsewhere. They spent a fair amount of time helping the alliances group (the
team responsible for developing business relationships) form partnerships with
other companies related to new technologies and not much time defi ning
requirements to guide product development efforts.
Jim began setting up meetings to talk to individuals in each of the func-
tional areas. His plan was to interview someone from each team, conducting
interviews in the same order that the teams were involved in creating a new
product or defi ning the features of a new release. He wanted to begin with
marketing and product management, because in many companies these teams
CCaassee0011--PP337700660088..iinndddd 66 33//1122//22000077 1111::3366::0000 AAMM