UX Storytellers

Connecting the Dots

Edited by:

Jan Jursa

Stephen Köver

Jutta Grünewald

Book (PDF) layout by:

Iris Jagow

Jan Jursa

ePUB, Kindle, iBook by:

Jan Jursa

Copyright

All stories © 2010 by their respective authors.

All images © 2010 by the respective authors.

UX Storytellers v1.02

To Our Community

Acknowledgments

I would like to thank all of the authors who have been so kind as to cut out a big chunk of their precious time in order to contribute their story to the UX Storytellers book. In alphabetical order, these wonderful men and women are:

Aaron Marcus, Abhay Rautela, Andrea Resmini, Andrew Hinton, Andrea Rosenbusch, Cennydd Bowles, Chris Khalil, Clemens Lutsch, Colleen Jones, Daniel Szuc, Dave Malouf, David St. John, David Travis, Deborah J. Mayhew, Eirik Hafver Rønjum, Gennady Osipenko, Harri Kiljander, Henning Brau, James Kalbach, James Kelway, Jason Hobbs, Jay Eskenazi, Jiri Mzourek, Ken Beatson, Lennart Nacke, Marianne Sweeny, Mark Hurst, Martin Belam, Matthieu Mingasson, Olga Revilla, Patrick Kennedy, Paul Kahn, Rob Goris, Robert Skrobe, Sameer Chavan, Simon Griffin, Sudhindra Venkatesha, Sylvie Daumal, Thom Haller, Thomas Memmel, Timothy Keirnan and Umyot Boonmarlart.

Furthermore, I would like to thank Stephen Köver, Jutta Grünewald and Iris Jagow for helping me with this project. Thanks, guys!

I want to take this opportunity to thank everybody for encouraging me to bring about the UX Storytellers book. It felt good to receive so many kind words.

Thanks to Sabine Stoessel, Gillian Birch, Gabriele Zenisek, Thomas Gläser, Simon Schmidt and Grandin Donovan who provided me with great feedback on an early draft of this book. And a special thank you to everybody who promotes this book :)

Jan Jursa, Editor in Chief

UX Storytellers

Foreword

I have a thick notebook in which I write down my fantasy projects—stuff I’ d love to build or to write some day. There is no date on the first page, but I think I began writing and drawing ideas in this particular book around the year 2000. I was working as an Adobe Flash developer back then, so all the early entries are games and crazy animations and such.

I guess I had many books like this as a little child, when I used to run through the winding streets of Mala Strana, right below Petrin hill on the left bank of the Vltava River. I guess so, but I simply cannot recall many memories from those early days in Prague.

So let’ s say I was extraordinarily talented, at least as a little child, and filled page after page of every drawing book that was handed to me. Yeah, why not?

Those books—if they ever existed—have long since gone missing, like so many things. On the way from childhood to our first job, we surely gain a lot of important skills, but we do lose things too. We lose the ability to observe, to ask when we don’ t understand something, to try things out and take risks, and to outline even the simplest idea in a rough sketch. Much later in life, some of us pay someone who promises to teach us how to draw again.

I don’ t know if the same is true for storytelling, perhaps it is. When we are young, we have the wildest stories to tell. Then, on the long path towards a profession, although we don’t lose our interest in them completely, many of us simply stop telling stories. And yet listening to stories is so much fun. Sure, but who will be the storyteller if we all just lean back and listen?

Somewhere in my notebook there is a page with “UX Storytellers” written on it, together with some rough sketches.

I remember coming home from conferences and recalling the anecdotes I had picked up Lord only knows where—over lunch or late at night in a bar. The kind that start: “Hey, wanna know how I got into this strange domain of User Experience?” or “This is what I tell my parents, when they ask about my job as an Information Architect ...” (No, Ma, I am not an architect.) Or “This is what I recently learnt during a project that went really bad ...”

Yes, these were the kind of stories I wanted to collect. The UX Storytellers seed was growing in my mind. The idea kept on bugging me, and in June 2009, I simply had to start this little adventure. Writing it in my book of unfinished projects and half-done dreams had been a relief, but it didn’t last long. One month earlier, in May 2009, some friends and I had organised our annual German Information Architecture (IA) Conference. Again, I had met awesome people and had listened to their stories. This time, the book had to be done. I approached Stephen Köver, a friend of mine and also a member of our IA Conference team.

Coming from London and working as a freelance translator (German-English), as well as being an IA, would already have made Stephen a good candidate. What made him a perfect choice though, was our shared love for words. Stephen is a passionate translator and a true master of the English language (especially the British variant). Some time later, Jutta Grünewald joined the editorial team. Graduate psychologist, copywriter and web editor, she always loves a pun, a catchy headline and an unexpected twist in a story. Last but not least, the designer Iris Jagow joined the party. Iris and I did the InDesign work together, however it’ s safe to say that all the good ideas and design decisions came from her.

I contacted many potential authors, and over the next 10 months, we—Jutta, Stephen and I—set about collecting and reading stories. Reading and re-reading them. And re-reading them again. Sending suggestions back to the authors who were so generous to submit a story for this book. And so on. Finally, we ended up with 42 extraordinary authors, all people I admire and look up to. Take a look at their lives, their books, their blogs, and their achievements. Jaw-dropping, isn’t it? You can’ t help but be astonished and inspired. Not only are they leading experts in UX and related fields with strange acronyms, but they are also the most wonderful people. Please take the time to read and truly listen to their stories in this book—or in person, if you happen to bump into them at one of the many conferences that take place around the world nowadays.

Dear authors: I salute you.

Moreover, a special thank you must be said to all the non-English speaking authors who had the additional challenge of writing in English, but kept at it and delivered really marvellous stories. We have carefully polished their stories while retaining the local flavour—always wary of reducing them to bland uniformity.

Why are there so few female authors in this book? Well, I can assure you I honestly tried to contact as many female authors as I could think of (ok, there was a bottleneck right there). I am all the more grateful for the contributions of Andrea Rosenbusch (Switzerland), Colleen Jones (USA), Deborah Mayhew (USA), Marianne Sweeny (USA), Olga Revilla (Spain) and Sylvie Daumal (France).

This book is available as a free eBook on the UX Storytellers blog (http://UXStorytellers.blogspot.com). Tell your friends and colleagues about it, or your students or interns and trainees. Help us spread the word.

Please excuse typos or misspellings, but feel free to email them to me. I’ll update this book from time to time. That’s the beauty of eBooks.

And now, enjoy.

Jan Jursa, Editor in Chief

UX Storytellers

uxstorytellers@gmail.com

--

Berlin, on a warm September evening in 2010

Chapter 1

The White Rabbit put on his spectacles.

“Where shall I begin, please your Majesty?” he asked.

“Begin at the beginning,” the King said gravely,

“and go on till you come to the end: then stop.”

Lewis Carroll

Learning Information Architecture

First Get a Job

I arrived in Boston in the fall of 1972. I had left my home in the suburbs of New York City, gone to college in Ohio, and spent the previous 18 months in Kansas. Kansas was virtually like a foreign land to a person from New York City. It was filled with friendly people and endless space. In Kansas, you can see great distances. Much of the land is flat. Trees are sparse and grow along the shallow rivers. Highways are wide and straight. The tallest buildings are silos for storing grain. You can see large weather patterns that may be hundreds of miles away during the day and chain lightning leaping across the sky at night.

I had studied literature and wanted to be a writer. More specifically, I wanted to be a poet. This was not a lucrative career path and I needed to find a way to support myself. In Kansas, I had been a part-time graduate student and part-time Elementary School teacher. Now I was going to a training program in Vermont to get a teaching license. I had three months to fill. I had not learned the art of creative lying. I didn’t want to tell an employer that I was going to stay for a year to get a “regular” job.

A friend suggested I could support myself by driving a taxi. The taxi fleets owned many cars and hired drivers by the day. The commitment was for one day at a time. The driver earned a percentage of the fare plus tips. There was a taxi garage a short walk from the apartment where I was staying.

In some major US cities, drivers must pass an examination to prove they know their way around before they can operate a taxi. In Boston, Massachusetts, all you needed was a driver’s license and verification from the Boston Police that you had no police record. I had a driver’s license, no police record and almost no idea of where things were. And that’s how I became a Boston cab driver.

I was not a total stranger to Boston. Parts of my family had settled there a hundred years before. My family drifted south, but some of my mother’s relatives were still there. So I had visited Boston as a child. I remembered being impressed by how strangely people drove their cars. The driving style in New York is aggressive but orderly. People drove fast and routinely cut in front of each other, filling all available space. In Boston, drivers followed a different code. They seemed to pay no attention to traffic signals and frequently made U-turns in the middle of major roads, as if the only thing that mattered was where they wanted to go. Though I had visited the city, I really did not know my way around. My relatives all lived outside the city center. Most of the pathways I knew were the routes of a suburban outsider—how to get from one highway exit to a specific destination and return to the highway.

Then Get Lost

When I started driving the cab, I bought a book of maps. It was the cab driver’s bible, listing every street in every town. Each map contained the streets of a single town. In the back, there was an index of road names, with a code to indicate the town, page and sector of the map. In theory, a driver could find his way to any address by looking up the street in the index and finding its coordinates on a map. This was the solution for the microcosm. But the macrocosm was more difficult to grasp. How do I get from here to there? Understanding the transition from one town to the next was the truly difficult problem. Often, I could find the destination on a map, but could not figure out how to get to the town. In retrospect, I can see that this was a case of mismatch between information organization and the user’s mental model. This particular user (me) had no mental model of how to get from West Medford to East Malden or from Downtown Crossing to Broadway in Somerville. The experienced cabbie had the macrocosm in his head, and used the maps to fill in the infinite detail. No one had made a book for a cab driver with good eyes and an empty mind.

If someone got into my cab and knew how to get to where they were going, we were fine. If they didn’t, it was an adventure.

Boston is one of the oldest American cities. Its urban development has a distinctly organic side. It began as a group of settlements in the seventeenth century around the curved shoreline of the harbor where the Mystic and the Charles rivers emptied into the Massachusetts Bay. Each settlement had grown into a town built along the English model, with a central commons for grazing animals, a church and buildings for public assemblies. The towns were connected by paths suitable for horses and cattle. By the eighteenth century, the harbor was the commercial center and became the city. In the nineteenth century, water-powered industry developed along the rivers and canals. Adjacent towns which had once been farming communities became factory and warehouse complexes.

As railroad, trolleys and cars were introduced in the twentieth century, the pathways that connected the towns were still based on the original cattle paths. The oldest part of Boston along the harbor became known as The Hub, because all the inland roads led to this area, forming the shape of spokes joining at the waterfront. But the resulting pattern was less hub-and-spoke than a hub-and-spoke-and-web. Every major road runs at oblique angles to other major roads. Some roads follow creeks or small rivers, while others simply connect the dots that once were villages. The Charles River had become a placid lake separating Boston from the town of Cambridge. In one small part of the growing city, wetlands were filled to make new real estate. On this virgin territory, known as Back Bay, the streets were laid out in a perfect grid, with street names in alphabetical order. To a New Yorker, this seemed like a reassuring and familiar pattern. To a Bostonian, it was simply a charming aberration.

The ancient mail roads, eighteenth century public thoroughfares that joined Boston to the other commercial centers in the south, west and north, became State Routes joining Boston to nearby cities such as Providence, Rhode Island, Worchester, Massachusetts or Manchester, New Hampshire. Many major roads crossed not at intersections but at rotaries (roundabouts), a distinctly British influence that took root in old New England. When the traffic was still pulled by horses, each road was marked by a carved stone announcing the number of miles to the next major city. As cars replaced horses, the signs were expanded to two bits of information: the closest town and the next major city. In Boston, these pre-highway signs had never been replaced. They continued to tell the driver nothing about any of the other nearby towns he might reach if he chose this exit from the rotary. By the 1970s, anyone driving to another major city would not use these small roads with traffic lights and stop signs that passed through each small town. Everyone used the high-speed interstate highways system. That entire system, which sliced up old neighborhoods in cities such as Boston, had been created by Eisenhower to assure the fluid movement of troops across the country. In this case, the word “slice” was not a metaphor. When the Massachusetts Turnpike was built, starting from Boston harbor and stretching west, the city planners dug a canyon that divided the city. This central city was bifurcated by a chasm into northern and southern segments.

Listen to the Code Talkers

Ambitious cab drivers filled their day by taking fares from the radio. Each cab had a two-way radio tuned to the frequency used by the fleet. From the office, a voice would announce “I need a car at 14 Tremont going to Cambridge, who’s near Tremont?” and drivers who knew what they were doing would grab their mike, press the button and announce “Number 12 for 14 Tremont”, at which point the voice would say “Okay, Mike, you got it. Who’s on Beacon Hill? Two fares going to Broadway in Somerville.” I just listened. I wasn’t sure how to get to 14 Tremont anyway. On the rare occasions when I recognized an address, I wasn’t fast enough. Mike or Sam or Billy got the fare before I could press the button. The efficiency of the system was too much for me.

This was my initiation into the world of code talkers. The two-way radio is a narrow channel of communication, with minimum space for output and feedback. The radio operator was receiving phone calls and translating them into the smallest possible verbal message. The listener was required to take these compressed verbal bits and rapidly expand them into a calculation of where he was, how long it would take him to get from here to the fare, and add a judgment as to how long it would take to get another fare when he dropped them off. Mike and Sam and Billy could do this in a few seconds.

It was many years before I learned that code talking is a basic feature of person-to-person communication and human-computer interaction. It is a method for compressing two critical elements of sending and receiving a signal: length and meaning. This is how pilots talk to air traffic controllers and how CB radio operators converse. A third critical element is a protocol—the expected sequence in which codes are exchanged. The cab driver listens for a request, the radio operator makes a request, the cab driver responds, the radio operator acknowledges the response and the transaction is completed. UUCP (Unix to Unix Communication Protocol) and FTP (File Transfer Protocol), two early methods for moving data between computers, are basically the same thing as a radio operator calling cabs to pick up a fare. One machine sends another machine a request to open a channel. If the other machine responds with the correct acknowledgement, the first machine continues, until the finale: end of file sent (EOF) and end of file received (EOF ACK). It is the perfect system—fast, efficient, unambiguous—when the mental models of the sender and receiver match; both sides understand the same code and the same protocol.

If you aren’t familiar with the protocol, you don’t know how to respond. And if you don’t understand the code, you don’t get the message. I also wasn’t motivated to learn. By the second week, I just turned the radio off.

Listen to Your Fare

I didn’t talk much, but I listened. I only drove during daylight hours. It was better money to drive at night, but I had a hard enough time recognizing the buildings and the streets during the day. For personal comfort, I found a few taxi stands where I was likely to pick up a fare that knew where he or she was going. I waited in front of large department stores—people going home from a day of shopping usually know how to get home. The first move of the morning often determined the rest of the shift. If I picked up a person arriving at the train station, I often found myself waiting at the taxi pool of the airport. I read books. I read the essays in Silence by John Cage while waiting in the taxi pool at Logan Airport. Cage, the American composer who introduced random sound (noise) and chance into contemporary music, wrote “If this word music is sacred and reserved for eighteenth- and nineteenth-century instruments, we can substitute a more meaningful term: organization of sound.” I was driving around in a sea of noise and it seemed to have little or no continuity. I needed to find a way to organize it.

I learned my way around by looking for the pattern. Patterns of information tell us where we are, where we are going, and where we should not go. I learned where to go and where not to go from my own experience. Not being from Boston, my mind was relatively empty on the topic of local racial stereotypes and tribal agreements. As a cab driver, I saw parts of the city that I never saw again when I returned to live there for over a decade. When a person got into my cab, I took them where they wanted to go. I didn’t know that I wasn’t supposed to accept a fare going to the Columbia Point Housing Project, a high-crime area that other drivers categorically avoided. One day when an African-American woman got into my cab and told me to take her there, I followed her directions. When I dropped her off, I looked around and tried to figure out how to get back to familiar territory. There, rising above the top of the buildings in the distance, was the Prudential Center, the tallest building in the city. I was able to keep this landmark in sight through the windshield as I found my way back to the Hub. When I read Romedi Passini’s Wayfinding in Architecture many years later, I already knew what he was talking about.

Being honest about my lack of knowledge did not get me good tips, but it got me good advice. Once I had told my fare that I didn’t know how to get to where he wanted to go, he often taught me his favorite shortcut home. My passengers shared their knowledge about which avenues to avoid at certain times of day and how to follow service roads alongside a crowded highway. Boston has a rich tradition of traffic congestion. In those years, it still had many uncontrolled intersections where traffic from several roads simply converged at entrances to highways, bridges and tunnels. I listened to my fare’s advice and learned how to find a little-known crossing of the same river, or a rarely used entrance to the same highway.

I read Steps Toward an Ecology of the Mind by Gregory Bateson while waiting for fares in front of Filene’s Department Store. From Bateson, I learned about cybernetics, feedback loops and the biological definition of information: a difference that makes a difference. The city was made up of different kinds of roads, different kinds of intersections, different kinds of neighborhoods. The Boston traffic network was my first experience of systems theory. On the street, this was not an abstraction. The network itself was the subject. It was a complex, multi-dimensional man-machine interface. The machine was the combination of the car which varied from day to day, sometimes with poor brakes, leaking windows, and a hole in the floor; the roads with potholes, blind intersections, turning lanes, and double-parked cars; the traffic that depending on the time of day, a baseball game at Fenway Park, and the ever-changing weather. The state of the network was set in motion when someone tapped on my window or opened my door to announce where I was going next.

By the time I turned in my last cab, I had learned a small but fundamental lesson. I had learned how to find my way around a complex network. I had learned how to observe and internalize patterns, how to build overviews and routes in my head from previous experience. Six months later, I returned to Boston and lived there for another decade. By the time I left, my mind was a rich database of routes from one part of the network to another. I could anticipate traffic patterns when a Harvard football game and freezing rain at five o’clock in November meant to avoid Route 2 and Storrow Drive when driving from Arlington to Watertown. I could tell the cab driver how to get me from Medford to Logan Airport at six o’clock on Friday without getting stuck in traffic, by navigating the back roads of Chelsea.

The day I left to take a job at a computer research institute at Brown University in Providence, Rhode Island, I was very upset. I remember thinking: all this special knowledge gone to waste! My brain was full of information I would never use again.

It was another decade before I realized that nothing had been wasted. I came to understand that I had learned wayfinding and navigation systems. My experience in listening to my passengers taught me humility and empathy. The people moving through the network were the most important source of knowledge. Getting lost taught me that I could understand a system I didn’t know by using it. Understanding was a matter of seeing the patterns in the information. Seeing the patterns requires a fresh and open mind, listening to the users and examining the data. In 1995, Richard Saul Wurman asked Krzysztof Lenk for a contribution to his new book. Kris and I had been collaborating for five years at that point, creating overview diagrams. It was our way of simplifying information, drawing our clients away from their fixation on the microcosm of specific features and banners and buttons, to make them see the larger system. We wanted them to see where all the electronic neighborhoods connect and the user passes from one district to another, accomplishing a task. Wurman called his book Information Architects. It was at that point that I understood. I had received my training in information architecture driving a taxi in Boston.

About the Author

Paul Kahn is a leading international consultant, speaker and author on information architecture and visualization. His activities in the United States included director of the Institute for Research in Information and Scholarship (IRIS) at Brown University, co-founder and president of Dynamic Diagrams and adjunct professor at the Rhode Island School of Design. He is managing director of Kahn+Associates in Paris, France and teaches in several Mastère Multimédia programs in France and Finland. Since 2005 he has been editor of the annual NEW Magazine, International Visual and Verbal Communication (www.new-mag.com).

Paul Kahn is co-author (with Krzysztof Lenk) of the book Mapping Websites (Rotovision).

Web: www.kahnplus.com

Twitter: pauldavidkahn

Facebook: Paul Kahn

Sex, Drugs and UX

The truth is, that for the better or worse of my design, I’ve never read a book about UX. Not in my thirteen years of practicing. I’ve started reading many of the books, but I get a few chapters in and I start looking elsewhere for the kind of fiction I prefer to spend my time reading. It’s not that the UX books or their authors aren’t any good, it’s just that—and how do I put this diplomatically—doing UX is about as much fun as I can have sober, but reading about UX is duller than watching paint dry.

I wonder then, is it not just a little hypocritical to expect you to read my story about UX, when quite frankly, I wouldn’t be likely to do the same myself. My plan is to try not to write about UX at all, but rather to tell you sordid stories of sex, drugs and rock ’n’ roll, that will be much more interesting and entertaining. It would be for me anyway, when I was younger I wanted to write porn for a living …

The thinking behind this solution gains its inspiration from what my brother remarked as he handed me Hunter S. Thompson’s Fear and Loathing in Las Vegas. I was in my early twenties and, although something of a drinker, I was a clean-living kid in drug terms. My brother is a fine artist and reading, fiction at least, is not big with him, so when he handed me the book, I made sure to pay attention to what he said: “I think for a full six months after reading this book, I couldn’t say no to drugs.” And that was that, more evidence of a brilliant book an impressionable young man could not ask for. The thing is, my brother’s six months kind of became my next six years, but there’s no denying it, it is one good book.

That isn’t quite the effect I’d like to create from you reading this story, but in my early years of doing this kind of work, UX, I guess there was a Gonzo Journalist, a postcards-from-the-edge, a b-grade wannabe rock star hoping to express himself through sitemaps. I actually was a b-grade wannabe singer in a grunge band in the early nineties but somehow that career path morphed into UX.

If I think of the hell I raised in the agencies I worked in, in retrospect, I really wonder how I got away with it. All the mornings I came in late, smelling of booze, the fool leading everyone off to the bar after work, night after night, bar after bar, Johannesburg, Cape Town, London. I guess something about agency culture lets you get away with this.

The delayed-response hangover arrives at about noon, just as you think you’ve finally managed to avoid it all together. Actually, you were shooting gold tequila and smoking joints with your friends until three in the morning, in the middle of a big project, at a pool bar trying to get into the pants of the oh-so-cute new junior designer, and you’ll stay a bit drunk and high until noon the next day, even if you managed to get two hours sleep. When the delayed-response hangover does kick in, it does so with a vengeance. Your monitor makes you nauseous, the air conditioning closes in and constricts your breathing, you develop beads of sweat below your hairline, your bones ache and your muscles feel like jelly. And like a total and utter fool, I sincerely believed, every single time this happened, that a toasted bacon, egg and cheese sandwich would magically make it all better. I’d rise from my work station and like a scarecrow in a strong wind stumble my way to the canteen, corner café, local greasy-spoon (depending on the agency, city or country) past all the other people studiously working.

Be it the grease, time passing, or the nap in the toilet, I would finally settle down in the late afternoon to get some work done. I look up from my desk, my monitor and pad and there is total calm. Some eletronica is flowing through me from headphones and as if by magic there are pages and pages of hand drawn designs all around me: thumbnails of interfaces, annotations, mini sitemaps explaining where the little drawings of interfaces sit in the structure, a line joining a box with an idea for a navigation device, task-flow boxes and lists of the things I imagine my users will want, content ideas, special offers, download calls to action, accelerated paths to purchase.

I breathe out, at peace. I feel as though all this occurred in that one breath, but three hours have passed. This is the magic of design and creativity: the receding of things as you drift off, unaware of time, temperature, or the movement of people around you, unaware almost of page after page, of drawings and notes and ideas and your true Da Vincian genius. Fantastic. LET’S GO DRINK!

At around eleven one morning (an hour before the delayed-response hangover kicks in) my project manager taps me on the shoulder. I take off my headphones (now playing: Underworld, album: Beaucoup Fish, heard: 1572 times), swivel around to face her, and she asks if I’ve come up with the five suggestions for names for the brand and CI intranet we’re creating for a large local investment bank.

“Sure. Sure,” I say, “When’s the meeting?”

“At twelve,” She says.

“Here or at the client?” I ask.

“Here,” She says. She smirks, turns and walks away.

Fuck. I totally forgot. I wheel over to my graphic designer and beg her for help. In order for you to appreciate what is humorous in this, you’ll need to know, 1. That the bank’s primary colour in their brand and corporate identity is green, 2. That in South Africa, marijuana is sold in clear plastic bags that seal at the top (the bags are acquired from banks when coins or notes are provided at the teller) and that the street term for weed purchased in these bags is a “banky” (like: “Score for me a banky of Durban Poison hey China?”) and 3. We’d been smoking a lot of marijuana out of these bankies until early that very morning.

An hour later, my graphic designer and I push a printed A4 page across the large boardroom table towards our client with five name ideas on it. Two of them are, “The Big Green Banky” and “Growing Green.” Lord knows how but we weren’t fired and they went for “Growing Green” and like a child whose secret hiding place for sweets never got discovered all through childhood, so do we treasure our big green bankies … and growing green.

Oh, and then there are the women, all the gorgeous, marvelous, smart, creative, sexy girls who I’ve worked with, and tried to seduce, and failed trying to do so. On only a handful of occasions have I succeeded and once I even fell in love. Something special happens when you work in a team over days, months and years. You share a lot and you show a lot, your good ideas and your dismal ones. Then, all of a sudden, there’s this thing happening. You find yourselves standing up for one another against clients rejecting your designs, project managers berating you for missing a deadline, or rallying troops to follow your shared suggestion to go to a particular bar for Friday evening drinks. One thing leads to another. Late nights working together become late nights drinking together and the next thing you know you’re hiding behind the back of a couch in the office ‘chill out space’ half naked at seven in the morning because the managing director has come in early and you thought it would be kinky to have sex at the office.

These are good times. These are times to cherish.

Then it all changed. One day I had the smart idea to put some of the wireframes I’d designed in front of some of the people at work (the secretary, the tea person … ). I’d read about this in an article about guerrilla usability testing and I thought I’d give it a try. I discovered that a different kind of creative magic occurs when you expose your designs to users. You start to see yourself in the design; you start to see yourself from above, from the outside. Unknown to me then, I think something fundamental shifted in me, both as a designer and as a person by doing this. All the late nights and women and drinks and parties and drugs and havoc wreaking very slowly, almost imperceptibly, started to become a little less important. In considering users and other people a little more, I found myself thinking beyond myself and with it the slow death of my bohemian-artist persona.

Since then, I have become progressively more boring in my personal life. It did, however, take another four odd years of bohemian agency misbehaving for me to cut it out all together. So it was a slippery slope, but one I clung to with all my strength for as long as I possibly could.

When I now lecture students on UX design, I try to share with them something of a paradox I see in user-centered design. I try to stress a kind of tension between the designer’s ego and the removed, distanced input we receive from users during testing, for instance. The thing is, your users will never design a gob-smackingly-brilliant-interface-driven-experience. They may notice something, pull a face, make an observation or point out the obvious, which will begin a chain reaction of insights, ideas, new models, new navigation, new behaviour or structure that you realize and ultimately become the gob-smackingly-brilliant-interface-driven-experience. But hear me now: it’s you doing the designing, not the user.

So long live Hunter S. Thompson. Long live the Gonzo Journalist. Long live the b-grade wannabe rock ’n’ roll star creeping into your design. The designer’s ego matters. Loving your design, fighting for it, staying up late, night after night for it, trying to improve project after project for it matters. I sincerely believe that without this ego, you won’t amount to much of a designer. But then you wont getting trashed every night either, however it’s a fun excuse for a life stage while you busy yourself stumbling through the series of realizations that users matter, research matters, process matters, good client service matters, project management matters, other people matter, so you’ve got to respect it all.

About the Author

Jason Hobbs runs jh-01 / Human Experience Design, a design consultancy in Johannesburg, South Africa. Over the past 13 years his work in user experience design has spanned commercial, non-profit, arts and culture and civic projects. He frequently presents at international conferences, is a published author on UX design, mentors, lectures and actively works to grow the local community of practice in South Africa through the SA UX Forum.

Jason is an Affiliated Researcher at the University of Johannesburg’s Research Centre Visual Identities in Art and Design.

Web: www.jh-01.com

Facebook: Jason Hobbs

All Who Wander Are Not Lost

I’m pretty sure that Jerry Garcia was not talking about career development when he came up with the line that is the title of this story. However, it describes my career in information architecture, how I got here and why I am so passionate about search. Information is so vast and takes on so many forms; it defies singular description or containment. Some find it directly. Others take a more circuitous route as they deviate from their original quest to pursue more interesting paths. One path leads to instant gratification and the other can lead to sequential illumination. It is this ephemeral side of information that seduced me.

I now see that I was an information architect long before the term existed. I was always arranging things, from stuffed animals to comic books. When I was younger, I wanted to be a traditional architect. I was crushed to find out that this career choice involved a lot of mathematics, not my core competency. In fact, I freely admit to being math phobic to this day.

So, I said goodbye to designing buildings and hello to Hollywood. That’s right: I went from architecture to a brief stop at academic administration before ending up at the movies for 16 years. This was not as much of a stretch as you might think. Movies are constructs just like buildings and made up of components that represent a unified whole. There is an artistic element that is bounded by a framework. People “experience” movies and consume and incorporate them, just like information. Movies are collaborative, at least the good ones are.

Hollywood

I started my movie career with a one-year fellowship at the American Film Institute (AFI). The time was the late 1970s and films could not get much better. “Annie Hall,” “Star Wars,” “Apocalypse Now” and “Raging Bull” were setting the tone. The movie-goer’s—the “user’s”—taste had changed and so must the process of finding and making movies. Out went the Old Guard and in came a much younger executive staff at the studios, fresh from war-ending protests at Ivy League universities to studio properties where excess was so pervasive it was the rule instead of the exception.

At AFI, I studied with other professionals hoping to get further into the film business. Unfortunately, that is not what AFI was about. Their purpose was to educate through a conservatory model and finding work after the fellowship was not part of the curriculum. Getting the first job is always the hardest, and in Hollywood, it actually relied on luck and a flexible moral framework more than intellect or preparedness. Somehow, I was able to put the right combination together and secure a position as the assistant to a television producer.

My career began in earnest when a friend at AFI photocopied the Director’s address book for me. The Director was a very well established film industry executive and he had the home addresses of everyone who was anyone in Hollywood. This enabled me to bypass the administrative watchdogs at the office and send my plaintive inquiries directly to the highly influential individual’s home address. I landed the job of Paula Weinstein’s assistant while she served as the first woman president of a major motion picture studio, United Artists. I had the best seat possible to observe how big studio movies were made. During Paula’s tenure, United Artists started or released “Yentl,” “Swing Shift,” “Poltergeist,” “Rocky III” and some others that do not bear mentioning. I finished my career as the Vice President of Development for Renfield, the production company formed by Joe Dante and Mike Finnell (“Gremlins,” “The Howling”).

The core function of my job was to find material to make into movies, and involved two critical activities, reading and eating out. I proved to be accomplished at both. I would read everything I could get my hands on: scripts, books (old, new and yet-to-be published), magazines, newspaper articles, comic books, trading cards, and other movies, anything that could inspire a movie. I also ate out a lot, breakfast, lunch and dinner meetings with agents, writers, executives and other producers. I would also have writers come in to tell me stories (also known as pitches) in the hopes of getting paid to write them.

Storytelling is a form of information transfer. Stories have a message that is essential to convey, a presentation that makes them appealing, a structure that makes sense to the listener. In my specific role, I had to “discover” information (stories or scripts) and then repurpose them with structure (three acts for theater releases and five acts for television) according to best practices of dramatic construction (crisis, conflict and denouement). I was working with the writers to build the framework of a film so that the director, crew and actors could make this framework come to life on the screen.

We all practice a form of personal information architecture from our bookshelves, computer hard drives and work spaces. Everything has a place that makes sense to us and where we can find it time and again. For me, one can claim the profession of information architecture when one is able to apply this ability to organize personal information in a way that makes sense to a large user base. I developed movies that made sense to me and to a large segment of “users” who want to go to the movies. It was not until I found information architecture many years later that I realized I had been practicing it in Hollywood and just did not know it by that name.

All good things must come to an end and sometimes not-so-good things too. My time in the movie land dream factory ended in 1993 when I relocated to the Pacific Northwest to work on something more tangible and meaningful. My first stop was as the creative director for business products at a commercial film agency in Seattle. The idea was to produce an instructional media package on job loss for companies experiencing downsizing. This package included a workbook and a 30-minute documentary-style film on the methods of coping with grief and loss.

Again, I applied information architecture to this task. I gathered information on the various stages of grief and applied additional information on practical methods to get through unemployment to find another job. The project went so far over budget due to directorial insanity that the entire company was laid off, and try as I might, I could not find a position in Seattle where the core job skills were eating out, talking on the phone and reading. The technology sector was hiring Hollywood expats to work on CD-ROM role-playing games. This was familiar and seemed like something I could do. There was one minor problem; I did not know anything about technology. Up to this point, my experience with computers was limited to a love-hate relationship with DOS.

Introduction to Software

The Software Product Management certificate program at the University of Washington came to my rescue. I am eternally grateful to my fellow students, who patiently helped me through the course of studies. As bad luck would have it, by the time I finished the program, the gaming industry caught wise to the hazards of hiring Hollywood veterans for story development, and that was no longer a viable career option. While I had broken my addiction to eating out, I still had to eat.

A temporary job with MediaPassage, a media software startup, turned to full-time, and I ended up with a practical application of the certificate I had just earned. The product was advertising software that ran on top of Excel and allowed users to estimate how much a newspaper print campaign would cost. I started out as a gopher that did everything. As the company grew, I migrated into data integrity and became responsible for collecting the data that populated the program. I learned a lot about software development, database construction and operation, sales, customer support and the Web.

In 1997, the Web was just starting down the tortuous path of commercialism. SEO was in its infancy, with lots of trickster methods that refuse to die to this day. AltaVista, from Digital Equipment Company, ruled the search world, with Northern Lights and Copernicus right behind. Jim Allchin won the war of attention at Microsoft and hobbled the company with box software in the infancy of the game-changing Web. It was at this time that I stumbled on the early concepts of structuring information, with the discovery of Richard Saul Wurman’s book Information Architects. I was sold on the idea that I could build things and not be good at math. I scoured the Web and read everything on information architecture that I could find.

I left MediaPassage when it became apparent that the 25-year-old from Florida State University would be managing the website instead of the 40 year old from Hollywood with a deep fascination with the exotic field of IA. I hung out my IA shingle and found some early converts to the concept of structuring information for discovery. My first job was for a local telecommunications company that was promoting a new telecommuting service offering. They had a very large pile of supportive articles and research that they wanted to convert to a more consumable and searchable form for the sales force. I transferred the articles to an Excel spreadsheet, created a taxonomy that the sales force would understand, and then tagged and categorized the content. If someone needed a citation on the ROI of telecommuting, they could go to this resource and find a number of quotes and article citations. This was the first time I felt like a real information architect.

I also got a crash course in the economics of consulting. You work. You send invoice. You wait. You send second invoice and wait more. Lesson learned in six short months, and I took up a contract position at Microsoft. If you have a broad imagination, my role as a Content Coordinator had some components of information architecture. At least it was a steady paycheck and working on the Web.

Inside the Borg

In all my professional life to this point, I have not worked with a stranger cast of characters. The team was made up largely of contractors at a peer level. There were tyrannical propeller-heads and an office mate who spent most of her time day trading tens of thousands of dollars in tech stocks. The manager was too absorbed in planning exotic vacations to get involved. I called them Team Titanic. A friend once told me that I was very good at “leaving the circus when only the clowns were left.” It seemed this was the case at Team Titanic, and I made my way to the lifeboats after six months.

The agency representative swore that the new team was different, and indeed they were. My job title was Web Producer. The hiring manager was most interested in my IA background and wanted someone who would bring best practices in to the multiple redesigns of the Microsoft Servers and Tools product websites. She concluded that I would be a good fit for the job after my on-the-spot navigation redesign ideas for one of her sites. In the Workforce 2000 initiative, I accepted a full-time position with the team. I decided to deepen my knowledge of IA through study as well as practice. I attended my first IA/Design conference, the Landscape of Design, put on by the now defunct Chicago Institute of Design, in 2002. Marc Rettig gave an inspiring talk on information architecture.

The good times did not survive the first of frequent team reorganizations. The last one brought in senior management whose idea of information architecture was one-for-all-and-all-for-one navigation across all of the product sites regardless of functionality or user-base. A personality conflict with the new Director of the group signaled the end of my career with the team. An interim manager encouraged me to apply to the Master of Library and Information Science program at the University of Washington. He believed that this would make me more marketable to other teams at Microsoft. Unfortunately, the Director of my group made it clear that no search team would have use for someone with a “library degree,” and did everything in his power to make that opinion a reality. So, the only direction my career as an IA specializing in search could take would be outside of Microsoft.

At one of the IA Summits, Jesse James Garrett asked in his presentation: “How would it feel to have a brand worse than Microsoft?” to which I answered (a bit too loudly), “Nice.” While Microsoft receives a lot of criticism, I found the IA “street cred” solid. It just needed some evangelization. With a colleague, I started the Microsoft Information Architects, an online community, to discuss IA that grew to 300 cross-discipline members worldwide. In 2007, Microsoft started sending presentations to the IA conferences.

Agency Life

I left Microsoft to go to work as an IA at Ascentium, a technology agency based in the Pacific Northwest. Ascentium was building out a digital marketing division and was in need of IAs to design the websites. This was the first time I held a job with the title of IA. In my interviews, I mentioned my specialization in search.

In an agency, you are expected to contribute to the profitability by “paying for yourself” through billable hours. It is not an environment to be seen being idle. So, while waiting for IA work, I started building a search practice that included search engine optimization, paid-search and enterprise search configuration. All of my time and attention was soon devoted to search, as clients began specially calling it out as a deliverable.

I have always seen search as inextricably tied to information architecture. User behavior towards information directly impacts how they find it and what they use to find it. Common sense would dictate that the user experience should drive the development of search systems that would result in perfect search. At the 2006 IA Summit, I represented Microsoft with a poster session on Next Generation Search. The goal was to visualize how search engines progressed from simple pattern-matching mechanisms to context-sensitive mediators, or as Larry Page, co-founder of Google, describes them, “reference librarians with a complete mastery of the entire corpus of human knowledge.”

Evolution of Search

My thinking coalesced further at the 2007 IA Summit, with a presentation that directly tied IA and search engine optimization (SEO) together. Search engines respond positively to structure. By creating a core foundation of metadata to describe the goods or services, and structuring the site, content and linking structures to support this core metadata, the search engines are more likely to perceive the site as being highly relevant to searches on core metadata and related concepts. My presentation was a “call to action” for information architects to design sites that were available to search technology as well as users.

Search and IA

In the movies, things are easily found online. The users actually use the Web site’s navigation, and search engines work great in the movies. Not so in the real world. In the real world, users visit a myriad of websites in any given day. In 1997, there were 200 million Web pages. By 2005, this had grown to 11.5 billion. In 2009, Google claimed to have discovered 1 trillion Web pages and to have over 126 billion of them in the Google index.

This information explosion takes the navigation that was so painfully crafted out of the scope of the user’s attention, because they are focused on the center of the page before they drift to the site search box or pogo back to the search engine results and click the link to the next likely candidate. Mark Hurst refers to this as the Page Paradigm[1] and George Furnes refers to it as Effective View Navigation[2]. Users visit so many sites that they do not have the cognitive bandwidth to figure out each navigation schema. They want to find what they are looking for and move on. It is no wonder that search has become the dominant wayfinding method.

The engineers have done their best, with dramatic advancements in relevance algorithms that focus on page topic and quality, and reward computation over mediation.

Topic-Sensitive PageRank is context-sensitive relevance ranking based on a set of “vectors” and not just incoming links. It is a “birds of a feather flock together” pre-query calculation based on the context of terms used in the document, in the history of queries, and in the behavior of the user submitting the query, which is reported to use the Open Directory for a loose ontology.

HITS (hyperlink-induced topic search), developed by Jon Kleinberg at Cornell, is a link-based algorithm that reveals the emergence of “authority” resources on a particular topic, and affords more weight to links from authority resources. Hubs are navigation pages that focus on authority pages for a certain topic.

So, game over as IA loses, search wins and we should all become interaction and experience designers? Not so fast. There is still time for us to claim our place at the search table, and rightfully so. As IAs, we represent the human experience in search. Instead of the tireless discussions on what IA is, or who is better, IA or UX, we should become a partner in developing more user-centric search technology. The pointy-heads need to join forces with the propeller-heads in building search systems that facilitate a better understanding of the spatial relationships of information spaces[3]. It is time for us to reclaim our place at the information-seeking table, and our approach should be strategic.

Structure can be an aphrodisiac. Search engines like structure and perceive it as a human indication of relevance. If something stored in the garage attic is less important than something stored over the coffee machine in the kitchen, then a page buried deep in the site structure must be less important than something closer to the home page. Right? Well, that’s how the search engine sees it. So, use distance in the structure to reinforce context and relationship. Extend the structure to the page itself. Search engines read pages like we read newspapers. They reward the content at the top of the page with more weight. Does the big Flash or Silverlight application really have to be there? Then annotate the darn thing with meaningful text.

Use navigation to build relational content models that play to the topic-sensitive page ranking. Develop link components that encourage the user to explore related concepts or break off to explore new directions. Relational content modeling focuses on what the user may want to see next, not what the business unit may want them to see next.

Links are valued as human-mediated relationships. Break free from the site or enterprise organizational constraints to produce views around a specific topic. Create a link-based relationship model of relevance by designating authority resources on your sites as well as hub pages. Use your authority or high-ranking pages to transport users to related areas of the site. Search engines now reward off-site links as much as those that point to the site. So, freely send users to useful authority resources outside of the domain. They will come back because all who wander are not lost. This thoughtful approach to relationship building is rewarded with higher placement in the search engine results.

The fold is dead. Even Jakob Nielsen said so[4]. So, let us bury the minimal content structures that have been the order of the day so that all of the messaging could be viewed above the now dead fold (an ironic carry over from the truly dead, in the case of newspapers, or dying, in the case of book publishing). It is true that humans do not like to read from a computer screen for long periods of time. However, humans are crafty and have developed coping mechanisms for this, such as: scrolling, printing out pages, bookmarking the page, emailing the URL to themselves, etc.

Search engines DO read (in a manner of speaking) and use the location of text on the page as a core element in relevance calculation. For search engines, real estate “above the fold” does have some meaning, based on human behavior as seen in the Newspaper Model. Content components found in the upper quadrants are weighted more for relevance than those placed at the bottom of the page. Design page structures in such a way that the most important content is elevated to the top of the page and supported by additional content made available to user and search engine.

Search engines do not have eyes, ears or opposable thumbs. So, all of the stunning Flash or Silverlight applications, sound accompaniments, buttons and such are not visible to the search engines that users will employ to find them. As guardians of the experience for all users, I believe that it is our responsibility to ensure that what we design is accessible to all, including the search engines that we use to find information. To accomplish this for rich media, it is critical to present annotative text for the search engines to use in indexing the content. As for videos; the search engines are now using speech to text transfer technologies as well as on the page annotation to find videos that are relevant to the search terms. So, if you don’t want a machine to “figure out what is being said,” design a page structure that allows for either a thumbnail synopsis or publish a video sitemap.xml configuration file so that a human editor can contribute to the search engine’s calculation of meaning and relevance.

The major search engine companies employ many interaction designers to make sure that the picture around the plain white box has the right detail, that the buttons are still correctly labeled or that the single column of results looks like the other engine’s single column of results but in a different way. The Interaction Design Association listserv discussion on Doug Bowman’s departure from Google[5] is a fascinating treatise on designers and engineers working together.

Until information architects get a place at the search engine design table, we must work from the outside. We should pay as much attention to how our users find our site as to how they find their way around our site, often using a site search engine that works the same way as the one that brought them to the site in the first place. We should design site and page structures that leverage the technology for the good of our users.

Search is a fundamental part of information architecture because we build our sites to be used and discovery is essential for use. Search optimization, whether for general Web search engines, public-facing site search or intranet search, is a core component of wayfinding. The methodologies presented here work across all forms of search, tacitly through participation in the design of search systems, and explicitly by creating revealing site and page structures with contextually-related pathways through our sites.

Until we are able to claim a place at the system design table or Larry Page’s vision of “perfect search” comes to pass, that will have to do. I have more confidence in the former than in the latter because I believe that IAs think better than machines.

About the Author

Marianne Sweeny is a recognized expert in the information design field and a member of Ambient Insight’s Advisory Board. Formerly with Microsoft Corporation from 1999 to 2006, Marianne pioneered development and implementation of numerous search optimization and information architecture improvements on www.microsoft.com, one of the largest and most complex Web sites in the world. In 2002, her work was recognized with the Divisional Vision Award.

An accomplished presenter and leader, Marianne has shared her knowledge of information systems at the American Society of Information Science and Technology, Puget Sound SIGCHI, and numerous seminars. She is also an active member of Information Architecture Institute, Content Management Professionals, and Women in Digital Journalism. During her employment at Microsoft, Marianne started Microsoft Information Architects, a cross-discipline, global community of practice with over 300 members.

In L.A., from 1980 to 1993, Marianne acquired and developed content for feature film and television projects for Paramount Pictures, Warner Brothers, Universal Pictures, and Walt Disney Productions. She created script analysis and production suitability reports, and supervised a studio story department with a staff of 14. In 1979, Marianne was a Producing Fellow at the American Film Institute.

Marianne Sweeny lives in the Greater Seattle Area.

[1]. http://www.goodexperience.com/2004/02/the-page-paradigm.php

[2]. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.83.8242&rep=rep1&type=pdf

[3]. Digital Ground: Architecture, Pervasive Computing, and Environmental Knowing by Malcolm McCollough

[4]. http://www.boxesandarrows.com/view/blasting-the-myth-of

[5]. http://www.ixda.org/discuss.php?post=40237

Watchmakers

Since 1876, all the sons of the Memmel family have become watchmakers, goldsmiths or dispensing opticians. From an early age, I was raised to be a successor in our family business. However, I am all fingers and thumbs as regards a skilled trade. Of course, I tried to make up for my lack of talent at craftsmanship. As a teenager, for example, I spent the Easter holidays in an internship as a fitter and welder in a ball bearing factory. It was very exciting and informative; however, I did not turn into a talented fine motor skills person. I think it became clear about then that I would not become a master watchmaker.

As a twelve year old, I already thought that my Commodore 64 was way more exciting than welded joints and tools. I was already enthusiastic about microprocessors as a three year old. My parents tried in vain to get me rid of my pacifier and my cuddly blanket. Their tricks didn’t work until my Mum offered me a calculator as a bribe. She had set the course for the rest of my life.

About 25 years later, I left the University of Constance with a PhD in usability computer science. I was the first graduate in this field and the press reported in 2009 about my three-cycle Bologna Process academic career in Constance. I never lost sight, however, of more than 100 years of family tradition. Despite studying computer science instead of taking the examination for the master craftsman certificate, I was able to combine the arts of watchmaking and goldsmithing with the modern age. Today, I work as a usability engineering consultant in Switzerland and have been selling watches and jewellery over the Internet throughout the world for 10 years.

This is my very personal user experience as a student of human-computer interaction, and as an executable prototype of a new generation of my family.

Schweinfurt

Just before the turn of the millennium, the boom of the new economy had also reached my Bavarian hometown of Schweinfurt. Meanwhile, I had moved into my first apartment and was doing community service (the alternative to compulsory military service) in a nursing home. Helping people dressed in white scrubs left many formative impressions. At the time, I didn’t know that I would later be helping people interact with computers. Similarly, little did I know that sometimes it would feel like being a plastic surgeon, merely in a different industry.

If I hadn’t already have been enthusiastic about computer science, I would have been the moment I plugged in my first 56k modem in my apartment, and my Apple PowerMac dialled into the endless spaces of the World Wide Web. Shortly afterwards, we invited my parents over to surf on the internet and philosophized about the idea of providing information about or even selling watches and jewellery over the Internet. The interactive experience of the Internet on this occasion was beneficial to their openness in regard to this medium later on.

A few months later, after working double shifts, I had saved enough for an online shop. After I finished working at the nursing home, I moved on to our family business. I sat in the watchmaker’s workshop where I had installed a PC workstation, only I set up an online shop instead of repairing watches. In retrospect, this spatial synergy of tradition and the modern age set the stage for the future of our business.

At the beginning of the online project, I also had the support of a small agency. However, I quickly started to develop more and more of my own ideas, which would have been too expensive to implement by a third party. Thus, I started with web programming, five years after writing my first lines of code on the C64 in BASIC. I collected and implemented requirements from the sales people in the shop. I researched the information that was relevant for a customer before buying and tried to reproduce these criteria on the Internet. Without me noticing, a solid IT value chain was established, and I learned more and more about the exciting watch and jewellery industry.

Shortly after the opening of our online shop in June 1999, I sold my first watch over the Internet. It was a radio clock by Junghans and was the beginning of an entrepreneurial change that would gain momentum from year to year. Selling this first watch over the Internet also marked a change in my life. Hardly a day would pass without me programming, configuring and optimizing the shop. The customer was king in the online shop, and for a few years I was the troublemaker in a still very conservative industry that was not yet ready for online business.

Still, during the same year, we were reviewed by a trade journal and compared with other shops; emphasis was placed on ease of use and the site’s navigation. Ah! More than anything, ease of use at this time meant foolproof to me. For example, the pictorial user guides that I was writing for my father needed to be foolproof, in order for him to be able to use his DVD player. “Press the button at the top right of the device to turn it on. Insert an empty DVD. Switch the TV to the AV channel. When the DVD player is turned on, you will now see a blue screen with the logo of the manufacturer.” Most of my user guides were several pages long, even when I was just describing simple tasks. In comparison, the manufacturer’s user guide was like shorthand and in no way sufficient to explain how to use a DVD player to the aging fathers of this world.

Today, I know that my family’s requirements formed my desire for user-oriented description and action. Even in my present professional life, I write a user guide every now and then. At some point, everything seems to come full circle.

At the end of the 1999, it was time to begin my studies. In October 1999, I enrolled at the University of Constance at Lake Constance in Germany for the new Information Engineering Bachelor and Master Degree programme. In advanced human-computer interaction studies, customers and users took centre stage. The graduates would mediate between business and IT and develop customer-oriented software. That fitted very well with my previous experience and so I packed my belongings for the move from Schweinfurt to Constance.

The Usability Drummer

In Constance, I quickly learned that website development constitutes only a small part of computer science. From that point on, I agonized through basic lectures such as theoretical computer science, maths for computer scientists and some other topics for which I couldn’t build a mental model for a long time. However, I really enjoyed Java programming. After all, learning object-oriented programming is very useful as an introduction to many languages, including JavaScript, Action Script and PHP.

Whatever I learned at university, I could immediately use to improve the watch and jewellery online shop. I think my first Adobe Flash movie was an animated clock for the start page. Later on, I developed or adapted several other animations in Flash, such as product slide shows. The work on my own shop system was also groundbreaking for me with regard to return on investment of usability engineering methods. Many activities for improving interactive behaviour, the navigation or product descriptions were directly reflected in the success of the business. Thus usability was double the fun and the outlook for financing my studies were good. Thanks to the income of the online shop, I was also able to assemble a very valuable library of technical literature that has proven to be useful to date.

I was happy that I was already able to engage in user and customer-oriented work outside of university. We didn’t cover the user of software until the end of basic studies. The top priority was development. Back then, sarcastic people argued that this would be exactly the same in many projects to come.

When we finally started learning about usability, we were really excited. The human-computer interaction professor was a tall, charismatic man who knew how to inspire his audience. He always convinced his listeners with his astounding knowledge and thus dictated the rhythm of technical discussions. In my opinion, he is the usability drummer of Baden-Württemberg. He also showed me that as a usability expert, one should not be a spectator but should strive to play in the band.

Despite the significance of usability today, often it only gets a backstage pass. It’s not up there with an instrument on stage, where the hits are performed. Usability engineers are often the roadies rather than the stars, ensuring that at least the visual customer experience is correct.

In my two years of advanced studies, I finally attended my first usability seminar, during which I was occupied with the design of embedded systems. This topic led me to Munich in 2001.

The Usability Enlightenment

For my term paper about embedded systems, I contacted the development manager of an automobile manufacturer, who invited me for an interview. As the task demanded, I was well prepared and expected an exciting and educational talk about the genesis of a user-oriented car communication system. However, usability engineering processes, such as the then popular Mayhew lifecycle, were unknown to the car manufacturer. Unfortunately, the car was defective and one couldn’t test the system. Finally, the development expert declared that neither time nor money sufficed to complete the system with optimal operational quality.

The world then discovered the rest of the story in various test reports and forums. The car’s buyers were not able to use the system, whose main functions were hidden deep within the navigational structure. If one wanted to program a radio channel during a trip, for example, one was confronted with an entirely new customer experience—not necessarily a pleasant one. The manufacturer had developed the system without keeping the requirements of his target group in mind.

Personally, the interview was a big disappointment at first. Were all the success stories and slogans of the usability engineering gurus nothing but smoke and mirrors? Fortunately, not every company burned their user requirements in high-octane fuel and eight cylinders. A few years later, I wrote my first technical article on the topic of agile methods, aiming to establish principles and practices whereby usability projects could be conducted successfully, even under challenging circumstances.

Interestingly, the client was a car manufacturer that supposedly wanted to draw timely conclusions from the mistakes of others for his own product development. Even today, negative experiences and reporting encourage me to think about new methods and processes.

After another visit to Munich, infotainment systems and automotive usability engineering would become my main focus for half a decade.

Munich—Beer, Pretzels and User-Centred Design

We Franconians are hearty and friendly people and therefore I decided to continue my stay in Munich in order to give my Bavarian kindred a little hand in the matter of usability. After gaining my bachelor’s degree, I left Constance and Baden-Württemberg, once again to work as a user interface developer for a big technology corporation.

Once there, I got into a development project for a multi-modal mobile device. A lot of usability engineering experts were working at this company, most of them even had a PhD. That really blew me away and I learned a lot during this period; among other things, that good communication in the team (at meetings in the beer garden) is very profitable for the success of a project.

In addition, we had a very interdisciplinary team. While a colleague and I programmed in Java and Flash, other developers were building voice recognition and output in C++. Two designers helped us with the configuration of the user interface. The systematic integration of various experts in the development process, as well as appropriate tools to achieve this, is a point to remember and is uppermost in my mind. Normally, the representatives of each species work with their own tools. Designers use image editing and layout tools; usability experts build paper prototypes and draw storyboards; developers model with UML and write code. Most of the time, a common thread of means of expression is missing and therefore media disruption causes many misunderstandings, longer consolidation periods and ultimately, higher project costs. The future belongs to tools that provide an integrated platform, but still offer specific views to experts.

One day, my phone rang in Munich. It was the usability drummer from Constance. I was to become one of two front men in a usability band. The concert promoter was one of the big players in the automotive industry who wanted to gain customers with user-oriented software in the future. Initially, the whole customer lifecycle would be supported through new concepts for digital distribution, within the scope of close industry cooperation. This was to be a full position as a research assistant during my Master’s course, with the prospect of continuing in a PhD position, financed by the automobile industry. It was the opportunity of my life. I could already see my name on a plaque in the hallway of a big corporation and I accepted immediately. It was the most important path I had taken in my life to date and the beginning of a long-lasting friendship with the aforementioned usability drummer.

So I speeded up in Munich so as to finish the project faster, which worked out pretty well. Later, a report was aired on commercial television about our mobile talking purchase advisor. At this point in time, I had left Munich and its Beer Festival behind, including the aesthetically pleasing dirndl. Instead, I shared my office with a very good friend at the department of human-computer interaction, started my Master’s studies and worked more than 80 hours a month as a research assistant and usability consultant for the automobile industry. I was very proud and happy—usability seemed to have become a good and successful path for me.

Usability Turbo Boost

Michael Knight and the Foundation for Law and Government were the ethical values of my youth. The miraculous KITT is to date an unfulfilled childhood dream; a black Pontiac Firebird Trans Am with turbo boost, super pursuit mode and perfectly designed dashboard is the user-centred product innovation of the millennium for me. KITT was the iPhone of the 80s. From my point of view, no car manufacturer ever developed a more beautiful arrangement of controls. Did Michael Knight know about user experience?

Now I had the opportunity to work for an automobile manufacturer and integrate some of my Knight Rider fantasies into real products. From 2005 onwards, from out of Lake Constance, we had won over several car manufacturers as cooperation partners and customers, who let us develop new control concepts for digital distribution channels, car configurators, car communication systems and even rear seat entertainment systems.

The diversity of the projects and the methods, which were key to the success of the project, turned me over the years into someone Agilistas would call a “generalist specialist”. This species is also known in colloquial language as a jack-of-all-trades. This means that usability seldom comes on its own. I still live and work according to this philosophy and I am furthermore trying to think outside the box of human-computer interaction through continuing education in areas such as development, requirements engineering and project management. This leads to a better understanding of the point of view of other fields and additionally allows a usability expert to considerably better integrate diverse stakeholders.

Singapore

With the results of our work, we went on a usability world conference tour. Then I made a pit stop in Singapore for six months, where I worked in the IT management of an automobile manufacturer. This position came about through a—by this time—long-time industry cooperation. Despite the crisis in the automobile industry, I had received a fantastic opportunity for a stay abroad. The position wasn’t directly linked to usability, however it was all the more about business processes and software development. As project manager, I gained insight into these important areas that usually also strongly influence usability projects. I am still trying to show ways to connect those disciplines with usability engineering for a reason. Integrated approaches, which consolidate all three disciplines, are still rare.

One day, word got out in the tower building of the automobile group that I managed the online business of my family from Singapore. Before I could refuse, I got involved in two intranet projects as well and my Asian colleagues named me the Internet Magician. The comparison of my work to magic is one I still come across frequently today. User interface design is perceived as obscure mumbo jumbo by many. In the end, however, this is quite inspiring. Maybe it would not be such a bad idea to open up my own circus with my painfully learned tricks at some point. After all, other magicians got wealthy and married a super model. However, I decided to return to Constance to advance my academic career.

Who Turned Back the Clock?

After my return from Singapore, I started my dissertation about user interface specifications of interactive systems. During this last part of my career, I was also accompanied by the automobile industry. Several automobile manufacturers realized at this time that text specifications were no longer sufficient for successfully developing the ever more demanding software systems in a vehicle, as well as those in automotive engineering and selling. Thus, I designed an interdisciplinary specifications method, based on UI prototyping, and developed a tool to support a specifications process driven by usability. After finishing my dissertation, this work was published in 2009 as a book with the title “User interface specification for interactive software systems”.

Those last years in Constance were full of fruitful experiences, innovative ideas and human maturing processes. My doctoral supervisor has been and remains my close confidant, coach and friend. I don’t know if I will ever learn again so much about myself and my profession as during this formative time.

For a while, I entertained the idea of staying at the university. A good friend of mine did this and became a young professor. However, I always really enjoyed the diverse projects of the automobile industry and the different internships always inspired me to work as a consultant. I therefore started to look for a job as a consultant at the end of my time in Constance.

Expatriate

In the meantime, my girlfriend had moved in and commuted to work in Switzerland. The proximity of Constance to Zurich and the beauty of Switzerland moved a few companies located in the east of Switzerland that were interested in usability to the top of my wish list. A very skilled recruiter helped me to sharpen my profile and choose the right positions to apply for. I was lucky to be able to closely review a larger selection of attractive employers. I was also positively surprised at how well developed the job market for usability experts had become in the meantime. A few years ago, the profile of a usability expert was hazy for many companies.

Due to lots of years in the e-commerce business, I was naturally also interested in appropriate positions in other companies. After all, I was already able to connect usability and e-commerce, be it in my own company or in the automobile industry, for which we had designed new websites from Constance. Actually, I also found some very good positions, however in the end I went for a stronger emphasis on usability.

The upside of the job search experience is the lesson that one probably never does anything to no purpose in life. Before, I often questioned how the setup of an online shop for our own family business would be judged by a third party. I was very happy about the respect and the recognition. I can only recommend holding on to your own projects and gathering experience accordingly. Very likely it will pay off in most cases.

Record Deal

Many interviews were in some ways still symptomatic of the job description of a usability engineer. Many interviewers refused to believe at first that, as a usability expert, I was able to write source code. Many a time, the conversation was simultaneously an attempt at clarification of the interdisciplinary and diverse nature of the field of human-computer interaction. Admittedly, it is difficult to conceive a functioning mental model of the skills of a usability engineer, considering the many different terms. What exactly is the difference between a usability engineer and an interaction designer? And what does a GUI developer actually do? Try to explain this to your mother. Then you will understand the confusion of the HR officer.

In fact only 10% of usability experts come from computer sciences as per recent industry reports. That is rather few, and therefore it takes a bit of convincing when one is asked about one’s programming skills. Given that one is asked about them at all. But don’t be afraid; experience with development does not turn a usability expert into an alien, but into a valuable associate along the IT value chain.

Besides, the profile of a generalist specialist does apply to a lot of usability professionals that I know:

“A generalizing specialist is more than just a generalist. A generalist is a jack-of-all-trades but a master of none, whereas a generalizing specialist is a jack-of-all-trades and master of a few. Big difference. A team of generalists can easily flounder because none of them have the skills to get things done. Similarly, a generalizing specialist is more than just a specialist. A specialist is narrowly focused on a single topic, making them very effective at that topic but not at others. Specialists will often be blind to the issues which other specialists focus on, and as a result will struggle to work with those other specialists effectively. People who are generalizing specialists are in the sweet spot between the two extremes of being either just a specialist or just a generalist, enjoying the benefits of both but not suffering from their drawbacks.” (Scott Ambler)

I think that a lot of people who dedicate themselves to usability and user experience, bring with them an incredible openness and a big interest in other fields. It may be true that one’s variability is sometimes in one’s way. Many companies prefer a pure specialist, which is reflected rather clearly in many job descriptions. But ultimately, there exists a appropriate usability band for most of us by now.

I finally signed a record deal with a consulting and services company in Switzerland at the end of 2008. There I record my new songs in the test studio as a usability expert or duet with my colleagues at lectures and conferences. I am even allowed to sing Java, if I want to. Otherwise, I also appear as a conductor in courses. The bridge to Asia still exists for me; I hold certification courses in requirements engineering in Malaysia. In the meantime, I also play other instruments as well as being a methodical drummer—sometimes even at the same time.

In the past, all-round entertainers have appeared on public television with approximately 20 instruments attached around their waist. Usability experts know the art of a one-man show only too well. One dictates the methodical rhythm with the feet, plays the business organ left-handed and a single-handed guitar solo for the development department with the right hand. As a piper, we try to play the tune of a whole gaggle of stakeholders. Nice usability projects are like a polonaise of technical experts and end-users.

Self-winding Automatic Clockwork

The beauty of usability engineering is that there is, in fact, always something to do. Bad control concepts will probably never become extinct. Always stay on the move and wind yourself up with the help of new projects. This way, you ensure that your methodical clock movement never runs slow, that you are not missing out on a new development and that you always stay ahead of your time.

Apropos: Did you know that there are now even wristwatches with a touch display? Or that there are watches that display the time as binary code? User experience is everywhere and confronts us with many faces. If you’re not already on board, check your time. It is 5 to 12 for the era in which software and products were no fun. From now on, everything will change.

Usability and user experience drastically formed and influenced my life for the last 10 years. I am looking forward to the future of this fantastic, successful and emotionalizing field, which is inspiring more and more people.

Time is in favour of user experience and of a career as a technical expert. Watchmakers are also very welcome as career changers.

About the Author

Dr. Thomas Memmel was a research assistant at the University of Constance at the chair for human-computer interaction. He holds a BSc (2002) and MSc (2005) in Computer Science. He was involved in a DaimlerChrysler AG funded PhD program and has previously taken part in other national and international HCI related projects with a special focus on automotive information systems engineering. In 2009, Thomas Memmel started working for Zuehlke Engineering in Switzerland as Usability Engineering Consultant and Requirements Engineering Trainer. Since summer 2010, he manages a business unit specialized in client technology and user-centered software development.

Web: www.usability-architect.com

Xing: www.xing.com/profile/Thomas_Memmel

UX Goes Viral

Warning—UX May Be Contagious

Yep, I’ve been infected, and if you continue reading this story, you run the risk of becoming a little infected, too. Or you may realize that you already have been, or that you would like to be, at least. Did I mention that you’re proceeding at your own risk? Please reconsider. There is no way back.

Beware Of the Symptoms

So you’re still reading? Great! But I did warn you. Do you remember your first cigarette? The first time you had sex? Your first taste of foie gras? The first person you fired or the first time you got fired? It changed your life, didn’t it? Nothing was ever the same again. You started to look at things a little bit differently. And there was no way to get back. Get back your virginity, your innocence. It’s the same with this disease. Once you’ve got it, there’s no one who can help you to get back.

The symptoms, as with most diseases, vary slightly in each individual. Some people may contract the disease faster, in others it takes longer, some people are born with it to some extent, and some people are (how fortunate for them, but unfortunate for us) totally immune to it.

So what am I talking about? Easy to guess, right? This is not a collection of horror stories, it’s a collection of user experience (UX) stories. I’m talking about how those infected by UX look at the world around them through a user experience “filter”.

I realized that UX plays a big role in many of my decisions; the kind of car I’m going to drive, the hi-fi equipment I’m going to purchase, etc. These days, whenever I use anything, I evaluate it more or less from a UX point of view. I found out that I was “different”, simply by talking to friends in the pub and elsewhere, and to people around me from other fields. Some of them prefer mainstream products (“everyone else has it, so it must be good”) and some of them prefer those products with the most features, but hardly anyone said that they picked a product just because it was easy to use, for example.

This story is about how I caught this “disease”, what it’s like to have it and about my everyday “struggle” with it.

How I contracted UX

My original background is deeply technical. I studied at a technical high school in Prague, with a focus on telecommunications, where we learned how to design and layout wiring (this was during the pre-cell phone era) and so on. We also did some coding (mainly very low-level) and hardware design (very often on a single chip level).

After that, I studied at the Czech Technical University in Prague, from where I graduated with a masters degree in software engineering. I obviously went through a lot of courses, focusing on programming and IT administration, low-level and high-level, but we also had mandatory classes in higher mathematics, physics, etc. We also had the opportunity to attend courses in other disciplines, like psychology, anatomy and physiology, rhetoric, and economics, which I considered highly welcome excursions to entirely different worlds. I have to admit that we learned very little about UX. I would say that the only contact I had with UX—but it was special—was when I worked on a project for BIS (Blind Information System), which was focused on users with visual impairments. This experience turned out to become very important later in my professional career.

Later, in tune with my university studies, I was employed as a developer, which allowed me to stay in touch with the real world. During the last year of my university studies (this was in 2000, the Internet bubble was about to burst and every IT company was growing like crazy), I took a unique opportunity and got a part-time job at the recently established Prague branch of Sun Microsystems. Since I had about five years’ experience as a developer and knew the whole development cycle, I was put in charge of forming the “User Interface (UI) Team”—a team whose mission was to implement the UI of the Net Beans IDE (NetBeans is what IT geeks call an Integrated Development Environment, in short, an application that provides facilities for developers to develop software).

Please remember that at this point I was still more or less an “innocent” as far as UX was concerned. I didn’t even know that things such as usability evaluation, user-centered design, etc., existed; we were only responsible for coding.

As it turned out, one of our first assignments was very unique—to make NetBeans Section 508 compliant. In human-friendly language: There is a law in the US called Section 508 describing how an application should support the needs of people with visual, motor and other impairments. It took us about a year to complete the job, and it was an outstanding experience. The basic knowledge I had acquired during my university project for BIS came in quite handy. In addition, we learned to look at UX from disabled people’s point of view, since we were cooperating with them and were using their tools. A great eye-opener! And this was one of the first projects of its size at Sun.

Besides, we were also playing the role of a proxy, liaising between the design team that was located in California and the engineering team located in Prague. After a while, our team and the management began to realize what seems obvious now: Firstly, things work out best when both designers and developers collaborate. Secondly, if you are responsible for the design, as well as its implementation, you tend to optimize your designs in order to make them easier to implement. Thus we made an earnest attempt to take over full responsibility for design, too. Because we decided that we wanted to learn from the industry’s best, we went on training courses with Cooper, NN/g, InContext, Jeff Johnson, and others.

After a few more years, we reached a point where our team in Prague became the general UX team. This involved hiring and mentoring the junior members, eventually to grow the team and attain a critical mass of people with appropriate abilities. The objective seemed to be straightforward, but it wasn’t—I will come back to this point later. Ours was the first and only “full-featured” UX team that Sun had outside the U.S., consisting of a local manager (me), interaction designers, visual designers and user researchers. Over the years, we have gathered experience with all kinds of applications, focused on enterprise (e.g., SOA), developers (developer tools), designers (Java FX-related tools), the end-user (email, calendar, IM), admins (middleware), and web 2.0 and mobile (Java ME). We didn’t just provide standard “UX services” alone, we sometimes also helped with HTML/CSS coding and search engine optimization.

So, what’s up?

So far the disease seems quite harmless, right? You’ve read more than 1,000 words and I still haven’t got to the point. I apologize, but I felt that you needed to know a bit of the background.

Anyway, here we go:

I heard about this “UX disease” for the first time, when Alan Cooper was talking about it and when I was chatting with other folks from his team at the training course. I thought it was so cool! They explained how UX has impacted more or less their entire everyday life: When they reach an elevator, they immediately notice usability issues with the controls, when they do an evaluation of their new car, they do so mainly from the usability point of view … and they were right. Many professions are like that; you start noticing things from your professional perspective that other people simply don’t see. Take, for example, my wife, who is a linguist; when she reads anything, whether it’s a newspaper or a book, she notices even the slightest mistakes, such as misspellings, style issues, etc., which I would simply overlook. Or if you are a hair stylist, you would notice more things about people’s hair when you look at them than anybody else would.

That’s pretty normal. But with UX, it’s different. Everyone struggles when they are forced to use a poorly-designed application or appliance, e.g., a washing machine. But we, the UX experts are able to put a name to it! Even worse, unlike ‘normal users’, if we aren’t able to use an application or device properly, we don’t blame ourselves, as the rest of the population would. Instead, we put all the blame directly on those who designed or manufactured it, and our patience threshold for bad designs is much lower than that of the average user. That’s exactly the point here—the number of choices available to us suddenly becomes very limited. Sometimes we have no choice at all, for example, when renting a car on a business trip or buying gifts. Having to use something which is unusable is so annoying, but one has to make do. It was so much easier when I was still clueless about UX, just taking things as they were, and if something went wrong, I simply blamed myself. But as I mentioned before, there is no way back.

I’ve picked a few examples from my daily life that help to illustrate the problem.

1. Our microwave. We received it as a wedding gift, which is something that’s very hard to refuse. So what’s wrong with this one? I have no idea what the designer’s intended uses were, but we use it mostly for heating up food. So I would expect it to have a UI optimized for this application.

Wrong, ours doesn’t. It has three buttons of the same size in a row. What are their functions? The left button is power on/off, the middle button is to set the clock, the right one is a timer. In other words, while we use the left one about once a month, the middle one only twice a year (to switch between summer and winter time), we need the right button several times a day. So why should they be the same size and at the same height? Let’s look at the icons now, are they descriptive, self-explanatory? I remember confusing the middle one and the right one lots of times, simply because the icons are not very meaningful.

2. A no-name alarm clock. It cost next to nothing, around three Euros, but it has two cool features: Firstly, it is radio-controlled and shows the precise time to the second. Secondly, it is capable of measuring the ambient temperature. We’ve had it for years and never got around replacing it. For the purpose that we are using it, it’s just fine. The only thing is, when our son plays with it (he is only two and a half), he pushes all the buttons, occasionally turning the alarm on, which is by default set to 7 a.m. This is ok, because we don’t sleep longer anyway. But when it starts beeping, we just don’t know how to turn it off again! There is a large button at the top, but it’s a pause button, so when you press it, it stops beeping for about a minute and then starts again! The only workaround is to remove the batteries …

3. My office telephone. Seriously, it’s not much of a surprise that I want to use my phone mainly for making phone calls. Why do nearly all office phones have dozens of buttons that you will never use, while the buttons you would use the most, seem of minor importance or simply don’t exist at all? A shortcut, for example, to forward calls from your extension to your cell phone? What I “like best” about my office phone: In the center of its number pad, there are two large buttons with arrows. My immediate assumption was that they are used for general navigation, for example, to navigate in the telephone directory. But no, the arrow buttons are used to switch between different menu levels. That’s all. To navigate, you can use a small button found in the second level menu, and it only works as a “next” selector. So when you accidentally press it eight times instead of seven times to call up an entry in the directory, you have to start all over again. Great.

I hope you can now understand my pain and that of others of our profession, with the same mindset.

Starting a Pandemic

So, are there any ways out of this predicament? I think there are two escape routes:

1. Isolate us to avoid spreading the discontent.

2. Do the opposite, help spread the disease and make it so common that the push-back from end-users will increase in strength and also infect the producers, so that they will stop designing such crap.

As you can imagine now, I and a few other folks here in Prague have been working hard on the second solution for the last few years. Why working hard? Because here we are basically starting from zero.

When we were planning to expand our local UX team about six years ago, we ended up with two possible sources of new employees. One was recommendations—someone knew someone who would be a good designer. The other was graduates; because we had a cooperation agreement with the local university, we were able to pick talented students. But in both cases, these new hires started more or less from scratch. It took at least one year of training and mentoring before they became more productive. When we contacted local recruiting agencies, they didn’t have a clue who or what we were looking for.

Even now, the situation is far from ideal. Just to give you an idea—as recently as October 2009, when we presented very basic topics from our field, such as usability testing, at WebExpo (the biggest local conference focused on web development, technologies, and design), the information was a complete surprise for the majority of people in the audience! Web design is a “local term” referring to visual design or search engine optimization. Web agencies are mainly experts in PHP, MySQL, or Google Analytics. But hardly any of them have recognized that it might be useful to talk to users from the target audience, to run interviews, focus groups or conduct usability testing. To some extent, this is a chicken and egg problem. Partly, local companies are not willing to pay for UX services or to employ UX experts because they don’t see their value, or perhaps they’ve never even heard of UX, and even if there were a demand for UX services at this point, it would be extremely difficult to get someone local to do the job.

Back to our topic now. As I mentioned before, we had a cooperation with the largest local technical university, the Czech Technical University in Prague (CTUP). In 2003, I was looking for other local UX professionals. Because I couldn’t find any, I got in touch with the local university I had graduated from, since they were teaching at least some basic UX-related courses. At the same time, we had a space problem in the old Sun Microsystems building—there were no facilities to conduct usability studies. I conceived the idea of establishing a usability lab on the university campus. Thanks to Sun, we were able to build the first usability lab in the Czech Republic in 2004 (which, by the way, was opened by the Czech IT minister) that delivers usability testing know-how to anyone who’s interested. Soon, the university started to use the lab for their teaching and made UX part of the curriculum. Today, lab utilization is close to 100% and we also run joint Sun – CTUP projects, focused on usability testing, prototyping, or simple web design. We’ve finally reached the point where the established UX department that was started in September 2008 has come round full circle to user experience and computer graphics.

It was in 2005 that I first heard of the World Usability Day—it’s similar to No Smoking Day, but it’s directed against anything unusable. When we received the buy-in from our management, our Sun UX team and CTUP jointly organized a local event. We rented a small local theatre with about 70 seats and prepared a program of introductory talks on usability. The speakers were from Sun and from the university. The entrance was free. We were very pleasantly surprised by the attention we got—the event was “sold out” in a few days. Motivated by this success, we decided to start actively promoting the field through a local chapter of the Special Interest Group in Computer Human Interaction (SIGCHI). The local chapter of ACM (Association for Computing Machinery) SIGCHI, the largest professional association in the world in our field, was established in 1998. Until 2006, it was mainly focused on the organization of specialized professional events and lectures. After the success of Prague World Usability Day 2005[1], we began to organize local SIGCHI meetings for the interested public. The first meeting was held on March 23, 2006. Since then, there have been many meetings with speakers from companies such as Sun Microsystems, Adobe, Microsoft, IBM and Google, and individuals such as Aaron Marcus, another doyen from our field. The next milestone was establishing the non-profit organization “Občanského sdružení Prague Association for Computing Machinery Special Interest Group on Computer-Human Interaction” or Prague ACM SIGCHI[2], on January 8, 2008. At present I’m in charge of this chapter.

So are we making good progress? I think so. The last Prague World Usability Day (which now takes place every year) saw more than 250 visitors. As already mentioned, the university has established a department dedicated to our field, the number of SIGCHI members is still growing, and we are being invited more and more often to give a speech about UX at local conferences. Also, in our company, we have reached the point where we have become a truly international team, based in Prague but cooperating with colleagues in the U.S., who are also managed by me. Still, we realize that we have a long way to go.

Join the Mission?

Let’s summarize the lessons learned. What can you do if you find yourself in a similar situation and would like to spread the virus and become a UX rebel in your country?

1. Connect with a local university. Focus on the new generation.

2. Evangelize, evangelize, evangelize—anytime, anywhere.

3. Establish a platform where people can meet. This could be a virtual community, social networking or it could just be regular real-life meetings in a pub. The main point is to meet like minds, and to get to know, support and learn from each other. Get connected, you’re welcome to hook up with us, we’ll be pleased to support you.

I have no idea where all this is going to end. But you, dear reader, have no choice, if you’ve been infected by UX. You’ve been warned. What you can do to save your soul? Spread the word, proselytize people around you.

About the Author

Jiri Mzourek works at Sun Microsystems as the Senior Manager of User Experience. He is responsible for an international team focused mainly on developer products. He built the local Sun user experience team from scratch.

He evangelizes UX in the Czech Republic: Jiri initiated and managed the creation of the first local usability lab and he coordinates the cooperation between Czech Technical University in Prague and Sun Microsystems to produce the local World Usability Day conference. He is also in charge of a local ACM SIGCHI chapter.

Web: www.mzourek.org

Twitter: mzourek

Linkedin: http://cz.linkedin.com/in/jirimzourek

[1]. Prague World Usability Day: http://www.wud.cz

[2]. Prague ACM SIGCHI: http://www.sigchi.cz

What I Know and Don’t Know

Digital stories have nothing to do with technology. Computer and virtual worlds are nothing if not deeply human; that is probably why I enjoy working in UX (User Experience) design. It is all about people, their mindsets and behaviours, which mean there is always an element of surprise—there is always something new to learn, something you do not know.

When Digital Was Called Multimedia

In 1994, I was working at a publishing house in the illustrated books department. As a publishing manager my role was to conceive books, propose them to the publishing committee and, if they were accepted, take care of the editorial work and production. My main topic was nature. The CD-ROM was just emerging and I was very interested in this new medium. I took my first steps in the digital world when I conceived my first project—a nature CD-ROM and although it was not accepted by the committee I think in retrospect that was a good thing.

At that time, digital was called multimedia. MILIA was the big event in this brand new field. This international fair took place in Cannes, France. I was there in January 1995 when people were wondering which format would win the market battle, CD-ROM or CD-I although you could still count the existing titles on the fingers of two hands—the market was essentially all potential. Walking through the alleys there, we were surrounded by stands mainly occupied by publishers, the ones who, we thought, would be the first to create and publish digital products. We didn’t realise that just as it wasn’t auto body manufacturers who invented or produced automobiles, nor would traditional publishers be the pioneers of digital publishing.

I met people there who were involved in multimedia and several months later, after I became a freelancer, they asked me to work on a CD-ROM (my first one). I was in charge of formalising the storyboard from a text written by an expert. The subject was Picasso’s life and work. His son, Claude, used to come and visit us on a regular basis, both to validate the work and also help to address issues we were facing—like finding the right person from whom to procure a good slide of a painting. In terms of content, the product was really neat. However, the scenario was a strange combination of brochure and TV-show, two models we were familiar with. The main paradigm was the page, and we added animated transitions in-between pages.

At that time, we didn’t know the design patterns we could have fallen back on. Indeed we were ignorant of the very concept of ‘design patterns’. It was a period when the Pompidou Centre was hosting many conferences on multimedia. Bob (Robert) Stein had just founded The Voyager Company, a CD-ROM publishing house, and had set up an office in Paris. He was a regular speaker at these meetings, along with others whose names I have forgotten. All of them were questioning the new media and the way the user handled it. How could we make the user understand dimensions, sizes of objects? How to make them understand where they were and where to go next, or even how to go back? Back then, we were not thinking about user centred design, but we were obviously facing questions: how to present the content and allow people to browse through it. Some creators were influenced by books systems, others by software. I remember one guy who created a CD-ROM as an interactive movie: the user didn’t have a back button but an “Undo”. If they wanted to go ahead they had to use a “Do” button.

In one of the projects presented, the screen hosted a menu shaped as a flat map: each section was represented by a room. The main menu was shaped like an architectural plan and the room was highlighted to show where the user was.

Everyone in charge of conceiving CD-ROMs had difficulty with navigation. How to communicate to the user as to how to access the content? Should we use numbers as in books? We also tried to create some immersive experiences.

Although it might sound weird now, at the time we felt we were inventing something new; and somehow we had, or at least the medium allowed us to create something we had never seen before. I remember a CD-ROM dedicated to Mozart’s Quartet in C Major K465 (Dissonance), which made you understand the music in an incredible way. You could play a piece of music as many times as you wanted and see on the screen the corresponding music score. You could also, if you wanted, have an expert’s explanation or answer a music quiz game at the end to test your musical ear. Manipulating different media such as sounds, images and games was completely new.

Dynamic Brochure-like Internet

When I began working for web projects in 2000, I somehow believed it would not be too different from my former job at a publishing house as a CD-ROM scriptwriter. How wrong could I have been?

After years as a freelancer I was an employee again. I had been hired by a multimedia agency to work on content-heavy websites for museums and festivals. If some pages were created statically, using Dreamweaver, most of the content (exhibitions, shows, conferences and so on) had to be updated through an interface a non-technician could handle. At the beginning, it was simply some sort of native phpMyAdmin. You could add, modify or delete text in a table, but you couldn’t upload pictures. You had to do it through ftp and type the name of the file in the table afterwards.

The second versions were ordered very shortly after the first ones and the developers began to create CMS better adapted to the size of the content, which was growing rapidly. We spent a lot of time with the client, imagining and discussing how things should work on the front-end (sitemap, templates, navigation and menu), but they never asked anything about the back-end, nor did we. The developers created it all on their own, sometimes taking decisions based not on the comfort of the user, but on their convenience. Little by little, problems became obvious: the back-end performance was not user-friendly and the way the system worked was not intuitive at all. We had to spend time creating documentation and we had to organise training sessions and produce documents that people could rely upon. When I had to add content to the website myself, I experienced how painful it could sometimes be.

In 2004, I began teaching website conception at the Sorbonne. The good thing about teaching is that it makes you re-visit your own practices and go back one step in order to see the big picture.

Now I realised I was beginning to face some strange requests from clients regarding user behaviour, needs and expectations. Most strikingly were reports of comments such as, “How do I go back?” or “My grand-mother wouldn’t like this.”

Developers who were working with me told me about the user-centric approach: it was the answer to questions I had faced for years without satisfactory responses. I understood that the user was the key and began diving deeper into the user-centred design world via the web.

Discovering User-Centered Design

I bought some books and began devouring them: The Polar Bear and Ambient Findability, The Design of Everyday Things, The Elements of User Experience, Don’t Make Me Think, Designing Web Navigation and so many more. I read Nielsen’s blog and stories on Boxes and Arrows. I spent time setting my Netvibes page to make sure I received all the possible RSS news more or less related to IA (Information Architecture).

I was discovering a brand new world; there were people around who wanted to design websites to help people find what they were looking for. I took inspiration from the way they thought, the way they worked. I began to adopt the same methodology. Each time I faced some problem while conceiving a website, I used some method borrowed from information architecture. I organised card-sorting sessions and I tested labels to be sure they were self-explanatory.

I remember an incredible card-sorting session for a website’s project aimed at young people. The team was wondering whether categories like school, culture, art and sports would be relevant at the first level of navigation. We learned that in fact young people differentiate chiefly between activities they practice on a regular basis (like sports training every Wednesday) and one-off events they attend (like a concert), not between culture and sports. So we used Activities and Going Out as the first level of navigation. It was a great lesson for me as I was really experiencing the “I am not the user” adage. Even if I could have pretended to be a kid and tried to think as one, it would not have worked as I was a grown-up. It demonstrated that discovering the user’s mental model can be a real journey.

At that time, I also subscribed to the discussion lists of the Information Architecture Institute and the Interaction Design Association. I remember one of the first mails I received being from Peter Morville, he invited everyone to somewhere in Australia where he was attending a summit. It was astonishing to have this in MY inbox, suddenly I was part of it. I read with great attention all the mails from the lists. One day, I answered a question myself for the first time and once in a while repeated it afterwards. It was then that I realised I really wanted to be full-time information architect and get rid of some production-related tasks that I didn’t like anymore.

While I was introducing more and more of the UCD approach into my work, I was also wondering whether my practice was really appropriate or not; since I was a self-educated information architect I was not sure I was completely legitimate. I really had to be sure of my thought process and I couldn’t get this certainty alone.

I decided I had to observe and learn from other professionals. I looked for work experience opportunities and sent applications to some prestigious companies. In Europe the BBC had probably the best reputation, mainly because of Margaret Hanley who built the team there. I applied to the BBC work experience programme and had the incredible luck to be accepted and I spent two weeks working with and learning from Karen Loasby, my own special “guru”.

Springtime in London

In France, there are plenty of jokes about how much it rains in London, despite the fact that the weather’s not much different in Paris. However, I cannot think back to June 2007 without remembering the rain. At that time of year, I thought I would enjoy visiting floral parks and gardens, but actually, during the couple weeks I worked at the BBC it rained virtually all day every day. Not the ideal weather for enjoying British gardens!

Karen Loasby welcomed me to the BBC, in fact she was the first information architect I had ever met. I worked on several projects under her direction and she introduced me to the many IAs who were working for the mobile site or for interactive TV. I attended conferences and presentations, saw many projects at different stages, first steps in PowerPoint, wireframes in Illustrator, prototypes for usability testing. Everything I saw was fascinating; I was like a kid opening Christmas presents.

I really loved the time I spent there. The work of IAs who were smart, subtle and impactful showed me the way forward. The work experience, whilst humbling, gave me confidence in my IA skills and all the self-education I had acquired. I realised that all my reading had been very useful and I used it for research projects. My previous experience also proved perfectly relevant.

I gained the certainty that I definitively wanted to work in this new field. Once I got back to Paris I met different people including some from Duke Razorfish and very shortly afterwards I was hired as an information architect.

Pioneer IA

When I arrived at Duke Razorfish, I was the first information architect in the agency. Duke had recently been bought by Razorfish and Duke’s managers had been to the United States to meet Razorfish’s people. They had discovered information architecture at this occasion and decided to introduce the discipline to the agency.

This meant that, in 2007, nobody at Duke knew what my job was and most people misinterpreted my role. None of the books I had previously read on IA prepared me for this environment. During the first year, I learned how to change my colleagues’ mindsets as well as adapt my practices to better fit their expectations. I organised many different presentations, some for the whole staff and some for specific groups such as account managers or project managers.

In the projects I was involved in I concentrated my efforts on the users and collected everything I could about their needs and expectations (primary or secondary research, depending on the available documents). I was the only one doing this and thus brought something really new to the teams. I also worked on content, creating content inventories.

I tried to focus also on the specific problems that only an information architect can address, i.e. those related to users, journeys and information findability. Once, I made a recommendation, with the help of a web analyst, to improve the search engine on one of our clients’ websites. I proposed a thesaurus and some change in the parameters. All of this (the approach, the collaboration, the way of solving problems) was completely new for the team, even though some of them had been working on the web for years.

I explained the user-centred approach again and again and I organized several formal presentations. I also asked to change the company’s methodology to take information architecture into account. I took every possible opportunity (small meetings, face-to-face discussion) to give information in a less formal way.

For my part, I also adapted my practice to the company, changing some deliverables to better fit existing habits, those of the agency and those of the clients as well. I proposed to re-think how teams co-operated and was quite proud of some results we achieved. I demonstrated that IA doesn’t equal boring portal websites, but can add value in immersive projects, created in Flash, with video content and innovating navigation systems.

I had the chance to work with the new business team on pitches for new clients. This offered me the opportunity to propose a UCD methodology from scratch. We won some of these clients and I thus had some very challenging projects I could work on from the very beginning.

The main lesson I learnt from this experience is to always keep an open mind. It isn’t worth fighting with your colleagues, it is far more efficient to listen to them and change things to better meet their needs.

European Community and Ambassador

Since my subscription to the IA Institute and my work at the BBC, I had always wanted to attend an international IA event in order to meet new people and to exchange and share ideas with other IAs. I wanted to attend the EuroIA summit in 2007, but I couldn’t afford to go to Barcelona, so in 2008, I was determined to attend the 4th summit in Amsterdam. I asked Duke to send me there and I convinced another information architect from Ogilvy Paris to attend as well. I didn’t know it at the time, but we were the only French people at the event.

I arrived in town late in the evening the day before and, on the morning, walked 15 minutes to reach the theatre where the summit was taking place. It was a sunny morning and while I was walking along the canal, I was wondering what I would find there. It was my first visit to the Netherlands and the streets looked exactly as I had imagined them.

My hope was merely to learn something from intelligent, talented professionals, but the reality far outstripped my expectations. People there were really open-minded and willing to talk to people they had never met before. The best times were probably those spent in the hall, in the corridor, during the breaks, lunch times and evenings, having drinks and dinner together. I met some brilliant, community-minded people, all willing to create a strong and efficient network in Europe.

After two days in Amsterdam, I felt proud to belong to such a community, it was as if I had acquired a whole new group of friends. Eric Reiss asked me to be the national ambassador of the EuroIA conference, and I was surprised, honoured and delighted to accept. I returned to France filled with an almost evangelical zeal for creating a more active local group.

I organised my first UX meeting in Paris at the beginning of the following December.

From IA to UX

As I worked on various projects at Duke Razorfish, I kept looking for information about my job through discussion lists, blogs and web magazines. I heard about service design thanks to Sylvain Cottong, from Luxembourg, who came to attend my first UX Paris group meeting.

Once again, I used my autodidactic approach and implemented some of the IDEO techniques, such as shadowing or fly-on-the-wall, to get to know user behaviour better. I exchanged and worked with UX professionals at Razorfish in the United States and learned a lot from their experience.

I have also become very interested in content strategy, which shares a lot with my former job at a publishing house. I also got involved in defining tone of voice. Little by little, my work has become more diverse as well as more global, related to the very premises of websites. In effect, I gradually shifted from IA to UX, which is what I do today.

Looking back, I am most grateful to the people who influenced my career. Even now, whenever I begin a new project, just after the kick-off meeting, I can hear Karen Loasby leaning over my shoulder and asking “What do we know? What don’t we know?” I’ll probably hear these words until the day I retire.

I am also grateful to the many others who have written the great books which are my references, given the conferences that have nourished my work, published their stories online or answered my questions through discussion lists and groups. Belonging to such a helpful and intelligent community means I am always willing to give a little back. Put simply, working to offer users a better experience gives me a sense of great happiness, a sense which only intensifies the more I learn about human beings.

And there’s always more to learn.

About the Author

Sylvie Daumal is an Information Architect at Duke Razorfish in Paris.

She is involved in European-scaled digital projects, takes care of the overall user experience according to a holistic approach and deals with content strategy, user journeys and interactions as well as business issues.

Sylvie also gives UCD courses at CELSA, a graduate School within the University of Paris Sorbonne and at Sciences Po Paris University.

Journey into Information Architecture

I wasn’t born an information architect. I couldn’t even figure out what I was going to do when I grew up.

I thought, somehow, a career would materialize in a dream—that I would wake one morning and say, “I’m going to be a management trainee!” I felt it was only a matter of time before I would don a dark suit, surround myself with facts and figures, and hammer out business decisions that were good for the organization.

But this urge never struck. Instead, I took job inventory tests and wrote descriptions of classes I liked and didn’t like.

My career advisor returned one book-length inventory with the comment, “Excellent inventory, but obviously you don’t know what you are going to do.” By the time I completed college and graduate school, I decided I had failed at the ONE THING I was supposed to get out of my education: I still didn’t know what I wanted to do when I grew up.

Nonetheless, armed with an education and a desire to do … well … something, I packed my 1977 yellow Hornet hatchback and headed for Washington, D.C., where I found a dumping ground for people like me—college graduates who didn’t know what they wanted to do when they grow up.

In the early 1980s, when I moved to D.C., the U.S. government had started contracting professional services to small corporations. Washington quickly became riddled with these “Beltway bandits”—most of them identified by acronyms and initialisms. In 12 years, I worked my way through the alphabet: ETI. CTA. SSI. CCI.

During this time, personal computers moved into the workplace, where they were used primarily to crunch numbers and develop print products. Those of us in government contracting soon used computers to support efforts. It’s a kind of government-speak for providing professional services. Contractors support efforts by completing tasks and submitting deliverables.

I was young, idealistic, and ready to help my companies support efforts! So, in support of EPA Contract 68.01.7030, FEMA Contract EMW-5-C2075, and multiagency Contracts OPM-89-76 and OPM-87-9037, I became absorbed by preparing deliverables—providing reams of paper for federal agencies.

“You know all that work you did for us?” a government contracting officer later asked me. “We had to hire a contractor to come in and tell us what we had.”

What was I doing? I liked my work—using principles of rhetoric I had learned in school. Like Aristotle and many of his followers, I believe information can be crafted differently depending on whom it is for and what they need. I was motivated by my passionate belief that end-users of information matter.

An Information Architect

Spring 1995. A colleague and I share a few words between professional conference sessions. “I don’t get it,” I said. “I’m a writer and rhetorician, but I like presenting the information graphically so others can use it. Maybe I’m a data stylist.”

“Oh, no,” he responded. “You’re an information architect.” That was the first time I ever heard that word.

Information architect. I liked the sound (kinda cool). And I liked the image: I envisioned structure. I was fond of structure. In my job, I enjoyed shaping documents and products so they made sense to others. For fun, I’d spend hours looking at ways visual designers clarified complex data.

“That’s a much better title than data stylist.”

My colleague directed me to the writing of Richard Saul Wurman, who coined the term. Within a week, I had inhaled Wurman’s book Information Anxiety. I found a lot I liked.

Wurman asks us to build understanding businesses—organizations devoted to making information accessible and comprehensible. He challenges us to identify new ways to interpret data and build new models for making it usable and understandable.

He asks us to “re-educate the people who generate information to improve its performance.” That advice mattered to me.

That was me: Information structurer. Builder of products that help people get things done. Educator. (Well, in my heart. I’d begun teaching part-time, but I still spent most of my workday creating deliverables.)

By the time I discovered Information Anxiety, I’d worked for almost 12 years in a three-foot by five-foot cubicle surrounded by federal workers, tasked with supporting efforts.

“How,” I wondered, “could someone with gusto in his soul spend his days surrounded by mauve decor, busily preparing deliverables? How could I work with people who don’t respect understanding but instead do things because they’ve always been done a certain way?” I needed an escape plan.

I sought advice from a former boss. “How do I get out of a mauve cubicle? How do I find something I truly believe in? How can I work in some way that really makes a difference?”

She directed me to a lifework class. “It’s 10 weeks. It’s cheap. You’ll love it.”

Most of us in the class were government contractors. During the first week, we talked about our jobs. During the second week, we took time to dream about what we would be doing if we could do anything—no limitations; only dreaming. In weeks three through eight, we examined our pasts and reviewed our goals.

In week nine, I quit my job.

I hadn’t planned to quit my job, exactly. But I was part of a team dismissed because of a contractual meltdown. My contractor boss offered to find me another role. “Perhaps,” he said in all seriousness, “you could work for Norm.” Would you like that?”

I reflected on what I had learned in lifework class. I was searching for work I loved. I felt in my heart that I wanted to enable others to find their way through information, and I believed in Wurman’s call for information businesses that emphasized supporting others. I also knew I wanted to teach.

So when my boss said, “You can keep a job with us if you want to work for Norm,” I thought, “I wouldn’t love to work for Norm. I have to find work I love—right now.” So I quit, and I officially became a full-time information architect.

Of course, in 1995, there were some difficulties. For example, almost no one knew what an information architect was.

An User’s Advocate

“WHAT HAVE YOU DONE!!!!!”

I screamed at myself soon after leaving my job. (I had been raised in a small town in a protective environment, raised to accept a good job with a good corporation.) Instead, I had quit my job to enter a field that didn’t exist.

So I questioned my decision with shrill, terror-stricken howls. I repeated, “WHAT HAVE YOU DONE!!!!” as I tried to see leaving my job as a positive move into independent consultancy.

“WHAT ARE YOU GOING TO DO????”

I also heard that message in my head, but I decided it must be the voice of my mother, who had often expressed concerns about the work I would do. What would I do? I could still type, and write, and create deliverables. Why, I could even find another job.

“WHAT ARE YOU GOING TO BE????”

That question had pestered me for years. Somewhere along the way I had come to believe that people are their occupations.

You ARE a fireman.

You ARE a lawyer.

Can someone really BE an information architect? I felt I could.

I’ve always been slightly belligerent—the kind of guy who asks “Why?” far beyond the point where it’s considered cute. Whyness has always pervaded my professional self.

“Why is it,” I wondered, “that writers, people with tangible skills, cannot make their value understandable to corporate America? Why is business so content to deliver documents-from-hell to their customers and users? Why don’t users complain? Why do they accept what they are given? Why are they so passive when information has so much possibility?

I left the mauve cubicle just as electronic communication began to change our lives. In my first month on my own, I visited a former colleague. “Let me show you this,” he marveled. “It’s called a home page.”

At that time, I was tempted to become a communication product developer—especially as salaries for product builders were growing—but I couldn’t quite go there. My interest did not lie in developing products. I needed to follow a gut feeling that I should spread a message: Good information structure matters to people. You can structure information so people can find what they want, use it, and appreciate the experience. I became evangelical, and I began to teach more. I became an advocate for improving users’ understanding.

I appreciate the opportunity to work with others who envision clear structure, fight for plain language, and devise ways to help humans. I treasure moments of discovery when a student or client suddenly sees the light. I recall a facilitating session where I worked with a team exploring ways to put content online. I could tell one attendee was becoming frustrated when suddenly he exploded, “Oh, I get it—people don’t want to sift through reams of detail to get to the information they want!”

A Teacher

Last semester I was introducing myself to my class on information architecture and the user experience. Now beginning its 12th year, the class is a place where Washington-area students can gather and explore the field.

“I don’t always call myself an information architect,” I told students at the beginning of class. Several stared at me in surprise.

“As information architects, we explore labels.” I offered. “If the label refers to the specific analyses performed by user-experience professionals, then the label doesn’t fit me.” (I’m no longer in the deliverable business.) “But when the label is used to refer to someone who believes in making the complex clear, then you’ll find I embrace the term passionately.”

I’ve now spent 15 years embracing, questioning, avoiding, and accepting the label “information architect.” Fortunately, I remain passionate about my work. I like teaching people to see—helping folks better understand the implications of information structure, sharing strategies for helping others, and experiencing the inherent possibilities of good information architecture.

It’s the kind of work I always wanted to do when I grew up.

About the Author

Thom Haller, teacher, speaker, writer, and user advocate—teaches principles of performance-based information architecture and usability. Since 1998, Thom has taught classes on architecting usable Web and Intranet sites. As a teacher, Thom enables students to structure information so people can find it, use it, and appreciate the experience. A noted speaker and facilitator, Thom is funny, passionate, and inclusive. He creates change in organizations, infusing his optimism and showing how we can make the complex clear.

For ten years (1998-2008), Thom led the information architecture consultancy, Info.Design, Inc. He also served as Executive Director for the Center for Plain Language.

Web: www.thomhaller.com

Twitter: thomhaller

Building Arcs with Wall-Hung Urinals

I’m no longer quite sure whether it was the summer of ‘99 or 2000, but I still remember exactly that we were sitting in an old pub in Frankfurt. I was just in the final throes of my biology studies, my thesis was almost finished and I had been accepted to do doctoral research in Toronto.

I was virtually on my way over, and my buddies and I had come together to celebrate my departure. A friend gave me a map of Toronto that evening; I still have it, but I never made it to Toronto. Instead, I moved to Berlin and became an information architect.

This is my short story of how I kept falling forward until I stopped, looked back and connected the dots.

Frankfurt With Attitude

In 1999, I was working on my thesis at the renowned Max Planck Institute (MPI) for Biophysics in Frankfurt. I was studying microbiology and genetics and had decided to write my thesis somewhere or other than at the Goethe University—which did seriously offend some of my professors. To them it seemed like the university and its labs wouldn’t be good enough for me. This, of course, was exactly what I was thinking back then.

It was quite an effort to get accepted at the MPI but I simply wanted to work with the best and learn from the best. There is a certain price you have to pay if you cultivate such an attitude. Facing annoyed academics during your oral examination, for example.

Nevertheless, six months later I dumped all of it: great colleagues, interesting studies, and the institute with its famous name.

When I started to work at MPI, I had only a vague idea of the World Wide Web, let alone the Internet. Naturally, all of us already had e-mail and we used search engines such as Yahoo or Northern Light, but the Internet was still nowhere near as omnipresent as it is today.

We had computers to help us with our daily lab work, image processing and research. The junior staff already had computer experience through games such as Monkey Island, Day of the Tentacle or Myst (games that I now have installed on my Nokia.)

For the subject of my thesis, I had chosen a membrane protein called P2X7; I no longer know anything about it. In retrospect, the most important things I learned at that time in a high security laboratory in Frankfurt were how to skim through scientific articles—and Photoshop.

Even nowadays hardly a day goes by without me using Photoshop. It is a good tool to quickly compose images, to visualize a mood, or to sketch ideas. It requires no great effort to become acquainted with the software, and after a little practice, one has achieved a skill level that Alan Cooper[1] calls perpetual intermediate. Not a beginner anymore, but stuck at a skill-level where you only know how to get around, doing the stuff you always do, but you can’t be called an expert, though you probably think your skills rock like hell.

Adobe Photoshop was the first complex program with which I was able to watch myself improving and, as a consequence, realize how my demands on the program changed (something called the coevolution of tasks and artefacts[2]). In his seminal book Usability Engineering Jakob Nielsen writes “Users will not stay the same. Using the system changes the users, and as they change they will use the system in new ways.” Years later, I learned that usable software should accompany a user’s progress, enabling one to work efficiently at any level of proficiency[3]. Efficiency and effectiveness are important attributes of usability.

Anyway, one day I handed in my thesis and all my studies were done. I felt unexpectedly free. All at once, the path I had planned seemed to be just one of many options, with alternatives as yet unknown. The good thing is, if you don’t know where you are going, any road will get you there. Or was this part of the problem? After all the time at university, after all the years of education during which one learns to follow well-trodden paths and supply spoon-fed answers, I suddenly had the freedom to ask questions.

Well, if everything is open to challenge, it is best to start with yourself. Was I really going to become a biologist? Me? Seriously? Having left my lab with its clean rooms and sterile atmosphere I began breathing the dirty city air again.

The problem was I’ve been touting about leaving Frankfurt for quite a while. There was no way I could pull out now and simply stay where I was—in my flat, near my gym and close friends. With Toronto I did herald a phat destination though. Now I had to come up with something similar. It felt impossible to settle with less. Bloody attitude.

I began looking for a new city. Where do you start with a task like this? Well, I did start with “A”. Atlanta, Austin, Amsterdam ... Amsterdam! Definitely a great city. What else was there? Barcelona, Berlin ... Berlin! Hey, I even happened to speak the language. That was it. I decided to move to Berlin and become ... err, well ... someone.

Flash

At school, I was editor in chief of the school magazine, drew comics and wrote short stories. When I mentioned to a school friend in Frankfurt that I had ended my career as a biologist, but didn’t yet know what to do instead, he reminded me of my “creative schooldays” and suggested I’d learn Macromedia Flash[4]. He himself had just dropped out of medical school to work as a Flash developer—instead of becoming a successful surgeon, like his father and grandfather. (Actually, this led to his parents kicking him out of home, which led to his girlfriend leaving him, which led to a serious drinking problem, which led to some more very bad habits. But in the end, he got everything sorted out and became a successful Flash and PHP developer.)

His deductive logic did sound pretty sensible to me. I installed a 30-day trial of Flash 4 and began to familiarize myself with this animation software. A month later we were having a barbecue at some friend’s backyard and I was practicing my new role as Flash “expert”. We had cider and sausages. The latter was hanging out my mouth when I officially proclaimed I was going to Berlin to work as a Flash developer. My friends were surprised, to say the least. Since the banger didn’t enhance my pronunciation they assured themselves: “sorry, did you say Fresh or Flesh?”

It was just 10 years after Berlin had become the new capital of a reunited Germany. Heretofore, I had never been to Berlin myself. In a faraway place called Silicon Valley, a bubble was bursting, and here in Frankfurt some drunken biologists were making fun of me.

It was definitely time to move on.

Berlin

One morning, I threw my things in a rental car and drove off. I put my Sinatra tape in and cranked up the audio. Start spreadin’ the news, I’m leaving today. Why Berlin, again? Well, it’s the capital. I figured If I can make it there, I’ll make it anywhere.

Luck favours the prepared mind, said Louis Pasteur and I am also very reluctant to turn up somewhere unprepared. Prior to my departure from Frankfurt, I had specifically approached a few people from Berlin in an online forum, so as not to be completely alone in the city. I had applied for various jobs and had bought two new books about Flash.

Barely a week in Berlin, I got an internship as a Flash developer in a small up-and-coming agency. As the payment for a position like this is generally not very high, I also worked on weekends, doing night shifts in a nursing home. During the day, I animated digital stories, and at night, I listened to stories told by old people. It was actually a pleasant combination. The elderly are often outstanding storytellers.

A few months later, I was a full-time Flash designer and had left my nursing home job and all those sweet grannies behind. Well, that’s how it is when you’re on a journey. You face new people and turn away from old friends.

At that time, Flash was only found on websites, somehow embedded in HTML. I learned HTML in order to do a better job. At some point, I realized that HTML was very closely associated with something called CSS, and that it would look bad if I had no idea about it. So I learned CSS as well. Meanwhile, Flash really started gaining ground, and its strange proprietary programming language was replaced by JavaScript. So I learned JavaScript, too.

What is it they say? It’s not rocket science. These are all languages and programs that are not incredibly difficult to understand. Hey, even an ex-biologist can learn them. Seriously: how hard can that be? It’s just one step after another, and sooner or later, you look back and think, “Wow, did I get this far already?”

Usability

I had now been at the agency for three years. We had grown from 20 to 120 employees and I had become a front-end developer and no longer merely their Flash monkey. Don’t get me wrong. I did love my job. I was part of the Berlin Flash developer community. I had great colleagues and a good boss—and there was always something new to learn: where HTML and JavaScript are concerned, accessibility is not far away, especially when creating web pages for government bodies like we did back then.

I got to know the subject and began to advise clients on accessibility. It is only at a stone’s throw from accessibility to usability—and even back then everyone thought usability was just great. At least in theory. Although we didn’t exactly know what it meant in the context of web-design, everyone thought highly of it—even the clients. Oh yes. And all those websites—how much better they sold when they came with build-in usability.

I started to get my head around the topic and read everything I could find about it on the Web. The good thing about usability is that there are guidelines to which one can refer to. By guidelines, I mean international industry standards—we’re talking big guns here. I don’t mean a top ten list that some blogger has hacked together to fulfil his weekly link baiting quota. No, I’m talking about long texts with titles such as: “Human-centred design processes for interactive systems” (ISO 13407), “Ergonomics of human-system interaction—Part 110: Dialogue principles” (ISO 9241-110) or “Ergonomics of human-system interaction—Part 151: Guidance on World Wide Web user interfaces” (ISO 9241-151).

These documents are absolutely worth reading, but they’re as dry as they sound. I went to borrow them from a library.

A young librarian pointed to an old computer. “You’ll find everything you are looking for in there,” she said.

I sat down in front of an awful monitor and stared helplessly at the complicated user interface of the software. After ten minutes of unsuccessful clicking around, I stood up resignedly and walked back to the information desk.

“Could you help me, please? I don’t know what to do; I’d like to borrow some usability standards, but I can’t use the program to find those standards ...”

“Oh. I’m afraid I can’t help you.” She shrugged her shoulders with indifference. “I don’t know how it works, either. Try reading the manual.”

So I went back to the workstation and read the yellowed manual. At one of the tables nearby, an old Turkish man sat reading a thick book. The title on the cover said “HTML 4” in big, bold letters. I watched him for a few minutes, intrigued. Then I reminded myself why I was here, and turned to the manual.

Reading the manual really did help (who would have guessed?). I clicked my way through the complex web of queries, alerts and meaningless icons, and indeed, I was soon done.

“Finished already? Did you get it to work?” asked the librarian in disbelief.

“Yes,” I said and smiled. “It worked like a charm.”

I looked at her encouragingly and waited for a moment—was there perhaps something she wanted to ask? But she had already returned to the magazine she was reading. Consequently, I left and took my knowledge with me.

One of the ISO standards I was looking for was the aforementioned 13407. In the evening, I was lying in bed, leafing through the pages, when suddenly I looked at illustrations of urinals. “Those usability standards are even stranger than I thought,” I said to myself and leafed forward. There were urinals everywhere. Almost on every page! “Wow, this author must be really obsessed with those urinals,” I thought.

I realized my girlfriend was looking over my shoulder to see what I was reading when she asked: „Are we getting a new bathroom, honey?”.

I flipped the document and looked closely at the cover. I had wanted a copy of the ISO 13407 standard “Human-centred design processes for interactive systems”, but instead, I had taken home the industry standard “Wall-hung urinals—Functional requirements and test methods” (German version EN 13407).

Wow, that was a surprise! Sure, there is a certain human-centred aspect around urinals and they probably can even count as interactive systems, but somehow I couldn’t help but think I had taken the wrong document home.

I looked at my girlfriend. “The urinal business is a tough one, but the wall-hung ones do sell pretty well.” She looked at me in disbelieve.

“I bet we could make a living selling those to tourists visiting Berlin. They could have images of places of interest printed on top of them,” I suggested.

She stared at me. “This is definitely the worst idea you had—this week. This will never work. You will lose everything and we will have to live on the street and eat junk like rats. Is that your plan, darling?”

“Aren’t you a little bit too pessimistic?” I asked and tried to score by citing Clint Eastwood: “If you think it’s going to rain, it will!”

She shrugged her shoulders “Predicting rain doesn’t count, building arcs does.”[5] She turned around, signalling the end of the discussion.

I remember staying up that night for quite some time. How could there be two completely different standards with the same number? Slowly I began reading. Hey, did you know that Europe has basically three types of wall-hung urinals, and that they must be able to bear a load of one kilonewton for one hour?

Information Architecture

On the lookout for conferences, I stumbled across TED and Richard Saul Wurman. I was fascinated. In the evening I told my girlfriend about it. She said, “Wurman? Wait a minute, I’ve got something for you.” She went into the study of our small apartment and came back with Richard Saul Wurman’s book, Information Anxiety 2. “Everywhere I go, this girl is already there” I thought to myself. But I didn’t say anything.

Richard Saul Wurman: here was someone who was devoted to making complex things simple. Someone who said “The only way to communicate is to understand what it is like not to understand.” I was intrigued.

I wanted to learn more about information architecture. I bought the “polar bear” book by Lou Rosenfeld and Peter Morville. I read About Face, by Alan Cooper and books with amusing titles, such as Don’t Make Me Think, Women, Fire and Dangerous Things and The Inmates are Running the Asylum. In Eric Reiss’ book[6], I read about information scent for the first time, and Erik Jonsson’s book explained why people lose their way[7]. This was not dry reading. No, this was amazing stuff and I wanted more of it.

In the end of 2004, I began once more to study: library and information science. My friends shook their heads again. Why would a front-end developer care about dusty books? By that time, however, I had lost interest in front-end development. No, interest is the wrong word; I had lost my enthusiasm.

I began preaching the “Do IT with an Information Architect”[8] gospel in our office. But you know it’s pretty hard to get rid of a label. In our company I was the front-end guy. It’s impossible to change roles without a top-down by-in. A JavaScript developer who can do Flash and CSS and even knows about accessibility is worth its weight in gold. I did understand the business side of things. But fact was, my focus had changed and first signs appeared on the horizon that there would not be a vacancy for an information architect anytime soon. Not in that company at least. I was looking for IA jobs but I didn’t get many. So I looked elsewhere. There is always something to do for an information architect—especially in the open source community or at communities such as the Information Architecture Institute[9].

Seth Godin writes in his book Tribes: “It turns out that the people who like their job the most, are also the ones who are doing the best work. Making the greatest impact and changing the most”.

In 2006, I completed my studies and received a Master of Arts in Library and Information Science. “Another pointless degree!” my friends laughed. Who knows, maybe they had a point. But I believe a degree is only pointless if you genuinely consider it to be the end of everything rather than the beginning of something.

“My next project will be whatever occurs to me” said Richard Saul Wurman in an interview, and went on, “Anything you do should come from your age, your ignorance, your curiosity. Think differently at different ages. “

Ignorant and curious? That’s me, or as the actor and comedian Steven Wright once said: “Curiosity killed the cat, but for a while I was a suspect.”

Though I’ve always preferred the journey to the destination, I’ve always been quite reluctant to travel unprepared. “Invest in preparedness, not in prediction”, advises author Nassim Nicholas Taleb[10] and that’s what I did.

Learning about genetics and organic information processing, learning Flash and HTML and CSS and JavaScript, having done accessibility consulting and building websites adherent to usability standards and having studied library and information science, I finally felt ready to work full-time as an information architect. The more I had learned, the more I realized what I didn’t know. I understood what it is like not to understand.

In 2007 I felt my time had come. Again. It was time to move on. I wanted to help build our German IA and UX community. I wanted to meet and connect with new people and learn from them as much as I could. It was time to ram some piers into the ground and start building arcs.

About the Author

Born in Prague, Jan Jursa has grown up in Germany and lives now in Berlin. He works as an Information Architect for T-Systems Multimedia Solutions, one of the leading companies for web-based solutions in Germany.

Jan is a co-organizer of the German IA Conference (http://iakonferenz.org) and Country Ambassador for the EuroIA Summit (http://www.euroia.org). He is also the co-organizer of the Berlin IA Cocktail Hour and the first European IA BarCamp called InfoCamp Berlin 2008.

Web: http://about.me/jan.jursa

Twitter: IATV

[1]. The Inmates Are Running the Asylum by Alan Cooper

[2]. Carroll and Rosson, 1991, Deliberated evolution: Stalking the View Matcher in design space. Human-Computer Interaction 6)

[3]. In Design is the Problem, Nathan Shedroff puts it as follows: “Superior systems should allow both novices and experts to work at their different paces, providing tools for each to work at their level of proficiency.”

[4]. Back then Flash was still owned by Macromedia. It’s Adobe Flash nowadays.

[5]. “I violated the Noah rule: Predicting rain doesn’t count; building arks does.“ (Warren Buffet)

[6]. Practical Information Architecture by Eric Reiss

[7]. Inner Navigation by Erik Jonsson

[8]. See my DIWAIA Blog: http://diwaia.blogspot.com

[9]. The Information Architecture Institute (IAI) is a global organization that supports individuals and organizations specializing in the design and construction of shared information environments. (http://iainstitute.org/en/about/our_mission.php)

[10]. The Black Swan by Nassim Nicholas Taleb

From Consultancy to Teaching

I had been invited to teach User Centred Design (UCD) at a university. Being a 32-year-old User Experience (UX) consultant with a work experience of ten years, should be a great background for transmitting my know-how to 19-year-old Design students. Suddenly, I realized that most of my knowledge in the field has come from non-university methods: jobs, blogs, Internet references, books, etc.; all not very scientific stuff for teaching at the university. So I started to research what was taught in other places about UCD and found that very little was done at universities. (Or public information was very difficult to find.) Then I turned to the places where I had learned and noticed that this discipline (I still don’t consider it a ‘science’) is mostly done by non-scientific professionals of design, librarianship, engineering and hundreds of other different backgrounds and profiles that had all given their “two cents worth” based on their experience. So here are my “two cents worth” based on my experience, what I learned and what I teach on my courses.

Courses and More Courses

I grew up in Alcalá de Henares; a little city close to Madrid, Spain, so when I started the Journalism Degree in Madrid, I couldn’t believe there were so many people in the class that it was difficult to even find a seat. Besides, the syllabuses were so antiquated that teachers merely repeated their old, moth-eaten notes. My marks were not very good that time, probably because I spent most of the classes in the computer room, a place where you could try that new thing called ‘the Internet’. It was 1996: I forgave the bandwidth (you could try a search at Altavista, read a book page, and were still waiting for the results), and the limited amount and diversity of content available. So, while my teachers were insisting on some stupid stuff about Gutenberg, I was discovering the real communication revolution on my own.

So here is the first thing I want to teach: critical self-reflection. Think by yourself; do not let others decide what is interesting, even if they are university professors.

As time went by, I saw clearly that my future was not going to be as a journalist, but as an Internet-things-maker. I now cannot remember how I did it, but I got a scholarship at a prestigious design institute. I had previously taken some courses in Photoshop and Freehand at the college, but this part-time, demanding Design Master taught me how multidisciplinary a designer should be: programming, networks, sound and so forth, although I did not see myself becoming a specialist in any of them. When you have to manage a group of people it is critical to know a little bit about your co-workers tasks. Therefore the second message for my students is: learn the basics of related disciplines, as you will find it easier to bear them in mind when you work in a group.

Despite my disappointment with that old-fashioned Journalism Degree, I finished it and some years later I started taking e-learning doctoral courses in Multimedia Engineering. This was my first contact with e-learning. The first thing I learnt is that it is pretty easy to give up when you learn through the Internet, especially if you don’t get the appropriate support. The lack of communication with teachers and other students is not a barrier, it is the Chinese wall. Suitable content and self-determination will lead me to read my PhD thesis hopefully in 2011, which is eight years on from the beginning. The third competence I would like my students to develop is: Perseverance, if the goal deserves it.

I could go on about my courses for much longer, but I will close this section with my second master, also through a scholarship. This time I was offered a Master in Ergonomics. Classes ran for a year, Friday evenings and Saturday all day. Actually, it was not a real Master in Ergonomics, but in Workplace Risks Prevention, with three specializations: Ergonomics, Security and Health. Since in Spain there is no university degree for Ergonomics, this was the closest way to study it with an official certificate. I finally got the Ergonomics and Security diplomas, and ruled out Health because I didn’t like at all the chemistry lessons, nor did I want to work in that field. Indeed, I didn’t want to be a Risk Prevention Specialist either, I just wanted to learn about Ergonomics to know how to design better products. Despite this great effort of learning many rules, I learned very little about what I wanted, namely, why these rules were like they were. Maybe I should have tried to look for that knowledge abroad, but I preferred to waste one year on this course just because it was held nearby. So my fourth piece of advice is: Grab the knowledge wherever it is.

Jobs and More Jobs

As you will have noticed by now, I am a restless person and this shows in my life as well. As far as I can remember, I always worked in two or three places at the same time. In fact, I got once rejected for that reason, because they did not believe that I had been able to do all the things I had written in my resume. In order not to bore you, I will select the most relevant jobs and group them into three categories: product selling, design and 100% UX.

Product Selling

My first job opportunity was at a hardware and software trade fair, specifically at a stand for video-games. I taught the users how to play. There were some islands with different games, and I was in charge of the island with a racing-cars game and a graphic adventure one. I was still at the university and did not know much about the multimedia market. They gave us a half-day training on their products. The company was at the top of the market, so people came to the stand very quickly. The favourite was the racing-cars island and I had to control how long people played the game and not to show them how it worked. They learned it instantly. On the other hand, nobody in the seven days showed any interest in the graphic adventure game. The company recognised this issue and they never launched it. Which was a pity, as I tried it for testing and it looked really nice: fine graphics, good story and so on. On the other hand, the car game had the poorest graphics, but better acceptance. I learned that sacrificing a quality product in order to promote the profitable one is daily bread.

During the summer holidays I worked in several places to get some cash for travelling. One of the jobs I will never forget is as tele-operator for different companies. My first call centre experience was in a big telecommunication company, receiving orders and complaints, as well as jokes. The week after I joined, the company launched the first Internet flat rate in Spain, and calls skyrocketed. I was lucky to have received a one-week training, because during that week many, many new colleagues joined, getting only a 3-hour course. The intranet we managed was really difficult to use, and I did not want to be in their shoes, and, even worse, in the customers’ shoes. Besides, we were encouraged to spend as little time as possible on each call. Therefore, the service quality drastically dropped. At first, calls were 85% orders and 15% complaints. Then, 50% orders, 50% complaints. Finally, 40% orders and 60% complaints about the bad service, many of them people who had not been told the complete information on the product—just because the company considered it a waste of time. I learned that quality involves time, which entails time to listen and talk to the customer, and time to train the staff.

Design

I finished at the university on June 15, 2001 and started to work just seven days later. Flash 5 was on vogue, and an e-learning company needed many graphic designers to develop their courses. I was taught Flash 4 in my Multimedia Master, so I passed the entrance exam easily. But then, when faced with the white screen, I found out that I had no idea about graphic design. I could use the tools easily, but my sense and sensibility for art was missing. Fortunately, I was a stagier and at the beginning, copy-and-paste was my first duty. During the 13 months I was there, I received several courses on learnability and simplicity in design; I accumulated tasks and gained experience in design from the beginning to the final product. I was supposed to be a Flash designer, but I also was doing Information Architecture, a concept I had previously not even heard of.

It was a really nice job but the Internet crash made the company teeter, many co-workers were fired, and everybody started to abandon the ship. Six months after I left, the company shut down. It was a pity. Bandwidth in Spain was not ready at that time for the challenges of e-learning. Besides, e-learning was still taking small inroads into companies, but I learned that art was not the most important thing in graphic design, but communication. Good for me, as I still have problems identifying the best colour-matches, but not to identify what my users need.

I joined a website-making company. When I say “website-maker”, that was my job, because it was just the boss and I, no one else. He contacted the customers and obtained the projects, and I developed them. “The webmaster”, was how I was introduced. I learned all the tasks in the process, and found out that planning the websites was really more interesting than fighting against PERL. But the best thing about this company was the very different kinds of projects we did: newspapers, marketplaces, intranets, extranets, public websites, and so forth. I focused on usability issues of small websites, and realized that I really wanted to work in that field. I was OK at my job, but if I wanted to get deeper in UX, change was a must.

So my real UX experience starts here.

100% UX

Maybe this sounds familiar to you: a big company buys an expensive intranet. One year later, they realize it is not being used by anyone in the company. Someone has to justify the expense, so a group of people gets hired to enhance the software. Two years after that decision, the intranet has become an essential part of the company. I was part of that group. I was hired to do graphic design stuff, but I took advantage of my knowledge in usability to improve the intranet and measure improvements. Contextual inquiry and guerrilla techniques were the norm, and I learned everything from reading books and websites, as nobody taught that stuff at that time. I did not even know the name of the techniques, just researched and proposed changes. However this was my first experience in working in a team, like a gear assembly where everyone depended on someone else. Every decision, even the most insignificant one, had a repercussion on my co-workers’ tasks and times. I could not just ask for everything users needed, but only realistic things, to adjust the budget, resources and time. At first it was frustrating not to be able to do everything, and even to think that what we were doing was insufficient to raise the intranet from the dead. Nevertheless a gradual improvement was made day by day, and when we did the first-year report and summarized what we had done, we became aware of the big changes in the intranet by comparing screenshots from the initial point to the current one—it was really amazing.

Design work was finished by the time I was offered a new job. The project was more interesting, and I felt change was mandatory the day I wondered if I had to learn UNIX to do a better job.

So I joined a great corporation to re-design one of the biggest public websites in Spain. My duties were a little bit of everything with a strong focus on accessibility. For a year, I worked with a great team and a great client, but the law in Spain is: politics are slow. Although we did it as fast as possible, any proposal or design had to be approved by at least five people. You cannot be at all the meetings where your design is going to be judged, so your design should speak for itself and any decision should be accompanied by the reasons for taking that decision. Technical knowledge is mandatory, but also strong communication skills are needed, both written and spoken. One year after leaving, the re-design was published.

Meanwhile, I got my second job for a big corporation—so huge; that in the NDA I signed I was almost forbidden to say I was working for them. Many people say “Wow, you’ve worked for ‘The Company’” and ask for more information about what it was like. I feel that I deceive them when I say I worked for a consultancy firm. I never actually stepped into the famous headquarters as my job was purely mechanical on “The Company” online interface. Indeed, the interface was so poor that the mechanical job became full of repetitive stress pain. I proposed some changes in the interface to improve it, but “The Company’s” response was zero. Deceived by this behaviour and with pain in my hands, I reduced my involvement to the minimum until the end of the project. I learnt not to be impressed by the name of a company you are working for; they are just another group of people looking for money. Instead look for good projects, no matter what company.

My next job was for a small company, where I thought the same was not going to happen again—and I was right. In this company it was quality over quantity, and we even got free cake on Fridays! I was hired to provide support on accessibility for some big companies, but I also did my best information architecture and usability reports there. I had finally escaped from the technical issues and even the code, and was completely focused on user experience, as I had always wanted. But numbers were not good, and we, four co-workers and I, knew it for sure the day we were fired. Maybe I was too idealistic about that “user experience” stuff, putting the user in the centre of everything. The last jobs showed me the importance of profitability for every company, no matter what size. So with that clearly in mind I faced my job search differently. My priority is still working on interesting projects about user experience, but from that moment on, I became a freelance professional. It has its pros and cons, like the certitude of being completely alone, but it also has the reward of being free to accept or reject projects.

And that’s the way I have worked until now.

Breaking the Fourth Wall For the First Time

About three years after starting to work as a designer for different companies, I was offered my first opportunity to become a teacher. A friend of mine was teaching Multimedia and needed a couple of weeks for personal issues, so she recommended me to cover for her. At first I was really frightened about what kind of questions I was going to be asked. I was still a junior and I did not attend meetings without the support of a senior consultant. But this time there wasn’t a net. It was going to be five days of Mambo CMS use.

I studied a lot, prepared some nice PowerPoint slides and downloaded a video-tutorial from YouTube with the same lesson I was going to give. When I got into the classroom, the students were checking their email. “They have good internet skills” I quickly figured out, “they are going to be a hard audience.” I introduced myself and asked them to do the same. Their profiles were very different: from 50-year-old housewives to 19-year-old chemistry university students. “Maybe they are too different for this course” I thought. Then I started my presentation. “Mambo is a system to manage contents on your websites”. Suddenly, the first hand rose. “Do we have to know how to code?” Strange question as in the syllabus of the course, no coding skills were asked. “No, don’t worry about coding, it is not needed.” I continued my speech, “We use Mambo to create complex websites with no need of coding.” Another person raised her hand: “But you have just said that it is for managing content on websites, not for creating websites.” Another person pointed out “But to create websites you need to code a lot!” A third person took part “I don’t want to code, it is very difficult!” Damn! What kind of students did I have? A rebellion after two sentences? I stopped the lesson and asked them why they attended that course and what they expected of it. It was then that I realized that their knowledge about the Internet was worse than I had previously considered. And they were scared. More than me, probably. Apart from emailing and googling, they knew nothing about the Internet. I was really surprised by their response. So I relaxed and calmed them down. I gave one third of the lessons I had prepared, but fulfilled all their expectations.

This first experience in teaching taught me to know your users as early as possible, so you can adapt your actions, contents and speech from the beginning. Because they are probably different from you.

Once I had overcome my fear, I decided to give personal lessons on design. I had time and needed some extra cash. I put adverts on several websites and the calls came at once. I selected five students and started the lessons. They were very different (Photoshop, HTML, Flash etc.) but their main goal was to pass an exam. In fact, they didn’t want to learn, but to pass an exam. They already had the books and tutorials, but wanted someone make it easier, because “books have many words; they are very difficult.” Although my fees were not low, those people were willing to pay for things that they could obtain for free with just a little of interest. In other words: people will pay you, if you can make their life easier.

Some years later I thought it was time to give back some knowledge to the Design community. Most of the things I know now come from library books, courses with scholarships and free tutorials on the Internet. I proposed to organize a free course on usability with the Cadius group in Madrid—Cadius is a Spanish speaking community of professionals from the fields of interaction design, usability and information architecture. About 30 people told me they wanted to collaborate in the organization, but finally only a bunch of them kept their word. We joined a non-profit conference series about science that is held in Madrid every year. We did this conference for two consecutive years and had a great time. In the second year we changed the focus of the lectures, in order not to repeat ourselves. The third year everybody was very busy (I was the very first one) and stopped organising conferences. We did it just because we wanted to, no money was involved, but it rewarded us with far more than we had given. For example, reviewing the videos recorded at the conferences, I found myself repeating a pet word. Although I have practiced at home, and my script was rid of this word, I could count more than 20 uses in just five minutes! Beside that I had changed some examples on the fly, and I still do not know why. Maybe I was too nervous to follow the script or had not practised enough. Anyway, people were happy and learned a little bit about User Experience. Probably they did not spot the pet word or the change in the examples. They really appreciated our effort. This taught me that it does not matter if you make little mistakes if the overall satisfaction is good. People forgive little lapses, especially when things are good, free and presented with enthusiasm.

So, here I was, able to speak about UX in front of other professional colleagues and university professors, as well as people who know nothing and have low expectations. So the next step could only be in one direction—try it abroad. It can be very easy to say but not to do. I was a young Spanish girl, with some UX skills and some contacts in the Spanish community. But I knew hardly anything about people abroad. The only thing I was sure of was that I had to speak English. I had taken lessons for years, but when I started at the university, I gave them up to enrol in French lessons. Ten years later, I needed to speak English again and I found it very difficult! A Spaniards’ level of English is traditionally quite poor. Only written skills are learnt in school, and the oral part is practically symbolic, so I downloaded tons of English movies (thanks P2P!). First it was really difficult to follow the storyline, even with subtitles, and five years later, I still need them sometimes.

My first international conference was in Beijing in 2007, but only as a delegate. There, I realized that my spoken English was not so bad; in fact it was much better than that of some of the lecturers. So I plucked up courage and tried my first shot. The conference was in Austria, and I spoke about my doctoral research. I felt terribly nervous, but I knew the subject, had practised a lot and had some slides to support my speech in case I was blocked. But one thing happened that I couldn’t foresee. My low-cost flight had landed so quickly that my ears were blocked; I could not hear anything for three days unless it was shouted! The worst thing was that I noticed it during the question time of my presentation. So I gave my lecture with few language difficulties, but when people raised their hands to ask questions, I entered into panic mode. I could not understand a word they said and continuously asked them to repeat their question in a clearer way! I became more and more nervous and finally had to leave the platform without answering anyone, feeling like an idiot. But, at the same time, I felt liberated as it could not get any worse. This was the worst scenario I have ever imagined in communicating in English. So from that moment on, everything could only get better. I got rid of my complex and practised my English diligently. There is still plenty of room for improvement, but if I hadn’t dared that first time, I would probably have missed a lot of opportunities, including writing this text now.

So, What Do I Teach Now?

Until now, I have enunciated some big value statements, but nothing about the content of the course. If you are reading this book you will probably know all the lessons, but here is how my background affects my teaching. I have summarized it into four big concepts.

It’s Your Life, It’s Your Decision

With the Bologna reform, exams are not the way to evaluate. In my case, the students have to work throughout the semester at the redesign of a product with the UCD methodology. Although attendance is requested at the university, I let the students do what they want. To keep them at the class, my lectures are like a “Lost” episode—much information, in an amusing way, but if they miss one, they will probably have problems to understand the whole subject.

To solve this potential issue, I mix the UCD theory and practice with an introduction about different, related disciplines, like information architecture, usability or ergonomics. If they miss one lesson, they have my slideshows on the e-learning platform and I provide basic bibliography, links and videos.

I can be flexible with the attendance, but I am not with their deliverables, as it is the only way to evaluate them. Probably those who attend will get better scores, but it is their choice.

Open Your Horizon

To complement my explanations, I use YouTube, comics or visits to archaeological museums. Knowledge is not only in Wikipedia. Books at the old library are also recommended as a source.

Also, I insist that my students have to try to speak English. No matter what their level or their mistakes, it is better to try as early as possible. Knowledge is available out there, and we cannot close our minds just because it is not in a formal way or in our own language. They have to dare, so they will not miss any opportunity.

You Are a Communicator

Design work is 50% communication (what you want to say) and 50% art (how you say it). There are plenty of subjects in the grade about art, so I focus on the first one. Moreover, 50% of our time is design and the other 50% is convincing others that your design is good, so I try to improve their communication skills both in oral presentations and written deliverables.

As you can imagine, simplicity, ease and user needs are stressed in the syllabus, and their redesign must reflect these concepts. Beside, all the deliverables related to the redesign must also follow these guidelines, as I want them to kill the myth of “Usability professionals make un-usable documentation”, from the very beginning.

Design Is a Profession

User Experience is not only about the user, but also about how companies benefit through design. Organizations, even charity associations, want to maximize the productivity of their actions. So the designer must also look for that profit, both for the company you are working for, and for the client of that company.

To get this, they must learn to:

1. Adjust the budget, resources and time to the reality; do not try to implement everything users, or clients, want or need. Be realistic.

2. Calculate (and communicate) the profitability of your design.

3. Consider sacrificing a quality product in order to promote a profitable one.

4. If you want a quality product, it will take time (and time is money, so return to point 1).

I know this may hurt the artist’s heart we have inside us, but this is what the real world is like.

About the Author

Olga Revilla holds a Degree in Journalism and a Master in Multimedia and Internet. Besides, she is a Graduate in Ergonomics and now she‘s researching on her PhD in Multimedia Engineering.

Meanwhile she manages the UX department of an Engineering Company and has her own business ‘Itákora’ where Olga thinks, designs, tests and audits interfaces.

In her spare time Olga plays basketball, draws and takes long walks with her dog.

Web: www.itakora.com

Twitter: itakora

Linkedin: http://www.linkedin.com/in/itakora

A Journey from Machine Design to Software Design

How It Began

I come from Sangli, a small town in central India, famous for sugar manufacturing and a large temple of Lord Ganesha. My family and I lived in sugar factory campus housing until I completed my engineering degree. I used to sit on the back of big trucks loaded with sugar cane, chewing on the sweet canes. My father worked as a chief engineer for, then, Asia’s largest sugar factory for 30 years, until his retirement. I cannot imagine working for the same company for three decades. I certainly can’t.

In 1991, mechanical engineering was the favorite course at every engineering college in India, and it was the subject I chose for my 4-year bachelor degree, too. A mechanical engineer himself, my father always urged me to improve my skills in managing big machines and shop floor workers. During my internship at the Cummins Company, I was fascinated by the unbelievably huge diesel engines manufactured for ships and mining haul trucks.

The 1990s were the era of mechanical engineering; this was every student’s aspiration in India. Unlike the multiple solutions of Human-Computer Interaction (HCI), mechanical design aims to identify the single optimum solution that is efficient, low-cost and easy to manufacture. In software design, you can afford to make mistakes and then release a patch to fix it. In mechanical engineering, however, a design flaw can result in huge costs, for example, of replacing a metal die and modifying manufacturing lines. Or in other words, you cannot release a car without a steering wheel and say it will be available in the next version.

During my engineering course, I learned how to design car components, such as gearboxes, transmissions, and pumps, following well-established mechanical design principles. These were based on the idea that “form follows function”, just like early design thinking at the German Bauhaus design school. As a mechanical engineer, I have always believed in the beauty of engineering-based design. It’s no-nonsense design. Look at fighter aircraft, for instance; their shape is determined purely by function, but at the same time, they are machines of real beauty.

Software engineering history started comparatively recently; it has been around since maybe 1940, or less than 75 years. Mechanical engineering, however, emerged way back, in the time of Archimedes (287-212 BC), with Heron of Alexandria deeply influencing mechanics. Software engineering still has a long way to go.

Automobiles: Field of Glamour

After completing my mechanical engineering course in 1995, I was campus picked by a famous Automotive Company, who primarily manufactured SUVs for the civilian market and the military in India. The company was located in the beautiful city of Nashik, some 400 km from my hometown. Nashik is surrounded by lush green mountains and is famous for its vineyards and wine making—the Napa Valley of India. The epic Ramayana mentions Lord Rama’s visit to Nashik, and there are many Rama temples in the area.

Being fascinated with design, I opted for the R&D department. I worked at the CAD center, where I first encountered high-end, 21-inch colour SGI & HP workstations. Using 3D modeling software such as CATIA and IDEAS, I made 3D engineering models of automobile parts and performed CAE (computer-aided engineering) stress analyses. At the same time, I used computers with black-and-white 15-inch monitors, working with dBASE and FoxPro via a command-line interface—no mouse.

A year later, we got our first colour monitors and Microsoft Office-equipped desktop computers. Each team shared just one computer and we used to line up to see what Word, Excel and PowerPoint were about. I remember being highly fascinated with MS Word’s formatting capabilities, compared with my old WordStar program. We got special training in MS Office but we still had no idea which program to use for what task. Because we liked Excel, most of our documents were spreadsheets. Nobody talked about usability back then, as we had assumed that we were the ones who lacked the skills. No one talked about ease of use; instead we tried to adapt ourselves to the software.

Another interesting point to mention is that we didn’t have email messaging at this automotive company. However, we did have inbox and outbox trays. We wrote notes on pieces of paper and the office boy used to deliver them to different people every day, according to the names on the notes. We could also send an attachment, such as a brochure, with the document itself. It’s what I call “physical and tangible email”. We were able to communicate with each other and work together in those days, so I sometimes wonder about how the arrival of email has really affected our lives. It has made everyone busy and waste a lot of potentially productive time with typing and reading. Sometimes I feel there is over-communication in general.

At the end of my second year at this company, I was shifted from CAD to prototyping in a management position. This is where I fulfilled my father’s dream, heading a team of 12 sheet metal craftsmen in an R&D prototyping shop. We made concept SUVs (prototype trucks) based on design sketches. It was the first time I really wondered where the design sketches came from and who had created them. What kind of skills did such people have? Were they engineers, architects, artists or painters? Then I found out about industrial design and the top design college in India, the Industrial Design Centre (IDC), Indian Institute of Technology (IIT), in Mumbai. Because I liked to sketch out my ideas too, I decided to leave a good job and pursue further education in design.

Adapt Engineering Design For Human Use: Industrial Design!

In 1997, I enrolled for a two-year Master’s course in industrial design at IIT Mumbai. Mumbai City is the financial capital of India and is also famous as a location for many Bollywood movies. The city is a mixture of LA and Washington, but the city architecture is British Victorian style.

Compared with software design, industrial design was very popular in India and it resulted in good placements for students with companies such as Tata Motors, Philips, Suzuki, etc. Software companies like Microsoft, Yahoo, IBM, and Oracle didn’t recruit HCI designers in India at that time, probably because nobody knew about HCI in Indian industry and schools then. Being a mechanical engineer and having previously worked in automobile R&D, I opted for industrial design with the goal of going back to an automotive company as a car designer. I loved cars. Many design trends were set in automobiles rather than the computer industry. It was more glamorous and visible than HCI.

It was at the Industrial Design School that I first heard of the internet and email. We used TELNET to send college emails. Email was a DOS program back then, with no graphical interface, just text and attachments. The Internet was very slow and images were banned. It is so weird to remember how we surfed the web without images, just text. What was the reason for the image ban? Most students were trying to view pictures, download movies and play games, however bandwidth was limited and expensive. Today, this is history. Everyone has their own laptop and network connection. In those days, search engines like Yahoo or AltaVista were very popular, and by the end of 1999, we all had free email accounts with Yahoo and Hotmail.

Designing Bikes in Italy

Just after completing my Master’s thesis in industrial design in India, I was given the chance to work in Italy at Centro Stile Piaggio, designing scooters. Piaggio itself is located in Pontedera, close to Pisa.

It was my first time outside India. It was good to work with the Italian designer of the Vespa ET4. I realized that everyone was a hardcore industrial designer there, that is to say, purely design-oriented and not technology-savvy. The designers didn’t use computer software for 3D modeling and engineering. They worked with pen and paper only. In India, a designer does everything.

In Italy, we used to debate each curve of a scooter sketch, think about each and every line and why it should be that way. Haha, I learned to be more detail-oriented. I began to realize that design is my passion. I came to see that everyone in Italy is a designer and art lover. The waiter in my hotel made wooden key chains; he gave me one as a gift.

My First Website

I came back to India and joined India’s top Scooter company in Pune as an industrial designer. Pune is like Detroit. There are three big automobile companies here. It is also called the Cambridge of India as it has many colleges. At the scooter company, I created designs for bikes and three-wheeled rickshaws. For the first time, I used the Power Mac and SGI workstations. I noticed that on the Mac, in order to remove a floppy disk, I needed to drag the floppy icon and drop it on the trashcan. I was afraid to do so because I thought this would delete all my contents on that disk. This is one example of bad metaphors that Apple had used.

Metaphors are great if used in the right way. We humans always relate our past learnings to new situations and objects; we generate preconceived notions of how things work. They form our mental model of every object we see. Our experiences from the physical world can be used to speed up the learning curve and accelerate interaction with software interfaces, but not all physical metaphors may make sense or may be applicable to the software world. The main reason is that software cannot convey various properties such as the sense of weight, smell, or touch from the physical world. We have managed to implement sound, for example we use the metaphor of an SLR camera shutter sound for digital cameras. But keypads on touch screen mobile phones are still in early stage, though I know many mobile companies are working to create a tactile effect for keypads on touch screens using vibrations or static currents. Another unusable metaphor I always see is rotating the volume knob using a mouse on a lot of mp3 player software. This is difficult to realize using current input techniques. A simple slider is always better for volume settings.

At our Scooter company, designers had exclusive access to internet. I started wondering how websites were made and decided to learn more. Yes, and HTML. I bought a few books on HTML, the Internet, and Web Design. The next question that arose was where to get a domain name from. Back then, ‘Network Solutions Inc’ was the only company that registered domains in India. By that time I had also received my first credit card, so in an attempt to check if the card worked online, I registered my domain, sameerchavan.com, in 1999.

My website had a black background colour. As the internet speed was slow, the site first showed a blank black page. My friends were worried whether the url they called up was my site or some porn because most porn sites had black backgrounds, even back then. When they told me about this, I immediately changed the background to white. When I updated my site, I had to take my files on 1.44 MB floppies to a cyber cafe to upload them to a server. And to upload 1MB of files, I had to take a cup of tea somewhere and come back later to the internet cafe. It took that long.

From Industrial- to Interaction Design

One of my friends (an industrial designer) from our team at Scooter Company got a job in a software company as a human factors engineer. We all wondered what that meant and what the heck he would do in an IT company without JAVA or C++. He explained to us that he would be reviewing websites and giving his expert opinion. This is called a heuristic review. So that’s what it was! And he was paid four times the salary compared with what we received at Bajaj Auto. This was the most amazing part. And believe me, within eight months,three more industrial designers joined IT or software companies with some fancy designations.

This was also the time of the Y2K problem and the dotcom boom. Everyone in Silicon Valley with a business plan had started up a venture-funded company with a sales office in the US and a development office in India. It was the time when so many software companies began coming to India and they needed people to work on the front end, whether you called it interaction design or visual design. The industrial designers were the most obvious choice to get hired, because India didn’t have interaction design or HCI or HF courses at that time. Since we had studied ergonomics, visual design, cognitive psychology and user research, we were getting hired by these companies. And yes, at four to five times the salary. I visited the popular IT job fairs in 1999 and 2000 and was horrified to see how 4,000 to 5,000 candidates lined up in front of hotels where these IT companies would interview them and give them on-the-spot offers. My heart didn’t agree with joining the queue of those 5,000 candidates. I felt I was not that desperate.

I applied directly to a Telecom IT company and fortunately got hired as one of the founding HCI team members. We all were industrial designers and our head was also an industrial designer who was working in IT networking. He had spent most of his career in the software industry rather than practicing industrial design. He had realized that an HCI department was needed in his company and had convinced his management to set up this HCI team. So we were hired and that’s how I came to the HCI field.

What to Call It—HCI, User Experience Or Usability?

Back in those days, “Human Computer Interaction” or HCI sounded more like engineering and it was an interesting term. It conjured up images of some sort of robotic science. It was respectable. I have seen in different companies that the department name is somehow related to its relevance to the company. For example, at this Telecom IT company, we called ourselves the ”User Interactions Group”, because we were trying to explain what we did, namely ‘designing user interactions’. At PLM, the next technology-oriented company I worked for, the HCI team was called ”Usability Engineering Group”, as it placed us on a par with other engineering teams. Engineers were highly valued there. At Enterprise Web Company, the HCI team was designing the overall experience in CRM, HR, Financial applications. So it was referred to as the ”User Experience Group”. Also, at an internet company we decided to call ourselves the “User Experience team”, as it was all about users’ internet experience. Most Indian service companies used terms like ”Customer Experience Group”, “User Experience Management” or ”Unified Experience and Knowledge Solutions”. Maybe they want to impress their client first. Here in Korea, where I am right now, at a large telecommunications company, we call it HCI again, as it is a technology-oriented company. It will be interesting to see how different companies coin different names for departments to justify their existence and to align them with the company business. As far as UX job titles go, that is another big story ...

User-Centered Design: What’s the Fuss?

In the last five to eight years, I have noticed that many product design firms have started calling themselves “user-centered product design” firms or they boldly write “user-centered design” on their website. Why this sudden change in strategy? Was it be because they never thought of users while designing before? Or, if you don’t mention UCD, does that mean, you are not following a user-centered design process? This strikes me as very strange. Industrial or mechanical design has always been design for the user. It was only the software industry that started out as technology-oriented business first and user-oriented next. As the technology side became saturated and matured, the same folks who at first were into technology now began to shout “user first” and to popularize UCD. Now the situation presents itself like this: If others don’t talk about UCD, they are considered bad designers or bad design companies. I think that UX has become a buzzword used by companies trying mainly to differentiate from their competitors.

Evangelizing Usability

As a member of the founding HCI team of this Telecom IT company, I didn’t have much of an idea of what usability really was, nor did our team. But we were all familiar with the industrial design process, its methods and techniques. So we started reading lots of books on HCI. The most famous ones were Jakob Nielson’s Usability Engineering and Alan Cooper’s About Face. We then called ourselves the “User Interactions Design Group” (UID). The engineers in the company also had no idea what our team was and what we were doing, so we started to conduct trainings. We taught software developers about heuristics, GUI form design and user research. In case you haven’t noticed, Pressman did not include much about usability in his Software Engineering book. I wonder why software engineering didn’t emphasize usability. They do mention use-cases and requirement gathering in the book, but there is no section on UI standards.

We gave away free copies of HCI books to different development teams. We even held competitions to spot the design problem. Slowly, the development teams started asking us for actual visual design and images. So we had to hire visual designers. In India, people with education in BFA (Bachelor in Fine Art) would take up software Graphic designer roles. Back then, their educational course didn’t included software engineering and UX . So these people where less conversant with UCD. We had to train the graphic designers to think in terms of usability. Later, we also found that the development team was not able to code based on our visual specifications. So we had to hire a few UI developers. They were experts in optimizing HTML, CSS, JavaScript, etc. So our HCI department grew from a bunch of interaction designers to also include graphic designers and UI developers. Later, we even hired usability engineers to do user testing. A HCI team in a company should be a mix of people with different skills and educations.

No One Pays For Usability

This Telecom IT company was a software service provider where a deal was closed by the sales team, and they never factored in usability as time and money. It was always really just about understanding client requirements and then proceeding directly to the development stage. Where was the time for interaction design, usability testing and research? Moreover, clients were not ready to pay for this ‘service’ separately. Historically, product companies had HCI teams. Service providers were focused on high profit margins with minimum time and resources, so we never had a proper usability lab or a user research team. But we did manage to do a little bit of both. The scene has changed now, as service companies do plan for separate budgets and resources. Why? Because the HCI teams in India have put a great effort into convincing first their management and then their clients that user experience does not come by accident. It is not something you do at the end of a process or in your spare time. You need to design for better experience right from the beginning. And it does not come free. Also, because of many websites such as flight and hotel booking sites, as well as Google and Yahoo, users now understand what good design is. They can compare and tell whether your design is good or bad. Clients, too, have realized this. Competition is tight. All this has led to the development of HCI teams in Indian IT service companies. On the other hand, HCI was not that difficult to realize at product companies. The HCI teams in US product companies insisted on setting up HCI teams in their Indian subsidiaries. When I stared in 1999, only two or three companies had UI teams. But now, in 2010, every company has a separate UI team.

Everyone Knows Usability

In 2002, I started working for PLM. They already had a good HCI team in the US and I was the first UX designer to be hired in India. The interviewing manager asked me whether I knew what the abbreviation UCD meant. Wow! That was it. I was hired. The hiring manager was so glad that I knew UCD. Ha!

We had a proper usability lab and also remote usability testing equipment. I did my first ethnographic study (contextual enquiry) in Cambridge, UK at a client’s location. I observed shop floor engineers entering part numbers into our system. I saw how they multitasked using other software, as our product lacked some features. It was also the first time I was part of a remote usability team. My manager was also a UPA chapter head in Minneapolis, and that’s how I came to know about UPA and SIGCHI.

Enterprise Web Applications

In 2004, I began working for this US top Enterprise Web Application company; I was the first person they hired in India. I was instrumental in setting up their HCI team and the first usability lab forIndia. I monitored the construction of the lab from ordering ergonomic chairs to buying a one-way mirror. The setting up of our team coincided with the move to a new building and we made sure that the usability lab was on the ground floor and easily accessible as soon as you entered the building. Firstly, we wanted to show everyone who came to visit our company that we did user testing and secondly, we didn’t want to have test participants walking around the building too much.

I was quite amazed to see how our Web UI standards team had put every task flow, whether for financials, HRMS or CRM, into one design pattern with defined tabs, action buttons and a work area. Having a standards-based design for an enterprise suite is very important. There were many development teams across the globe developing applications on the enterprise web application server. As a UX team, we wanted to make sure that they followed a standard design pattern, so the user experience is consistent for those users who use many of our applications at the same time. In general, users should not have to relearn everything all the time.

I gave a presentation on standards-based UI design at an Indian UX conference in Bangalore (Easy04). Among the audience ,who came from service industry , some had difficulty in understanding why UI standards are required. They worked on projects with different clients and delivered the code directly. I had to explained that a product company needs to have UI standards as they have a family of products, which they enhance every year. This is also helpful for multi-location UI teams who work on the same product.

Internet—the Age of E-Commerce

In 2007, I joined India’s top internet portal as Vice President of User Experience. I headed a team of web designers. Yes, now in India you can find VP UX positions. Back in 2001, there were only UI Designer positions. This aforementioned internet company has a top job site, a marriage site and real estate websites. It is the Yahoo of India.

The company had four separate teams: web design, product management, development and sales. When I joined this company, I saw that most of the Interaction designs were decided by the product manager, and the web designers were just implementing the decisions. The product manager took all the decisions regarding the functions, the layout, page interactions, buttons, colour schemes and every text on the site. They were really smart guys. But I thought this process could be improved and some responsibilities could be shared with UX teams This way product managers focus more on customers, market studie and sales plans—and the UX team focuses on design. It took some time for this transition. But finally it did happen.

I reported to the CEO and was able to convince him that we needed people from different backgrounds in my HCI team. I hired good designers from top Indian design schools and companies and made sure they had different interests and skills. I didn’t wanted a UI designer doing usability testing of his own design and influencing usability test participants. I didn’t want a graphic designer spending time on interaction flows and vice-versa. I didn’t want all my UX designers sitting in front of Dreamweaver doing HTML.

So now I had visual designers, interaction designers and usability engineers doing their specialized tasks. I transformed our team of 15 web designers to a 40-member User Experience team. We started doing user interviews and contextual inquiries. I took my usability engineers to recruiters where we saw how they used our job site and how recruiters maintained their own résumé database. The UX team also did some joint user research together with the Product Manager. Earlier design decisions were taken on the basis of the likes and dislikes of the Indivisuals. But then, we started usability tests and showed which design users actually preferred. I trained our content writers to write for e-commerce sites and web applications.

HCI Conferences in India

Being a usability evangelist, I started to host local community UX meetings when I worked at Enterprise Web Application at Hyderabad. We invited HCI folks from other companies and provided a platform for knowledge sharing. Initially, Hyderabad was like the Silicon Valley of India, until it was overtaken by Bangalore. Microsoft, Oracle, CA, Google, IBM, Accenture and other global players have development centers in Hyderabad.

I told my VP UX about my ‘evangelist’ activities. He asked me why I didn’t do this formally and set up a UPA chapter. I attended the UPA Denver conference (2004) and proposed a UPA Hyderabad chapter. It was approved and we went live with our website upahyderabad.org. We did the first and the only UPA HCI salary survey available until now for India. I also proposed a reduction in UPA membership fees for developing countries like India like in ACM SIGCHI policy.

I had met the Director of World Usability Day (WUD) and we started doing a few WUDs in India. The HCI community in India was very small then—may be less than 500 folks—but currently, we have good WUD conferences in India. One of them is usabilitymatters.org

There are now peer-reviewed paper submission conferences in India, conducted at an international level. However, only the speakers are international, and there are no attendees from the international community. Unfortunately, I have not seen Indian UX conferences continuing every year. Most conferences simply fade away after four to five years. This is because the founding team members are no longer together to continue organizing the conference. None of the UX conferences have elected bodies; they are all one-man shows. I hope if we have elected members, new members could get a chance to organize conferences and then conferences may continue year after year.

We hope to have UPA and CHI conferences sometime in India.

Mobile Design in Seoul

Currently, I work in Seoul with a large electronics company focused on mobile phone design. There are many things I am learning right now about the culture and the way they practice usability in Korea. Here, it’s all about technology. I have not seen any usability communities or forums. Nor have I seen any kind of knowledge sharing among the companies or even within the same company. This may be because it’s a small country and a highly competitive market that is divided among two or three strong players. There is lot of emphasis on benchmarking and competitior study in HCI design. Its difficult to convience new designs unless someone has already implemented it in another country.

I’ve read that big multinational companies have failed to adjust quickly enough to the tastes of South Korean consumers, so companies like Wal-Mart, Nokia, Nestlé and Google had to wrap up their business pretty soon.

Here, no one uses Google maps, eBay or Facebook. They have their own local version of every product and perhaps they are better than the international ones. What I like here is the fast pace of innovation and the very fast Internet connection.

Everything is perfectly designed, from roads to electronics to metro trains. Seoul is named the World Design Capital 2010

Concluding Notes

From the variety of experiences I’ve had over the last 13 years, I have learned that design is never finished. You can keep improving your designs as long as you have the resources, time and money to do so. We take a decision to halt further innovation at a particular time, as we feel this is what we can achieve with the available time and resources. Design is a continuous improvement process. UX designers will have to continue to evangelize and keep justifying their designs and convincing stakeholders. I have realized that if you are not a good advocate of your ideas, they may not reach the production stage. User experience is not an engineering topic that can be proven like a theorem. It’s a mix of art and science.

About the Author

Sameer Chavan currently works at LG R&D Labs at Seocho-gu, Seoul, South Korea as Chief Interaction Designer and Researcher in Mobile domain. Prior to this role, Sameer was running his own User Experience Design consultancy from Pune, India by the name “LillyChilli”. Previously he worked at Info Edge India as Vice President User experience and at Oracle as Manager User Experience. At both companies he set up User Experience teams and Usability labs.

Sameer is a founding member and president of UPA Hyderabad. He has worked as User Researcher, Design Manager, Usability Evangelist and Product Designer with over 13 years of Industry experience working on Mobile, Enterprise Web Applications, Internet Portals and consumer Websites. He has two pending US patents in UI.

Web: www.sameerchavan.com

Twitter: sameerhere

Facebook: www.facebook.com/sameerchavan.me

Linkedin: www.linkedin.com/in/sameerchavan

UX the Long Way Round, Ken Beatson

User Experience Design (UX) is a much younger profession than its practitioners. We’ve almost all migrated here from other professional “lands”, bringing our own unique histories and perspectives. I came here from fairly nearby places; I was a database developer, web developer, designer and web project manager. Others came from slightly further away: product designers, graphic designers, librarians, marketers and many other interesting starting points. So here’s the story of my journey to UX, together with some of the things I picked up along the way.

Love at First Sight

I was instantly addicted to the web. Love at first sight. It was late 1996, about halfway through second semester, just after morning tea on a Saturday. I could still smell the “new” in the University of Tasmania’s shiny, modern North West Study Centre, which felt like a brave new world of academic prosperity brought to the declining small industrial city of Burnie, Tasmania, Australia. Tasmania, for those of you who are American, is that little triangle-shaped island at the bottom of the Australian continent. It’s not that I am picking on Americans or taking sides with those unkind people who regard you as geographically challenged. I just appreciate that you’re surrounded by a heck of a lot more of your own country than other nationalities and so it’s harder to get out as often.

So here I am using Notepad on the new lab computers, in the new lab, exploring this new thing called HTML. Text with pointy brackets gave me tables, colours, fonts, backgrounds and even blinking text. I was making web pages! They looked just like real ones on the Internet when I viewed them in Netscape 2.02. I’d borrowed HTML for Dummies from the public library. I’d only been reading it for a couple of hours and I was already making real web pages! I edited the code in Notepad, saved, clicked refresh in Netscape and there was my updated webpage. The feedback was so instant and visual, unlike the C++ and COBOL I was learning in my classes. That was hard work because you spend loads of time writing and debugging your program, then when it finally runs, you get the wrong set of numbers out on the other end and you don’t know why. Not exactly compelling stuff. But HTML was everything I loved about both programming and visual design.

This was not part of my Bachelor of Applied Computing degree. Learning about the web was an elective course in second year (which I didn’t even know about at this point) and I’d decided to do a little elective study of my own to get under the hood of this wonderful thing called the World Wide Web.

By Sunday afternoon, I “knew” HTML. This, plus my basic Photoshop 3.0 knowledge, gave me everything I needed to make great web sites and surely get very rich after I graduated. Something magical would happen and I’d get snapped up by some shiny big global company, get paid zillions and get to fly all over the world.

I graduated 5 years later with a combined degree in commerce and applied computing. I didn’t get rich. I actually ended up working for the university I studied at, then another university in New Zealand (NZ), eventually for a small start-up in London, a peppering of various consulting jobs along the way and finally I’m a UX designer working for a small agency in Christchurch, NZ. Somehow, I managed to help create London’s largest UX community online (London IA) and learn a bit about UX along the way.

Roller Coaster Online

So I “lauched” my first website in late 1996. Let’s face it, the site was crap. I never really updated the content because I was too lazy to, and the icons I’d sketched (to give that handmade touch) were basically saying, “Hey, I love that Comic Sans font ... I’d like my whole website designed by the guy who created that font”. The site was the online version of the student magazine for the North West Coast students called—wait for it—”Roller Coaster Online”. At the time, this was my first website, a real live website and a clearly wonderful thing in itself. Everyone would love it, obviously. I was explaining this to an old guy, a former beekeeper now studying education. He’d start working at 3am in the labs and bring his own paper to do huge clandestine print runs using the free printing. He wrote his essays by printing all the related articles he could find, cutting out interesting topics from each and putting the cutouts into boxes ordered by topic. I guess that sort of makes him the first IA I ever met. Anyway, he suggested I should update the content once in a while. That caused a slow but steady dawn of realisation that just building it mightn’t have been enough. I hassled the committee who published the mag to put everything online. They didn’t want to, for fear that students might stop reading the paper version and upset the advertisers. This is where I learnt that whining about how great the web is and how people “don’t get it” isn’t a very persuasive approach.

Getting Paid and Everything

Early the next year, it was time to move down to Launceston (still in Tasmania, just in the middle of the island now, instead of at the top) to continue the rest of my degree. I was about to have a major stroke of luck. While buying textbooks, I bumped into my old tutor and casually mentioned on the spur of the moment that I was after web work. Two weeks later he contacted me and asked me if I’d be interested in a $2000 project doing the new Human Resources Department website for the university. That’s a lot of money when you’re a student! This got me into doing “real web work” and I continued to have as much of it as I had time for during the rest of my study. I did various other department sites in the university. It was also the perfect part-time job and provided a base of consulting and web skills that my university study didn’t.

One of the most astounding things I noticed was how otherwise normal people were rendered temporarily insane when thinking about doing things with the web. They would use a reasoned, well-considered and rational process when designing printed brochures but unleash utter madness on their websites. Brochures, nicely structured and laid out with good pictures gave way to websites akin to compost heaps festooned with leftovers from the print publishing effort and other offcuts. They were a decaying mixture of pixelated pictures, waffly stale content and colours, all of which were long past their use by date. I still don’t fully understand this phenomenon and what drives it. I just knew that I was mostly immune from the thinking paralysis that surrounded it. I was learning that most clients struggle to understand the medium of the web and don’t see that there are many rules that transfer between print and web. Luckily, my first client, the HR department, never had that approach and their practical and focused thinking gave me a solid grounding to kick-start my consulting career.

All these clients in a vulnerable state gave rise to a food chain of predators, parasites and scavengers calling themselves consultants. I once read a Dilbert strip where the character Dogbert explained that he liked to “con” and also to “insult” people, and how the word “consult” was a fusion of these two ideas. This was apt for web consulting in Tasmania in the late 90s. There were an astounding number of people running around calling themselves web consultants and some of them drove their clients to me through their random acts of web development and their Frankenstein design. I remember one that was infecting the university’s International Students Office. A remarkably shifty and incompetent guy had been thrust upon them as part of a senior management initiative. He could talk the talk but his designs were a hideous monstrosity of primary red, fluoro custard yellow and a stately royal blue that was far too classy for the sordid company it was keeping on the page. His content management plan was to get all the department staff to edit the site in Netscape Composer—probably the buggiest and most unreliable editor available at the time and very probably one of the worst in the history of time itself. Imagine your beautifully crafted Notepad HTML page as the Mona Lisa. Now imagine Netscape Composer as a petulant three-year-old child attacking your masterpiece with a set of crayons. That’s your page after Netscape Composer was finished with it. These were dark days.

I graduated feeling pretty drained at the end of 2000. It had been a long five-year degree—especially the commerce and HR bit. By the way ... a tip for those people considering doing an HR degree. Don’t. Read The Dilbert Principle instead. It gives you everything you need to know more cheaply and with no pain.

Career Choices—Still at Uni

I didn’t know what I wanted then. I had no career plans, only strong ambition without direction. I was torn between two choices. I had a strong desire to see the world and advance my career in management consulting through the graduate recruitment track. But my passion was the web and I couldn’t tear myself away from that. I was still very green and, looking back now, pretty immature. I did the graduate recruitment round and got through to the final interviews for a couple of firms. At Ericsson, I asked some dumb questions about web opportunities and they spotted my heart wasn’t in it. I was almost relieved when they let me down gently. Other friends joined PricewaterhouseCoopers (PwC). I had an offer from PwC open for a couple years and almost joined them twice. But there were family and relationship issues that kept me at home and I just wasn’t ready to do the big move from Tasmania to Melbourne and further afield. My best friend at the time turned down a position with Andersen Consulting and also stayed on in Tassie for a couple of years.

This was a pretty good time as it turned out, and a good place to wait out the aftermath of the dot com bust. They were good years, if not all that productive. I lived in a western red cedar house on stilts up in Trevallyn, on the hill facing the morning sun, with a 180 degree view of the river Tamar winding its way through the city and out to the hills in the distance. A big deck and plenty of space to have BBQs, parties and generally cut loose in my early to mid 20s.

So the world of universities would dominate the next seven years of my working life. And it is another world. Making headway is sometimes like swimming through treacle. There are consultation processes, committees, subcommittees and of course “academic freedom”, which can be interpreted in more ways than the Bible. Meetings were relentless time slurpers and people both loved and loathed them for all the reasons Dilbert readers and those working in large organisations will be familiar with. Reasons include a chance to avoid doing real work, talk, have personal interaction, grandstand and gossip. I had withdrawal symptoms when—much later—I finally worked for a small firm who mostly teleworked and had a couple of full face-to-face team meet-ups a month. We chatted and met one-on-one regularly to discuss specific things, but that was about it. It was amazing how much I got done.

One of the major challenges with universities is that there’s really no central control structure. They’re more like a collection of fiefdoms. I was working in a central service unit which acted as an internal web consultancy. The academic departments are often cynical and resistant to central initiatives, often for a variety of good reasons. Persuasion, flexibility and educating clients about ways the web can add value was critical. For example, it’s often best not to approach a new idea head on, but lead people to a better approach diplomatically by increments. I remember working with a university client who wanted to rush at discussing links on the home page without first looking at the users, their needs and how these relate to the areas of the website. I wanted to use an approach akin to those described in Indi Young’s Mental Models to work the problem through. But if I’d suggested it outright, the client would probably have not understood it, declined it and insisted on going straight to discussing the links. So I just asked to spend 10 minutes of the 1 hour meeting looking at the user tasks. We actually spent 40 and at the end of it the client really did see the value and got some insights they hadn’t expected. But they needed to experience it to see the value. I couldn’t just expect them to take my word for it.

There is sometimes a tendency to put users on a pedestal of always being right, but to see bosses, clients, marketers and other people on the business end as idiots when they don’t ‘get it’. But I’ve found it is important to understand and accept that they need persuading and educating. The trouble is, needing to do this all the time can get you down. I’ve always found it hard to keep pushing against the tide and at times it’s been frustrating that the people around me don’t get what I do and the value of user-centred design. The UX approach is so much better. Why can’t people just accept it at face value?! It took me a long time to see that to succeed, part of our role must be educational. I actually needed to use educational techniques to get my points across, be prepared to compromise and most of all, be willing to accept the fact that people learn gradually.

This is one of the main reasons I didn’t get on with one of my colleagues. She was very knowledgeable but I found her approach bureaucratic, defensive and impractical. She was often more knowledgeable than me but I could get more good, usable designs into the university thanks to my design ability, taking a collaborative approach by becoming part of client teams, and compromising a bit to keep clients happy. Being a bit raw on the team skills front managed to get her back up by doing a poor job of communicating how I felt and acting like a smart-ass at times. She taught me a lot about classic usability and accessibility theory. She was extremely bright and very learned. But she also showed me a set of key characteristics of many other practitioners and approaches which have held back the potential for UX to help organisations. Most of this comes down to education again. People need to be educated about the process, the web generally and go on a journey of discovering what they really want. People don’t read big, dense documents and need to be walked through things. They are busy and often need to be nudged to get things done on time. You as a consultant need to take responsibility to get results and expect all this to be par for the course. People don’t by default understand UCD and its value ... get used to it, accept it, and reach out to them. Don’t clam up and hide behind a wall of process documentation.

A further problem is that our type of work needs patience, empathy and sensitivity. We put ourselves in the place of a range of users with a range of goals and perspectives to get the insights that we need to do user-centred design. I haven’t met many UX people who I’d describe as brash, hard-nosed or overly extrovert. We’re not natural marketers or sales people. And we tend to take things to heart.

It’s so good to see us as a profession now getting away from the “websites that suck” mentality. These approaches seem to have caused usability to get a bad name in some situations. People in traditional brand and marketing had the right ideas but were applying them in the wrong ways. They didn’t understand the web and the value of usability. Well, why should they really? It’s not their area of expertise. But our reaction mustn’t be to get defensive and retreat into defending our turf. We’ve got to go out and meeting them, bring them in, including them and showing them results that are within their reach. We need to give business people that “don’t get” websites the same amount of respect as we do website users we might design for and approach them using the same attitudes. They’re all doing their best.

It was 2005 and I had done a CMS deployment, two rounds of re-branding and redesign and a host of other projects for the University of Tasmania. It has been a great stint with plenty of variety, project management progression and I could now jump into the management track if I wanted to. I did PRINCE2 training and kidded myself that I could do that stuff full time and like it. Big projects, lots of controls, full methodology of reporting, stages, definitions of what’s produced and processes galore. A few years later, I eventually realised this wasn’t the path to career happiness for me personally. It’s the creative equivalent of eating dry Weet-Bix but without that nice wheaty flavour.

Moving Back “Home”

My father was very ill and it made sense for me to move back to New Zealand to join the rest of the family. A Web Team Manager role happened to be going at the University of Canterbury in Christchurch on the South Island so I grabbed it with both hands and jumped countries.

It was a huge emotional experience being “home” after having left reluctantly with my parents at the age of twelve. New family I’d never seen, all the familiar things that warmed the cockles of my nostalgia and a very conservative university going through major upheaval. The biggest learning curve, initially, was really getting up to speed with my management and leadership skills. But despite all this collaborative pragmatism I’ve been banging on about, I was still working with a very basic toolkit of techniques. For example, it’s scary to think that back then I didn’t realise how much traditional meeting formats suck for many group work exercises. They’re good for general discussion on a topic or getting agreement on a simple set of points. But they’re terrible for doing lots of UX things, like brainstorming, ordering and prioritising large numbers of things like system requirements and moving people to think differently. Just using meetings with a whiteboard for all this is like having a toolbox full of nothing but hammers. I still wasn’t fully getting it. I could come up with the perfect structure for the meeting, prep the participants well, but at the heart of it the structure still sucked for doing workshops. It wasn’t truly collaborative and not everyone was really engaged. I was yet to discover the full power of sticky notes, affinity diagramming and properly planning the participant interaction in structured workshops.

Here’s what happens when web meetings go wrong. Many of us have been there. An hour meeting is booked to discuss the new website. Everyone turns up. The web consultant chairs the meeting. Vague discussions meander around where each person in turn puts their point of view out about what they think should go on the site and what form it should take. It’s a fruit salad of features, links and vested interests and everyone wants to have a bit of their idea go into the website. As the meeting progresses, everyone hunkers down and defends their turf and it becomes a competition on who can think of the brightest ideas and have them acknowledged by the group. Say hello to Frankenstein design.

Working with a leading knowledge management consultant on a content management project while at the University of Canterbury really opened my eyes to what I should have been doing all along. He coached me on some of his techniques and I was off and racing after that. Key elements were physical ordering of objects to prioritise them, structured exercises to get people away from fixed thinking, the power of small groups competing with each other to generate results. All this was so much better than the standard things which went on in the sector. Good facilitation skills, a range of workshop formats and a range of exercises are so critical to the UX consultant’s toolbox.

I’m really, really lucky I feel the same level of passion now as when I was fresh out of uni a decade ago. That wasn’t the case back in 2007 when I was nearing the end of my term at the University of Canterbury. It was a combination of needing a change, needing to see the world and also the role not totally fitting me. I went through different roles, each with quite a bit of challenge and variety. Still, the weight of a large organisation takes its toll. It’s the classic problem of internal politics, not being able to get things done, and in web, everything having to fit into the same template. It’s a world of overcoming restrictions. I was starting to stagnate and become a bit “institutionalized”. It reminds me of what Morgan Freeman’s character “Red” said in The Shawshank Redemption “These walls are funny. First you hate ‘em, then you get used to ‘em. Enough time passes, you get so you depend on them. That’s institutionalized.”

I became increasingly hungry for something new and ended up starting too many new projects. My attitudes to political challenges and obstacles were becoming more defensive. Most notably, I was a Web Team Manager looking for excuses to do hands-on UX consulting work wherever I could. I was still functioning well in my role overall, but I was running out of gas fast.

Luckily, a restructure brought a welcome redundancy. I took it with both hands. I’d just met the girl of my dreams and wanted to go travelling with her more than anything before we settled down into our mid 30s, got married, had kids and had to act all responsible. That would provide the opportunity and challenge I needed. That and the looming credit crunch I was landing in the middle of.

The Belated “OE”

I should explain about the “Overseas Experience” or “OE” (Colonial readers can skip this paragraph). When you’re an Antipodean, you’re surrounded by ocean and Europe is a very long trip away. So you take holidays abroad (we call it “overseas” because of that big lump of water around us) in large chunks to make the most of the long journey. And to experience Mother England and the Old World, you do an “OE”. It’s a rite of passage for many and some even stay on.

We went through Thailand and landed at a snow-covered Heathrow on Easter Sunday 2008. We stayed with parents of friends, relatives and in make-do short-term accommodation. I was dodging falling pieces of crumbling banking infrastructure. The credit crunch was hitting full swing and the Dow was plummeting along with the FTSE. It had been a tough slog. It took almost two months. During that time, I’d really had to think hard about where to head next. I could have got sidetracked into project management, web editing or a bunch of other careers. Philosophically, I was thinking of it as a holiday job; practically, we needed something to stop the “cash burn”.

Shockingly, London wasn’t just a place where you magically get catapulted into your chosen career just by virtue of being from Australia or New Zealand. You need the right skills and direction and there’s all this sweating blood in between. I hadn’t properly researched the London job market. I was too much of a jack of all trades. I had this collection of role components in my past roles which were very broad, shallow and generalist by London standards. Management, web developer, project manager and IA. I couldn’t really imagine wanting to do more staff meetings, HR, position descriptions and organisational politics, so management was out. Web development was really becoming a commodity and my skills were quite rusty for what the industry demanded in the UK. I didn’t really like pure project management—more Gantt charts, project planning, long documents, methodologies like PRINCE2 were all dry Weet-Bix variants to me. So I decided IA and UX roles would be a lot more fun and I tried like hell to land one. It was the first time I totally let go of ladder climbing and just went for something modestly paid that I loved doing.

IA in London

I finally managed to get a permanent IA role at a little startup called MyVillage.com. They’d been a dominant force in local entertainment guides during the late 90s but had since been overtaken by the huge number of other players in that market. So they took an increasingly smaller share of the pie and were hoping to turn this around by adding strong social recommendation elements to their core product which centred around restaurant, bar and gig reviews.

The working environment was totally different from anything I’d known. I was interviewed at my boss’s house. My first task as IA was to run down the road and get some milk from Tesco. I worked out of a small office in Notting Hill three days and from home two days.

What I loved most was seeing the results of my IA work so quickly implemented. My wireframes were turned into real pages within a couple of weeks in the semi-agile production environment. We built and launched sets of features for each module. There were many work streams to keep track of and shared interfaces between streams needed to be watched so we didn’t get version conflicts. It was a kind of organised semi-agile chaos. The developers were in another country so I had to work remotely. I could finally get away from the documentation-heavy approach required by universities and get into specifying things through prototypes using Axure and other tools. It really was about just getting things done any way I could. It was all madness and a welcome breath of fresh air—the can do attitude, the need to be self-sufficient, the pragmatism and the total lack of constraints apart from no money. This is where I really got to do interactive prototyping using leading-edge tools and understand the commercial drivers behind web applications.

But I was still the lone practitioner and so much more so because of the small company size. I really hungered to connect with other professionals. Luckily, I was in London and there were about 1000 people like me who felt the same. Now all I had to do was go out and meet some of them.

Starting London IA

Everyone was nice enough at UPA events but I was kind of a nobody working for a tiny company most people had never heard of. Small fish, very big pond. At least back in Christchurch, New Zealand, I would say I was working for the university and that got a bit of kudos. Most of all, I was shocked by how little IA and UX community activity there seemed to be in London. There were these IA and usability London mailing lists on Yahoo that only ever seemed to send out jobs. Then Paul Wheeler, bless him, organised a get-together to see what we could do about it. About a dozen of us from the Yahoo group london_ia met at the Wellcome Trust offices, which I would later learn had some of the lushest muffins to be seen anywhere in London down in their café. I still owe Paul one of those. I really hope I get to buy him one someday. But I digress. We all wanted something better than Yahoo and I suggested Ning because I knew about it through MyVillage. I proposed, with a spark of creative genius, that the group be called ... “London IA”.

Back at the University of Canterbury, I’d started a tertiary web group for New Zealand but that was hard going. Being geographically separated was the main killer I think. We organised a conference that went well but after that, things petered out.

London IA was different though. It started out in August 2008 with about a dozen and grew steadily to 35 by invitation only. It pottered along for a few months. Then I opened it up to everyone and got a big plug from one of the UX recruiters. There was a strong appetite for online interaction, pub meetups and something different. The group exploded to 300 or so and just kept growing and growing. Now it’s over 1000, thanks in no small part to the efforts of people like Matthew Solle, Martin Belam and Tom Coombs.

I “got” the way professional organisations and conferences were changing for the better. It’s like the UX Bookclub idea, “low cost of entry” and “everybody learns”. What made London IA work was:

1. There was nothing else like it at the time in London

2. People had existing relationships which they reestablished online

3. People had something in common—a strong common interest

4. People had a desire to connect that was driven by various things, not least of which is the feeling of being an isolated professional forging a new frontier

5. A base of engaged people with some useful content ticking over so there’s always something to come there for

6. Some events in the physical world to anchor on—even if they’re just meet-ups

7. Not plugging it or trying to grow too fast or being commercial

8. Letting the membership steer it

9. Being low cost

These things really helped me to understand what does and doesn’t work about setting up online communities. Being part of the group gave me energy, hope and a hunger to learn and improve. It challenged my knowledge level and made me try new things.

Eventually though, all good things must come to an end, especially when UK Immigration changes your visa rules. We were hoping to make the UK our home for at least three years but it wasn’t to be. We had met up with my fiancée’s family, had Christmas in Devon, sampled Europe and made lots of great friends. So in June 2009, just as summer was threatening to happen, we did a final road trip around the UK and left old Blighty, returning home to Christchurch, New Zealand via San Francisco. I didn’t dare expect to get a specialist UX role in Christchurch—a city of only 300,000 people—much less an agency one. But I had been introduced to a Kiwi returning home and he in turn put me in touch with LeftClick who were hiring.

I now see this city I had lived in for 3 years previously with new eyes. There are so many opportunities and so many great software companies here. Now I’m learning even more and it’s almost like the hunger I felt when I started uni for the first time. That sense of being alive tells me I’m in the right place and that I’ve found the right career.

About the Author

Ken Beatson is Senior User Experience Designer at LeftClick, a digital agency in Christchurch, New Zealand. His path to agency UX has been via 8 years in university roles including web technical, project management and business analysis across Australia and New Zealand. In 2008, he was looking for a change and took the plunge moving to London with his fiancee in the middle of the credit crunch. He worked for a small internet startup and founded London IA, London’s largest network of 1000+ user experience professionals.

Ken is a Kiwi by birth and his travel experiences have taught him to make the most of the beautiful country he lives in—he enjoys hiking, roadtrips, ultimate frisbee and cooking outdoors. His other professional interests include data visualisation, content strategy, business strategy and professional online communities.

Wine, Women and Song

Hello, Deutschland

“Wine, women and song.” That’s the short answer I tell people when asked how an American ended up in Germany. Either that or “sex, drugs and rock-and-roll.” Both jokes, of course. But it usually brings about a chuckle.

Actually, there were a lot of converging reasons for my coming to Germany and staying there. The most important was meeting my lovely wife. There was also the excitement of living in Europe: Prague, Oslo, Amsterdam, Paris—all a short flight or train ride away. And the European way of life simply appealed to me, particularly their orientation towards time. A saying I once heard sums it up well: in the U.S. you live to work; in Europe you work to live. Who wouldn’t want 30 days of vacation? Compared to the measly 5-10 vacation days you start with in the States, a month and half of paid time off is luxurious.

Work-wise, job prospects kept me in Germany as well. If doors open up, you sometimes have to take the opportunity. So the whole moving-to-Germany thing wasn’t planned at all: it just kind of happened. But in moving to Germany, I also found a career that matched my academic background, experience and skills: information architecture, usability, and, later, user experience.

Not that Germany is teeming with positions in IA or usability. It wasn’t then (and it’s not now). But I was fortunate enough to eke out a path that met my interests and allowed me to develop professionally.

This is a personal story recounting my move to Germany, the work experiences I had, and what I’ve learned along the way.

Searching For an ID

It was the summer of ’98. I had just sweated out a master’s degree in library and information science (MLS) at Rutgers University in New Brunswick, New Jersey (USA). At the time I was working at the university music library supervising the media desk at night and was looking to become a music librarian eventually. Working for a university is a good gig, after all. Good pay, comfortable working atmosphere, and the rhythm of college semesters: on again, off again, on again.

Still, even with a somewhat clear career focus, I found myself picking at existential scabs at the time. What if there’s more out there? Do I really want to consign myself to a fairly narrow career right now? So, before entering the tenured world of academic librarianship, I wanted one more summer in Europe: a final jaunt that would surely get any wanderlust out of my system, or so I thought.

Two years earlier—in 1996—I had taken part in the Rutgers summer abroad program for German in Konstanz, deep in the south of Germany, on the border to Switzerland. It was fantastic: a beautiful university city right on a gorgeous lake—the “Bodensee” in German, or “Lake Constance” in English—framed by the Alps peeking through in the distant background.

That’s when I started to learn German. I was really obsessed with learning to speak German at the time. I wrote a brief journal every day of what I did that day and went to informal “coffee talk” groups and the like.

So, after obtaining my MLS degree, I wanted to go back to Germany. The summer abroad program wasn’t an option again, and instead I searched online to find a summer job or internship of some kind. That’s when I came across ID Media, an upcoming web agency in Aalen—about one hour east of Stuttgart in the southwest corner of Germany. Not exactly Konstanz, but close, relatively speaking.

I sent an email off to them and, to my surprise, someone answered my request for a three-month internship as an HTML programmer. And off I went to Aalen to work at ID Media for the summer.

(Previously, I had learned some basic HTML at library school. Back then we were working in emacs, a primitive text editing program, writing code for the lynx browser, an early non-graphical browser. I wasn’t very good at it, but knew just enough to get by. Those skills still help me keep up with conversations on web development to this day. It’s important, I believe, to have a firm grasp of the medium for which you are designing, just as sculptors have to know about stone or bronze, for instance. Or, I have a friend who spent a summer framing houses while studying to become an architect in order to have a better sense of how things get built. A web designer without knowledge of HTML—the main constructive material of web UIs—lacks necessarily skills to design properly. But I digress … )

The atmosphere at ID Media was electrifying—young, creative people looking to do nothing less than reinvent the then burgeoning digital, online world. There was a real sense of innovation and trail blazing.

Interestingly enough, the office itself was in a small village outside of the center of Aalen called Forst, which probably had about 100 residents. And right in the middle of this village was a group of wild, creative web designers. Pretty interesting contrast.

ID Media became this cult-like enclave deep in the heart of the Swabian Alb, the region of Germany surrounding Aalen. (The Swabian people, by the way, have their own dialect and culture. It’s a fairly traditional region of Germany with a strong sense of history and pride.)

The ID team—then probably 60 people—was very closely knit. We worked hard together and partied even harder. The famous “Pauli’s” were all-out drink fests held in the office at night. People ate together, pooled cars, and shared flats. As a result, ID Media back then was at times like a single-minded organism.

Work-wise, it was totally chaotic. Though there was strong, visionary leadership from digital media guru Bernd Kolb, there was little structure to the teams and the projects. A very flat hierarchy and a high degree of transparency was the norm. But the strong shared sense of vision somehow magically kept things on track. Sure, mistakes were made. Sure, people worked through the weekend because someone else screwed up. But by and large, we were totally psyched about the work we did, and we were proud of the results most of the time.

Two projects at ID stand out as the ones which extracted the maximum out of us, though there were many others. The first was Beetlemania. For the introduction of the New Beetle into Europe, VW contracted ID Media to stage an event—one that was to combine online and offline aspects. Our idea was to stage a scavenger hunt across Europe.

Here’s how it worked: contestants were put into teams of two. Each got a New Beetle, which they had to drive through Europe to collect clues and artifacts that led to the next destination.

Now comes the interesting part: online communities solved riddles and found information, which they fed back to their respective driving teams via wireless laptops in each Beetle. The answers to the scavenger hunt challenges were in effect crowd-sourced by the online teams, who really directed the drivers along their journey. Keep in mind this was 1998. Many firms would have a hard time conceiving, coordinating and implementing such a grand-scale effort today, 12 years later. I didn’t really play a major part in the development of the concept or the implementation of Beetlemania—I just cranked out some of the pages in HTML, as well as translated some of the riddles to English. Still, for me at that time it was both thrilling and educating to have worked on the project.

The other big project was an ongoing one: Cycosmos, a service that ID Media created itself. Cycosmos was a full-fledged online community with customizable avatars and 3D chat rooms. Discussion groups instantly sprang up around a variety of topics and hobbies: travel, sports, business, science or just watching TV—you name it, Cycosmos had it. Accompanying Cycosmos was a virtual “rock” star: E-Cyas, a virtual personality. At its peak, there were reported to be 100,000 users in Germany. ID worked hard to convert this huge online community into profit, and there were lots of interested business partners. But ultimately, the business model part of Cycosmos led to its eventual closure, despite a growing number of users. There’s no doubt about it: Cycosmos was very progressive at the time. It even foreshadowed Second Life, predating it by five years.

Beetlemania and Cycosmos are just two examples of the type of forward-looking projects ID Media engaged in. There were many more, including other community-based solutions for clients, innovative uses of Flash applications to push content to users’ desktops, forays into interactive TV, 3D modeling teams, and participation in the development of Swatch’s internet time. (The latter was a way to measure time without time zones. Minutes and hours were replaced with “beats” or a division of a day into 1000 equal time units.)

Web 2.0 for the rest of the world was Web 1.0 for ID Media.

And that’s what attracted me to them, I think. It was eye-opening in many ways—in terms of web development processes, working in teams, and being creative. What’s more, there was never a primary focus on technology. Sure, you need technology to implement your ideas. But the starting point for just about every project was based on questions we asked ourselves, like: “How can we connect online and offline experiences?” and “How can we forge a community here?” It was about connecting people and creating meaningful relationships that, in the end, would bring our clients’ value to their businesses. It was precisely this type of deep, reflective pondering about people—their desires, needs, and emotions—that was fundamental to the vision of every endeavor at ID Media.

The flat organizational structure also allowed for many freedoms. My role at ID Media quickly moved from HTML programmer to assisting in new business development, primarily through research, competitive intelligence, and pitch preparation. Not exactly your typical job move, but one that suited me and my interests better.

A Bigger Fish to Fry

My stay in Aalen only lasted about 10 months. ID Media then opened an office in Hamburg, to which I was promptly relocated. That was March of 1999. The Alb region proved to be too provincial after all, and the thick, southern accent prevalent there—which seemed cute at first—complicated my ability to understand the locals. Hamburg, by contrast, is a large city—the second largest in Germany—and fairly open to foreigners. They also don’t speak as if they have a sock in their mouths like the Southerners do.

ID Media continued to grow rapidly in a seemingly uncontrolled manner, contributing to an even greater sense of general chaos. This drained the energy from the team and changed the company spirit. We were still creative and innovative, but the general bedlam that pervaded daily work was unbearable to some. I even remember a new employee in Hamburg quitting after one day because he couldn’t take the disorder. Key people also started to jump ship: the frustration was just too much for them, or they found better offers elsewhere.

Nonetheless, the company continued to grow in numbers (though not necessarily in maturity), and my role continued to expand: it now included usability and user research. That was really my first contact with design-related aspects of web development. The whole scene really appealed to me—Nielsen, Spool, the Polar Bear Book—and I dove into the subject head first. The team became a half a dozen people solely devoted to usability and user research, as well as competitive intelligence and strategic support. There was hardly a model for such a group inside ID Media or outside, so we essentially made up our own charter and mission, as well as creating our own set of deliverables and tools.

But the stress at ID Media eventually got to me too. I was ready to move on, despite the fact that the company was still successful.

At the time, there were many newly-established online media agencies in Hamburg—some small and some large. Icon Media Lab and Razorfish belonged to the latter, and I thought a larger, international organization would be a change for the better. Icon Media Lab turned me down, but Razorfish gave me a chance.

At the beginning of 2000 I switched to Razorfish, where there was the role of Information Architect (IA). Actually, at the time it was called Information Designer, but that changed eventually to IA. With a degree in library and information science behind me, the field of IA really felt like “home” to me in terms of a career choice. I was able to combine my academic understanding of information structures and information behavior with the practical experience in web development and usability I gained at ID Media.

It was the height of the dotcom bubble. Razorfish stocks reached an all-time high—over a $100 per share. The stocks then split. We had a ton of cash and a ton of business with larger, international clients. Exciting times, indeed.

Razorfish was represented in about a dozen cities around the world, and it, too, was a rapid growth organization. And just as in many other rapid growth organizations, chaos quickly set in. But it was a different kind of chaos than ID Media. At least there was an attempt to address disorganization in general with constant re-orgs. There were also global frameworks Razorfish relied on, such as with branding, team structures, and job roles. But those attempts couldn’t keep up with the expansion rate of the agency at the time.

The international network of work colleagues was fantastic. It deepened my IA skills immediately. I was fortunate enough to work with people like Liz Danzico, Karen McGrane, and Victor Lombardi in the U.S., as well as Peter Bogaards in Amsterdam and other leading European IAs at the time.

Like ID Media, Razorfish had a strong focus on user experience. Both strategy and user experience were our main service offerings and competitive differentiators. Projects always began with an elaborate conceptual phase to nail down the vision of the intended user experience. Teams were unified around a common understanding of the desired outcome.

Razorfish had a very unique culture as well. We were a family bonded by both work and play. Looking back on Razorfish in Hamburg, I recall that it was also quasi-cult-like in some ways—like ID Media—with a range of unique signs, symbols, and shared references. For instance, the term “fish” referred to any Razorfish employee, leading to clichés such as “flying fish” to indicate a visiting coworker from another. Bags, hats and t-shirts branded with our logos and colors abounded and were worn with pride. Don’t get me wrong: we weren’t drinking the Kool-Aid of a mad leader. The culture was strong, but never over the top.

The dotcom bubble soon burst, and the company went into a tail spin. Razorfish had three locations in Germany at its height, with over 80 people in the Hamburg office alone, where I was. The numbers dwindled even more rapidly than they grew. Within a year there were only about a dozen of us in the Hamburg office. That’s when I heard the term “pink slip” party for the first time: people celebrated getting canned. It was kinda like pulling out a lounge chair on the Titanic to watch the thing slowly go under. The majority of the fish were young, and moving on professionally was not unusual either in those days. Not that anyone really likes to get fired; in many cases it just wasn’t a surprise when it happened.

It was the beginning of the end. But the management struggled and contrived to keep the boat afloat. Razorfish then split into Razorfish US and Razorfish Europe, which meant we were competing with our former American colleagues for some accounts. That didn’t last long either, and Razorfish Europe split further after shutting down many office locations completely. Left over were Razorfish Germany and Razorfish Amsterdam.

Razorfish Germany then went bankrupt, but was kept alive in a new company form. The Frankfurt office closed, and the company was managed from the Munich office. We were now only three people in Hamburg—two IAs and the Design Director—forcing the company to conduct projects virtually. The centrally located downtown Hamburg office—also famous for its monthly parties, by the way—was forced to move, and the remaining trio of fish shacked up in a shared office space of another much smaller digital agency in Hamburg.

Not only was all the magic gone, it was embarrassing for the once leading agency in Hamburg to have its office in a corner of the office of a B-level agency. Our fancy quarters with an all-glass conference room (called the “fish tank”) and exposed brick walls were gone, and we now sat in a drab warehouse in the middle of an industrial area of Hamburg.

The multi-million dollar accounts also dried up in a wave of über-conservative client spending that the dotcom bust wrought on online industry, and we found ourselves pitching for the smallest of projects. Razorfish went bankrupt again. Though the management wanted to keep the company alive in yet another organizational form, I’d had enough.

That was the spring of 2003. Coincidentally, an ex-fish colleague contacted me and asked if I’d like to take a position with LexisNexis. Of course, as a student of library and information science, I was very familiar with LexisNexis, one of the leading providers of legal information for professionals and a true pioneer of online database searching. So, I didn’t really have to scramble to find a new job—it found me. Good timing.

The Missing Nexus

In April 2003 I started at LexisNexis. Since I’m still there, I don’t want to get into hot water with my employer by revealing too many gory details here. Suffice it to say that the experience has been much different from what I had at ID Media and Razorfish.

LexisNexis is a large, traditional organization. It has been providing online information to legal professionals (e.g., lawyers, paralegals, etc.) for 40 years. It’s a multi-million dollar company in the multi-billion dollar industry of legal information publishing. LexisNexis has over 13,000 employees around the world.

Not surprisingly, a fairly deep management structure is ingrained in the basic DNA of LexisNexis. And I landed at the very bottom of this structure, in an engineering-led product development department. The user experience team was small when I started, and it has since grown. Our reach and influence is limited, even to this day, at least compared to ID Media and Razorfish, where design and user experience ruled the day.

There are advantages and disadvantages to a large, traditional organization. On the plus side, the overall business is fairly stable. Salaries and benefits are generous. LexisNexis is also a truly international company, which means I can work from my home office in Hamburg, supplemented with considerable travel. (I recently did a short stint in our Sydney office, for example—not too shabby a place to get sent for work.) And of course, the network of colleagues worldwide provides a source of energy and inspiration as well.

On the downside, the weight of the hierarchy at LexisNexis proves to be crushing much of the time, particularly for creative design activities. Innovative ideas, no matter how small, get squeezed through layers of filters for “approval” and come out the other side mangled beyond recognition, thereby squashing out any inkling of the original vision behind the idea. It’s quite a sober atmosphere, for sure.

Suffering from this weighty structure and, at times, political subterfuge is creativity and design innovation, I believe. While ID Media and Razorfish bathed in out-of-the-box thinking, LexisNexis usually prefers to take a safer path. Pushing the boundaries of what’s possible is simply harder within such organizations as LexisNexis.

A Broader Field Vision

So after over a decade of professional experience in various types of teams and companies, I’m left asking myself, is there a relationship between organizational rigidness and creativity? Do chaos and transparency breed innovative outcomes? My personal experience of moving from ID Media and Razorfish to LexisNexis seems to suggest so.

More importantly, I feel that at ID Media and Razorfish, both at the company level and on each individual project, the sense of a common mission was the real driver of our creativity and innovation. Perhaps personal relationships aren’t the best for a working environment, but those common bonds were missing for me at LexisNexis as a whole.

So how can something like user experience design have a chance to make a difference or even survive in an organization like LexisNexis? This is an interesting challenge the user experience group at LexisNexis faces. And we’re working on it, brick by brick, trying to change stagnant mindsets and make a difference. Other such companies face this challenge as well.

The answer, I believe, lies in a strong shared vision. Unless you have a “Steve Jobs” at your company, a vision needs to be actively forged and nurtured along the way. Creating a vision, however, doesn’t just mean creating a vision statement after a couple of minutes’ thought and moving on. A vision should be something that is alive, and it should pervade every action of every employee and guide their thinking in general. It has to be a clearly and widely understood ethos across teams and departments—a veritable way of life.

Grass roots efforts to craft a common vision are necessary, but only get you so far. There has to be support from above, ideally top-level management support. By definition, you can’t have a partial vision or a vision that applies only to some but not others. The common cause must be holistic and overarching, pervading all levels in the company.

Apart from getting a shared vision, I also have two other general recommendations for people working in large organizations. First, be patient. You’re not going to change things overnight. Fighting town hall directly can be futile, leading to even more frustration. There’s also a tendency to think the grass is greener on the other side of the fence. But don’t jump ship too soon: wait for the breaks—they will come slowly.

Second, be flexible. The vastly different company cultures I’ve experienced required me to be highly adaptive. Likewise, living in a foreign country has also given me insight into different national cultures and increased my ability to adapt to different situations—or at least I’d like to believe so.

Something that kept me going was information architecture and user experience, as broader fields of investigation. These professional communities provided the stability I needed during more chaotic times, and they also supplied inspiration and creativity to contrast the stifling structure of LexisNexis.

Just as I didn’t plan moving to Germany, I also never really planned a career in information architecture or user experience. My path from librarianship to creative digital agencies to the corporate world was not at all expected when I first came to Germany. There were many times of uncertainty—uncertainty about my career choice and about my future. Several times I was very close to packing everything up and retreating to a life of academia in the US. But I adapted as needed and kept plugging forward.

And that’s the key, really: being able to respond and react to situations as they arise. Sure, being pro-active is something you should strive for. We’d all love to work for organizations where Design (with a capital “D”) is an integral part of the business strategy at the highest levels. But that’s rare. So in relatively young fields like information architecture and user experience, flexibility and adaptability have to be part of your professional DNA—on a daily basis as well as for your career as a whole.

About the Author

James Kalbach is a User Experience Consultant with LexisNexis, a leading provider of legal and news information, where he develops interfaces for web-based search applications. James previously served as head of information architecture with Razorfish, Germany. He holds a degree in library and information science from Rutgers University, as well as a Master’s degree in music theory and composition.

For the past five years, James has been on the organizing committee for the European Information Architecture conferences. Previously, he served on the advisory board of the Information Architecture Institute in 2005 and 2007.

He is the author of Designing Web Navigation (O’Reilly, 2007).

Web: www.experiencinginformation.wordpress.com

Twitter: JamesKalbach

Facebook: James Kalbach

Chapter 2

“The first step in making rabbit stew is catching the rabbit.”

Isaac Asimov

Almost Dead on Arrival: a Tale of Police, Danger, and UX Development

How We Got Started

It is not often that the lawyer for a prospective client, that is heavily armed, calls us in for a new project. Starting off with lawyers and police, we were already on alert. Still, we anticipated that this job would be different, challenging, and perhaps dangerous. It happened about five years ago.

The lawyer (for the policemen’s union) explained that the police department of a major Silicon Valley city was rolling out a new mobile information display system, but they were running into problems. The police officers who had to try the new system found it problematic, sometimes refusing to even use it, because they said it might endanger their lives. What a customer or user reaction! As we learned more and more about the context, the application suite, the software developer, the threads of politics, software development and organizational behavior became more and more intertwined. We felt like we were detectives ourselves, trying to understand how things had come to this situation; that the police officer’s union (which hired us) was about to sue the software developer, the police management, and the city for creating a fiasco. The newspapers were also beginning to sniff around.

It turned out that a police management group had set up a committee to consider whether to renovate their decade-old communications software that linked dispatchers to all the mobile police force in their cars or to their personal communication devices, or to abandon their previous software vendor and purchase off-the-shelf products and integrate them into a new system, a more modern one that knew about the Web, recent mobile devices and improved information display. Ultimately, they decided to interview software vendors and selected a provider of police information management software.

All might have gone well, were it not for several unfortunate circumstances. On the team considering the requirements of the new software, there was not a single person from the actual officers, who were the users, only management—people who had once been officers but were no longer in cars and on the streets. Consequently, they did not get actual user-input when setting up the vendor requirements. Also, the team did not know about usability and user-experience development concepts and likely issues. They did not know to establish user profiles, personas or use scenarios. The users were not involved in the vendor interview process. It seems clear, in retrospect, that the team that decided on the primary vendor asked the vendor about functionality, not usability, and, of course, the vendor was enthusiastic about the capabilities of their product, offering to provide what the team was proposing. Little, if any, discussion of usability issues probably occurred.

With hindsight, it would have been good to know if the selected vendor was already being sued by another city’s police officers for the software they had provided because of some usability problems. This seemed to be the case, but the facts did not come to light until much later. In retrospect, it seemed possible that the vendor was marketing a product designed originally for small corporate police forces with little or no “crime action” to big city police forces that placed many demands on the software.

So, now it was show time, and the new integrated system, when it was rolled out, crashed. No matter, eventually the vendor team at police headquarters got the software to work. But there was still the issues of officers not being trained on actual working equipment, being trained with too little time, and their having problems using the software. The city had already spent $4 million dollars on software development at this point. That was when we were called in, months too late, but better late than never.

Late, But Better Late Than Never

We proposed interviewing some of the users to see if the problems they were having were really issues of the software user-interface, or problems with the capabilities of the officers (which would originally have translated from user profiles to different user-interface designs). When we interviewed a half-dozen people, we discovered that they were actually relatively well educated, experienced with PCs, and quite articulate about the problems they were facing.

Based on the interviews and our own observations of the software, we determined more than 20 significant usability problems. They ranged from poor color choices, poor layouts, hiding significant data in the middle of other non-essential data, certain interaction details, and, in general, the challenges of using a Microsoft Windows PC paradigm for a computer system that was installed in a police car, in which the user would really need to operate the system as if blind, using their hand, while the officer’s eyes were trained on the environment ahead.

For example, an officer might have to keep watch on a pulled-over car ahead, in case the driver tried to reach for a weapon or toss something important from the car. After entering the car license plate into a data system that determined if the car was already known as stolen or suspicious, the information came back to the PC display in a small window that showed other information that was essentially useless system messages stating that the system was operating OK. The officer could only glance quickly at the display, looking for the important message needed: OK or Danger. Alas, the displays were not well designed for this purpose.

In another problem, the map displays would lose track of cars in a group of officers because the car happened to move into another district managed by a another group leader and would become invisible to the officer’s own group leader.

These Were Not Happy Users

At first the software vendor was very hospitable to us, even inviting us to travel at its expense to its corporate headquarters to meet with their development team. Later, after our report criticizing the software was released and was shown to members of the city’s government, and after articles began to appear in national newspapers about the crisis and its gathering legal storm clouds, the software vendor was less friendly towards us. The vendor told the police department that it would be happy to make changes but it would cost more money. The vendor’s local team was not very cooperative at first, but then a company executive visited, probably noticed the bad publicity the situation was causing, and replaced the local team, which then began to cooperate with the police department’s development team.

So, How Does the Story End?

Eventually the software was “fixed,” at least as far as we know. The eventual cost was several more million dollars, which brought the total cost back up to about what the vendor of their previous software (which was much used, much improved over the years and much more familiar to the users) had said it would need to radically revise their previous version. The police department’s attempt to save money by using “off the shelf components” had not gone well.

What was noteworthy to us about the entire project was that the original team, which sought to find the best solution, did not know what they did not know. What they lacked was an advisor on software development who was experienced with the usability and user-experience profession and the appropriate user-centred development process that emphasized such matters as the following:

1. Development of user profiles and use scenarios

2. Development of clear understanding of all stakeholders

3. Involvement of stakeholders in the development process

4. Contextual analysis, ethnographic analysis

5. User interface components: metaphors, navigation, mental models, interaction, and appearance

6. User-experience dimensions: usability, usefulness, and appeal

7. Cognitive walkthroughs

8. User testing

9. Iterative design

All of these concepts and techniques are well known in the usability and user-experience professional community. Alas, they were virtually unknown to the members of the police department’s information technology group. If they were known to the software vendor, they were not promoted as such. After all, such matters probably would just get in the way of a quick sale and quick development process.

By the way, in the course of our project, we also had occasion to talk with the dispatchers, the specialized professionals on the other side of the communication link who would direct officers to a scene of a crime or gather key information from them and disperse it to other officers. These users had their own high-performance, multiple screens and a different suite of software. They, too, were experiencing usability problems. We did not even get to interview them or work with them to help solve their challenges. That is another UX bedtime story for another time, boys and girls.

This particular police department was a fairly sophisticated one, but it, too, became trapped by not being aware of user-centred design best practices. All over the USA, and probably elsewhere in the world, other police and security forces are attempting to upgrade their software systems. Many of these groups are probably equally unaware of user-centred design and its professionals. It seems that the usability and UX community has a tremendous opportunity for outreach to these people who want and need help.

So ends the story. This one had a somewhat happy ending, but it raises troubling thoughts about what needs to be done to improve the situation in general.

A complete case study of this project can be found here.[1]

About the Author

Mr. Marcus is the founder and President of Aaron Marcus and Associates, Inc. (AM+A). A graduate in physics from Princeton University and in graphic design from Yale University, in 1967 he became the world’s first graphic designer to be involved full time in computer graphics. In the 1970s he programmed a prototype desktop publishing page layout application for the Picturephone (tm) at AT&T Bell Labs, became the first designer to program virtual reality art-spaces while a faculty member at Princeton University, and directed an international team of visual communicators as a Research Fellow at the East-West Center in Honolulu. In the early 1980s he was a Staff Scientist at Lawrence Berkeley Laboratory in Berkeley, founded AM+A, and began research as a Co-Principal Investigator of a project funded by the US Department of Defense’s Advanced Research Projects Agency (DARPA).

He is the Editor-in-Chief Emeritus of User Experience (UX), an Editor of Information Design Journal, and was a regular columnist of Interactions for five years. He is also on the Editorial Boards of Visible Language, Universal Access Journal, and the International Journal of Human-Computer Interaction.

Mr. Marcus has written over 250 articles and written or co-written six books. He has published, lectured, tutored, and consulted internationally for more than 40 years and has been an invited keynote speaker at conferences internationally.

Web: www.amanda.com

Twitter: amandaberkeley

[1]. Marcus, Aaron, and Gasperini, Jim (2006). “Almost Dead On-Arrival: A Police Emergency Communication System.” Interactions, 13:5, September-October 2006, pp. 12-18.

Moving into Non-Linear Iteration and Managing People Who Haven’t Arrived There Yet. Dave Malouf

Have you ever noticed that all stories are really sub-stories of a bigger story? There is no true beginning and there is no true end. Really great stories actually begin to develop their back-story in fuller depth as you move forward through the part of the tale that the teller wants you to focus on. As I begin to write this story, I’m struck by this same problem. Where exactly does the introduction start and where does the conclusion end? Through the iterations of this very paragraph I have started and restarted a host of times. At some point, you just have to throw the proverbial dart at the screen and let it fly from there: Design.

That is my introduction to how I learned about iteration as a primary concept and tool for design. Of course, even the simplest story is strewn with nuances and sub-themes and hopefully a few of those will rise to the top as well.

HTML: The Gateway “Drug” to Design

Not to go back too far, but my entire career up until the real beginning of this story has been a passage from side to side, or one of trying to balance between. Whether starting out as a right-wing Zionist and finding a home as a progressive, or going back and forth between New York and California so many times that even I have lost count, I have always bounced, or more accurately, made the extreme decision. I was never a moderate by any sense of the definition. In my professional life, there is no difference here. I started out as a technologist; dubbed a designer by those who didn’t care what design really was. I coded HTML, which in 1994 put you squarely in the center between design and technology (and it still does), but from what I can tell, in a new way. As the industry matured and more people from varied backgrounds (read formally educated) entered, there was more and more pressure on me to decide. Am I a right-brained technologist or a left-brained designer? Neither felt right, so I was constantly pushed from one to the other, or sucked into the middle as a project manager or producer. To be honest, this is still going on, as you will see later.

Vizooal: Entering the Design Studio

In about 1998, I entered a small studio called Vizooal in New York City. It was run by two really smart guys. One was a shrewd businessman with tremendous management talent, while the other was a great designer, mainly from the print world. They had something special to offer their clients between the two of them. What they were missing was the middle, so to speak. This yet-to-be-defined (will it ever be well-defined?) role where business, technology, and end-user are all translated and re-translated, so that everyone and everything understands in perfect detail what the other is saying—towards the goal of the technology building a product that derives a value that the business can sell to human beings who want to accomplish or experience stuff. There are many paths to this role, and in 1998, there was no formal education in it, for sure. But I jumped in with both feet, neck deep the moment I was asked the question, “Do you want to be the project manager or the ‘information architect’?”

All I REALLY knew about information architecture was that there was a book with a cute bear on the cover about it from some Library School in Michigan. By the way, I worked in the library in one of my previous careers. That seemed to be good for me! With that, a new career was born. I fitted into the role nicely because I have a good sense of direction (which really matters), spoke a few languages really badly, (but at least I tried), and seemed to have the ability to ask the right questions over and over again, until they are answered the same way. In previous roles at other organizations, I did wireframes (we called them storyboards), and I was known for designing user interfaces.

Vizooal was not the first place I worked directly with formally trained visual designers, but I will say it was the first place I had the opportunity to collaborate so closely with them. An open studio helped for sure. It was new, different and, well, foreign. Things that are foreign are different and very hard to map against our natural ways of thinking. For the remaining two years of my time at Vizooal, I never really understood what I was seeing, but I was very attracted to what I saw and intrigued to learn more.

At the end of those two years, I can say I learned the following points about the value of the creative studio environment:

1. Transparency: the more your work was visible in process, the more your peers can enter your design process in fundamentally empowering ways.

2. Openness: imperfection is an invitation towards participation, and being open to listen is the kindling to allow for collaboration.

3. Informal and formal: There was a clear separation of work for client vs. work for you. This meant that you knew you were creating artifacts that the client would never see. These could be sketches, or could just be directional explorations.

4. Non-linear: Nothing gets thrown out. Everything past and present is a point of reflection through the iterative process.

5. Abductive reasoning: Envision the desirable and deconstruct that into the possible and desirable.

Fast Forward to 2003

After living in the deep suburbs of the East Bay Area of California for two years, working tightly as a “UI designer” in a completely technology-focused organization, I started to miss that mysterious thing. The year before, I had attended some collaboration sessions between AIGA (graphic design professional association) and SIGCHI (researcher professional and academic association). That experience threw me for a loop. Almost a full year later, the culmination of that meeting led to a conference called DUX2003 or Designing User Experiences. For the first time, people all over the map of user experience were brought together without any sense of tribalism. I felt lucky and privileged as an “almost nobody” to be presenting on stage next to people I held in such high esteem from all over the world. There were many pieces of that experience that stuck with me. They definitely pushed me deeper towards seeing that I was not a complete designer, and possibly I was not a designer at all. In 2003, while I was leaving California and moving to New York City, I knew in my heart of hearts that I was not a designer. I never practiced anything like design and didn’t even really know what design was.

Fortunately, right at the center of this realization was the formation of a new community of practice—IxDA (Interaction Design Association). In taking on a role of leadership in this organization, I gained access to some amazing people. Some were designers, classically trained, coming from graphic, multimedia and industrial design. Some were not. These people all became mentors to me. They all taught me and engaged me in new ways that I didn’t feel possible in other organizations at other times in my life. But again, these designers started to clarify things for me. So as I began my new life as a Manager of UX, I knew I had to bring on people who were designers (which I did) AND I had to start educating myself on what design really is all about.

The subject of Industrial Design came up a lot in IxDA. I noticed that more and more of my peers were talking about Interaction Design and Product Design as much as a close coupling as UI Design and Visual Design. Inspired by this, I took two courses at the Pratt Institute of Design. They were Product Design and Drawing for Product Design. These 8-10 weeks were some of the most profound in my career. Now I understood it, and I knew how to talk about it. For the first time in the 5 to 6 years since I entered the world of design, I finally reached the level of understanding.

So many people in the UX community got through much of their careers building their knowledge as they went through. They worked through a system that barely ever understood what it is they did, how they did it, and quite honestly, beyond buzz, why they were needed. This got tighter after the bubble, but many were fabulously productive additions, with deep understandings in parts of the processes they were engaged in. Like myself, I knew Information Architecture, User Interface Engineering, and Human-Computer Interaction really well. What I didn’t understand until now was design process; I knew that I had to go out and learn design process and the language of visual communication.

The True Essence of Design

So, what did I now understand?

1. That making is a vital part of design (although I didn’t yet know why!)

2. That good craft is a key part of communicating ideas.

3. That good ideas are not born out of divine conception but are forged and carved repeatedly in a crucible of specific processes.

4. That design has been doing UX all over the world before a computer was ever sold to a consumer (they just never called it that).

5. Sketch ... Sketch ... Sketch and sketch some more!

6. That valuation using analytics and metrics is only one path of evaluation. That there is critique based on experience as opposed to experimentation.

7. That aesthetics has a language, and that language can be transferable to any medium, including interaction.

I was so excited. I was like the Zealot who was spoken to by G-d him/herself. So, with this back story, the real story begins ...

Rewind a Little

I arrived at IntraLinks, my newest employer, in the summer of 2003. In the role of Principal UX Designer, I made it clear to them that what I saw in their current offering was pretty disappointing and that I really wanted to change the application from the ground up. Since this is not a case study but a story, I’ll just say that their existing application was just really bad in all the obvious ways. We ran some usability tests on it a year after I got there (it took that long!) and it was hysterical. Die-hard users for years would not be able to complete core tasks, but when asked what they thought of it, they said it was great! This really confused our stakeholders, but it was just a small part of the story to come.

When I arrived at IntraLinks, they had an existing application platform with a solid user base. There were signs of User Centered Design (UCD) practice from my predecessor in the form of personas, and there was a very open attitude, and even agreement, that considering and observing users is an important part of the process. A year after I started, I learned that they even hired a usability testing group to do tests on their applications. I never actually saw those results. At the end of the first year, my role, if not my title, had decidedly changed to that of managing the user experience team.

Life in the Trenches as a User Experience Manager

So with a heavy heart and a growing team, at the same time I had to manage the day-to-day feature creep of a completely over-extended platform. We were asking it to support more and more markets that it was never intended to be used for. There was just a tidal wave of square pegs that only had round holes to go into.

During this process, my only access to user data was through secondary contacts. Not ideal, but a reality. The sales teams were very protective of their clients. What was worse was that the clients were not the end-users. This was an enterprise system that was purchased by a manager who would probably never be the primary user of the system.

The team of three was completely overworked on the feature creep and new market additions that were being demanded of us at a very rapid pace. We were doing major upgrades three times a year. We had three different projects at different stages running in parallel at any one time. We were not using any agile methodologies (yet). Once more, the development team was a few hundred miles away in Boston, while I was in New York City.

One of our markets was at a crucial stage of development. We were also learning that this market had significant cultural, workflow, and even core process needs that we were deeply struggling to make fit within our existing system. The group began taking me and my team on site visits. This was “allowed”, due to the vastly different culture in this new market segment, compared with the previous core segments. The product management and sales teams knew that the existing flat product would never be able to satisfy this emerging market. To better engage their clients, they needed to present a face of forward thinking and future improvements. This allowed the stakeholders engaged in this market to open up and include the user experience team.

The goal of these visits was to create a prototype of what an application would look like, specifically for this market. Basically, I was asked to design something from scratch. The data sources were very limited, so I drew most heavily from my insights from previous research that I had done at my former employer, dealing with similar issues in the same market space, but on a different part of the process. In fact, part of my new task was designing possible integration systems between my old employers and Intralink.

This was an opportunity to include as many stakeholders in the design process as I wanted to promote for the entire organization. But again, time was limited, so only the most necessary parts of the process were employed:

1. I developed three concepts in low-fidelity

2. I presented the concepts with heuristic analysis against the research data of the limited site visits

The concepts were well received and nothing was done with them. It would have taken too much work on the core platform to develop the concepts. However, it created two conversations. The first was around the feature set, what really made sense for that market, and how to implement the features within our existing platform, if at all possible. The second was that there was a realization of greater synchronicity between the existing markets than originally thought, and that if the platform was rebuilt based on these newly observed patterns, we had an opportunity to create an incredibly extensible platform for all our markets and then some.

Emerging From Darkness, User Experience Success

So, whispers of a grand redesign started going around the product team. Lots of meetings were attended and heavy planning was done behind many closed doors, including my own. One day, I went and told the boss that we needed more information about our users and how they are really able to use the existing application. We needed this for two reasons. The first was that if we were going to do a redesign, we needed to have a baseline understanding to be able to measure success. The second was that to begin doing designs, we needed more real world insights about the users of the system, across all the targeted markets that we planned to deploy within the next three to five years.

We hired an outside user testing group. We put out an RFP (request for proposal) and after evaluating five groups, we chose one based on price, which could not be ignored. However, it was a group that had a clear plan for how they would deliver, based on the RFP. We decided to go outside for user testing, because the internal team was too close to the interface to be clear in their critique. Furthermore, due to the rampant complaining within the entire team, including myself, for the last two years at this point, we had lost a bit of credibility, and it was agreed that a third party would help bring that back to the group. I had no problem with that, because quite honestly, I was very confident in how the results would turn out.

The tests took place over three days with five 50-minute tests per day. We did the tests in Manhattan, a short cab ride from the office and invited, begged and pleaded that key stakeholders would come to the tests, especially from product management and sales. Product managers showed up, but few from sales did.

In my opinion, the tests were a huge success. The usability testing organization provided the exact insights that I had described in previous reports, just using my own judgment. It was a huge win for me and the team and was filled with rich data for how to move forward with a major redesign of the system.

Our first task was another concept design for a market specific feature area. It was the right area to get our juices cooking on one of the most complex areas of the application. By providing prototypes around this very complex feature, we learned a ton about the foundational object model, the metaphors and the action sets that would be at the core of any new redesign project. It also was an opportunity to demonstrate the use of a multiple-concept-approach to the organization, who were more used to getting one idea and running with it.

Unlike last time, different players each worked on different concepts, but also collaborated as assistants on their peers’ concepts, as in the studio environment. We even took advantage of moving to a new space where, instead of facing walls, we all faced each other with no walls between us. This led to filling the space with constant reviews, critiques and cross-fertilization of ideas. Each concept, though, was given a specific design direction, based on a focused goal. Imagine designing a house from a single point of view: sleeping, food, entertaining, etc. While the application was broad in its functionality, I wanted early concepts to be focused on a specific aspect of the market’s workflow.

As these early designs started to come together, again it was clear that they could not work without a major revamp of the core platform of our application. This redundant cry from development was finally starting to be heard by the executive staff, who then started a small skunk team on a feasibility project for a complete redesign of the platform.

Now looking at all markets, the design team had to figure out how to communicate to engineering what was needed in a new platform, so that the engineering team could begin doing their research. Again, two designers now started working on three different concepts, each with a design brief of its own.

As a point of historical context, both Vista and Office 2007 were on the horizon and Microsoft was publishing a lot of information about their user experience designs. They supplied rich information with lots of data. This began to heavily inform some of our design decisions, because if this application was going to last five years without a major redesign, in order to recoup investment costs, we needed to be looking at the conventions end-users would most likely be seeing in that time frame and beyond. While this story is not about design critique, but more process critique, I will just say that this may have taken too much of my attention to the detriment of the product.

So three designs were put in front of the stakeholders. It was very clear that one of the designs was a solid winner. While there were issues, there were significantly fewer of them. The other two designs were not nearly as appreciated and quite honestly were way too rough to evaluate fairly.

I learned two things during this phase of the design process:

1. Wireframes cannot be used for interaction design decisions. The lack of behavioral fidelity and context of use in the presentation of wireframes led to people focusing on the wrong parts of the design.

2. For myself, it was a kick in the pants to better pay attention to visual details in deliverables, regardless of fidelity, as mistakes are distracting and cause confusion in the discourse about the designs.

As a next step, I decided we would combine the two problematic designs with an iteration based on lessons learned, and take this new design out to the field. I learned later that this decision without proper team explanation or inclusion was the beginning of my downfall, but also led to the success of the project.

So we took the designs and iterated on them and beefed up the fidelity with a crisp visual design. We then put that design in front of some 100 end-users across four of our primary markets, in four key global regional areas: NE Corridor, San Francisco, London and Frankfurt.

The primary method was in the form of a focus group. While there are certain dynamics that make focus groups less than ideal, there was one aspect that I wanted more than any other. Our user base included two sides of the business process that never really considered the other’s use of the application before. So, by creating some groups that were mixed, I was able to have these groups engage with each other and reach their very different points of view. What ended up happening was the creation of tiny crucibles, in which new ideas were formed that would have never happened otherwise.

The feedback on the new design was not exactly disappointing, but was more negative than many would have liked. But me? I was excited, because what I got from this set of data was even more data that supported key areas of this design. More importantly, there was even more support that the previous design still had tremendous value. What I ended up with, however, was strong support for key features in the new design that would have never happened, if we had not gone through this process of looking at the tangents before focusing on the center.

After the presentation, we began working hard on new ideas for how to combine the designs. One thing that made a big difference was looking at newer sources of inspiration than previously. This enabled us to consider new visual patterns, while maintaining the interactive patterns that they were communicating. We increased scalability across both designs and brought the object model of the new design to the navigation model of the old design.

During this stage of the design, we did more than create visual comparables. Rather, we created a full interactive prototype. We even hired a contractor as part of the design team to build out every visual composition into this interactive prototype.

Through all of this, it was clear that communication between the internal stakeholders was not going well. We decided to create a space where the stakeholders could work in teams around core pieces of functionality. We would work with one product manager, one designer, and one or two developers, making up a team for a market segment. Then we would create mockups that were converted into a live prototype the week after, to be reviewed and possibly iterated on. It was a rapid custom agile method that seemed to be working for the team in order to close the communication gaps that were causing problems previously.

Towards the end of the design phase, my team disappeared out from under me. One left the organization and, upon inquiry from Human Resources, the other main designer let them know that he was dissatisfied as well. The organization removed me from the project and from management, making me a concept designer under the R&D group. Besides feeling completely betrayed, I lost all trust in the management, who I felt had not covered my back, nor did they look at what the team had actually accomplished.

Even Success Has its Failures to Learn From

Upon reflection, I had some insights as to what happened and it goes back to my zealotry after studying at Pratt. I changed the rules on the team without letting them catch up with me. While I got my superiors and cross-department teams to allow me latitude due to good results, the process I used to get those good results left my direct-report designers feeling either ignored or disrespected.

While I found design nirvana through my education at Pratt, I did not evangelize it, thus allowing my direct reports to gain the same insights. I just asked for blind obedience in a world where there are too many options, and a bottom-up culture. So when the designer of the best of the three designs was told his design was being “put on the back burner” in order to iterate on the other two weaker designs, he did not see it as part of a bigger process. Even though it was clear that the final design was framed mostly by his concept, I don’t think he was actually able to see it that way anymore.

The project continued without me, based on about 90% of the design from when I left. It has taken more than two years since I left to get it launched, according to inside sources. It succeeded well through a round of usability testing, although it challenged the engineering groups. The final result was what the customers needed to increase being productive and successful.

The end result was that I was basically demoted due to poor management, which I would call poor communication to the design team. The lesson learned here is that when working as a designer in organizations that don’t necessarily understand or appreciate design, the act of evangelism is not just about convincing management to spend on user experience. It is also about team management. You cannot make your direct reports follow you. You have to teach. You have to give room for them to discover their own way. Finally, if you do have to lead, due to time constraints and pressure, you need to be transparent in your communication style. It is not good enough to merely tell your staff what to do, you need to explain what will happen along the way and why.

About the Author

Dave Malouf is currently a Professor of Interaction Design in the Industrial Design Department of the Savannah College of Art & Design (SCAD). Before taking this position, Dave was a Sr. Interaction Designer for Motorola Enterprise Mobility where he designed software, webware, and hardware interactions and interfaces. Motorola was the last in a 15 year journey of practicing interaction design, information architecture, UI design, project management and other roles and positions working almost exclusively with thin client technologies.

Dave is also one of the primary founders and the first Vice President of the Interaction Design Association (IxDA). Dave’s passion for evangelizing and teaching interaction design came to a climax in 2008, when he co-chaired the first Interactions conference, Interaction 08 | Savannah.

Web: http://davemalouf.com

Twitter: daveixd

Facebook: www.facebook.com/daveixd

One Thing, Many Paths. David St. John

When I graduated from college the only computer programs I knew how to use were Word, Internet Explorer, and the popular CD-ROM based PC game called Myst. This was still the height of the dot-com boom, so while I had limited technical experience, my college education and a healthy local economy lead to plenty of work as a contractor for several startups in the Seattle area. Most of the assignments were not glamorous (data entry, quality assurance and categorizing products), however these experiences opened my eyes to the way of life in several technology companies that were still grappling with how to turn a profit using this new thing called the Internet.

It was during this early period that I participated in the launch of a new category of products for a large and successful e-commerce company in the Seattle area. All of the employees I met were extremely accomplished. Several people had companies that were acquired during the Internet’s growth spurt, while several others abandoned previous careers to join the tide of new companies flowing onto the Internet. It seemed that no matter your background, there was a place for you in this new economy.

I remember that the excitement was contagious and everyone behaved as though we were part of something new, huge and unknown to previous generations. Of course, there were some startup quirks during these early days; books, CDs and toys, that were purchased for reviews and cataloguing, were stacked on metal shelves in the dimly lit office. Employees and contractors could pick up whatever was no longer needed and use them. Dogs were also still allowed in the office during this time, so it was as common to have a four-legged friend walk past a meeting room as it was to see your colleagues heading to grab some free refreshments.

During my assignment I supported a program manager by associating categories to products. After the categories were associated with the products, the records were merged and uploaded to the enterprise product catalogue that was eventually used to power the search and browse experience on the production web site. Like the assembly line that created the physical object, I was a part of the digital assembly line that described that object for the online user.

The category editor would repeatedly state that there are “multiple paths to every item in the online catalogue.” One item had several dimensions of information, or meta-data, that described whether it was age appropriate, for a girl or boy, or of a certain brand. The point, she said, was for each item to have enough data assigned to it so that visitors to the site could find it in more than one way.

Our forefathers of information architecture were so bound by the physical world where everything had its place. The place was in a chain of multiple, cascading levels of organized hierarchies. Like Russian dolls, or the rings of an onion, after each layer you went down, you would eventually get closer to the core of what an item was. Most of this hierarchy was necessary to be found in the very structures of where information would eventually be placed.

Science would be on the 3rd floor of the library, so the entire third floor was science. To support the floor, all subjects of science were divided into many pieces, concentric circles of scientific pieces: campus, libraries, arts and sciences library, science floor, southwest corner, row 2, shelf 4, this is where you, the book, would live. The point the category editor made was that we were no longer bound by the same rules in the digital domain. We could create multiple paths to one object and it did not have to live in one place nor in one hierarchy.

Of The Book

Only there, where gravity acted upon you and every other book, did you realize that a hierarchy bound you. It is you, book, with such pent up pages that you cannot be in more places than one. There is one place you can be, and it is there in the midst of all other science books, that your first steps away from your boundaries began.

Now look at you, unbound from your inner rungs, you can step toward the world. Now you can be found anywhere, in any language, by any person. Anyone with access to the Internet can begin to reach you, search you, and course through your words with the clacking of buttons and keys, keys and buttons. I know your maker has put conditions on your letters, but nonetheless you are here, and now everywhere. No more shelves, just you, your reader, your creator’s words, some screen, some light or electric ink, are scribing your existence. Now, book, you have your freedom. Anyone can get you, to you, from you, and to others like you.

This is the glory, the lifting of the hierarchy. Oh book, you went everywhere simultaneously. One book you are, but to me you arrive by many paths.

Deconstructing UIs

Another era began with observing interfaces, studying them, and communicating how they functioned as a technical writer. The role of a tech writer afforded me the opportunity to be a close observer of the language used to describe a user interface, to learn how to structure a conversation about software, and to identify what to tell the end user about how to accomplish tasks with software.

The exercise of documenting software often began with deconstructing the interface. I would slice images of the interface from screenshots, assign a number to the images, and then pair each number with a description of functionality. There would be informative text about function after function. I would ponder the varieties, but always author to the most likely way to use the tool. The focus was usually on the way things should be done, how software should function, and how functions should be used. There were infinite “to statements” instructing someone on the steps needed to complete an action. (For example: To search for content, 1. Type a term in the search field 2. Click Go.)

In this flow from the receiving software, to deconstructing the UI, and then to providing a narrative; I grew weary of being the storyteller of an interface that I could not directly affect or improve. I could author with the craftiest descriptions of how software should function to meet user needs, but in one moment of realization, I came to the conclusion that the more complete the description necessary, the less likely one would be to read it. The best messages, I told myself, are those that are told by the work of the designer. The interface should “speak” to its user. It became clear that I wanted to swim upstream to find the source, to begin to meet user needs at the font of all my content.

Technical documentation is the recognizable discourse of the disciplined technical writer. Be it the bolded to statements and numbered sentences, or all the notes, tips and warnings, that craft, and its form, are unmistakable. And we know it is not the writers’ software, it is just their story. Unnecessary complication upstream has lead to a precipitous increase in words downstream. In fact, the deluge of functionality, so imaginatively articulated by the corps of software engineers, creates an emergency of words, a need for a raft of How-Tos and FAQs.

Intranet Design

Around the time that I began to show more interest in Web UIs, a new opportunity to redo our company intranet came my way in 2004. There were around 12,000 pages that needed to be accessed in a unified user interface by around 9,000 employees worldwide. The President of the company wanted a consistent experience that reflected the unified culture of the company. While the project already had a well thought out category taxonomy, and a proven technology approach, it did not have anyone in the business acting as the champion for the project, and the user interface had not reached a level of refinement to build momentum behind the effort.

I recall the new canvas of colours, fonts, texts, and controls; not to mention, MVCs, CSSs, JSPs. The user interface, now mine to improve, needed a voice. To give it form, the lead developer, development manager, and soon after, the sponsoring VP, all committed early to providing a voice for the user during the redesign. Though much was guided by healthy discussions between VPs tracking the project, there was an equal role afforded to the user feedback gathered in usability tests, web traffic patterns pulled from the existing intranet and frequent search terms mined from the existing search.

I designed and facilitated usability tests that walked users through the versions of the interface and recorded both their voice and the actions on the screen. Users were instructed to use the think-aloud protocol, which requires users to talk about their actions as they interact with the interface. After the tests, comments were grouped by theme, and for each area where we witnessed a task failing or the interface not meeting the user needs, we created an action plan to modify the design.

Web traffic patterns showed us the behaviours and patterns that already existed in the site. These metrics were used as the baseline for existing behaviours and as a standard for helping to see what effect the new design had on those behaviours. The frequent search terms helped us to identify the preferred resources and language used by the intranet users. In addition, we used the search terms as a way to identify what resources should be optimized to have prominent locations in the search and browse experiences.

As you can see, multiple measures helped to prioritize project activities, to focus efforts on where users encountered task breakdowns and to identify where the UI failed to “speak” to the user. During subsequent releases, we were able to make course corrections on the design based on our research. Each month we released a new pre-release build of the intranet that was punctuated by a meeting with the sponsoring VP to review progress. Then the sponsoring VP used the content of the release as talking points to share progress and features across the organization, and to gather feedback from around the globe.

In hindsight, the development team was small, we provided frequent releases, favoured high fidelity wireframes and working code over large requirements documents; we were extremely lean, and yet we still found time to test with users and incorporate their feedback into the design. The final release included a browse and search experience, template-driven authoring, search best bets, syndication management, rich text editing, and self-publishing. The UI will not likely win any design awards on visual design alone in 2010, but because we talked to users, and tested our designs, that intranet still has design concepts that are considered essential for successful implementations today.

Look Outward

The Help texts from my experiences as a technical writer were standalone content offerings. Each unit of information, “a topic”, was written to deliver enough information without the need or assistance of any other topic. Topics were assembled often to support a style of learning that slowly built knowledge. The new or intro concepts were first, then the more complex concepts and finally the most advanced. In addition, Help included narrowly focused sections that detailed functions that were the most complex to convey in just one topic.

In the intranet world, the ordering principle could not be as narrow and deep as when I authored Help. Here, one had to incorporate the multiple information views and there were just too many points of view to account for one way of navigating to the information. And in contrast to one Help site dedicated to a release of software, you had to provide a way to manage and address many primary sites and their supporting sub-sites. The movement was from nodes or topics that were members of a single site, to sites that had sub-sites and yet also included nodes that were individual topics. The Intranet proved to be a navigation problem that scaled up and out. It was both broad and deep, and had to account for the multitude of viewpoints that would be navigating the information.

The approach I envisioned to solving the information challenge was not that different that the “one thing, many paths” mantra of 1999, except that I had to articulate the problem and identify how it would be solved. While an intern from the University of Washington School of Information had already built a taxonomy, there was no defined approach for synthesizing hierarchical categories into a search and browse experience.

Around the same time (2004) a research team at the University of California, Berkley, was studying this type of problem, they called their project Flamenco. This project looked at faceted user interfaces powering both search and browse experiences. While the design approaches were welcome inputs, it was the discussion, language and discourse that gave a new area of design a written and visual language to explore.

It is one thing to read about a project, its theories and its outcomes, but as a practitioner of user experience, you have to problem solve from a place that is developed from your personal experience, the techniques that have informed design decisions for decades, and from your own research. The Flamenco project, and projects like it, have taught me that you do not have to go it alone when you think through tough design problems, and that there are most likely other people working toward similar goals. One hopes that they intend, like others before us, to share their experiences.

Be it your education in school, the books your read as a part of staying current in your field, the design problems you tackle with colleagues, your day-to-day experiences you have as a professional in the field of user experience or the hands on interactions with users, you will find ways to incorporate and solve the design problems you face. The challenges before you are made more achievable by the accomplishments behind you, and through it all you will find others like you that carry their stories of challenge and triumph.

The great reward for me comes from the equal exchange of ideas and finding others that have found a way to form their user experience story. As we delve deeper and vacillate between theory and practice, we will find common ground through the exchange, and I believe, the path will not be definitive or clearly called out, but rather, a series of many paths to this thing we call the user experience.

About the Author

David St. John is a Lead User Experience Designer at a wireless company in the Seattle area. He is a user advocate with experience in content management, content strategy, information architecture, and user interface design.

David lives in the greater Seattle area and is currently focused on rapid user-centered design methods, enterprise social applications, and the enterprise mobile web experience.

David’s LinkedIn Profile: http://www.linkedin.com/in/davidstjohn

Accepting Star Wars at Work

Red cascades of data flicker rapidly through my right eye. They move with me as I turn my head, telling me where to go; I now have to turn right. I mechanically follow the instructions, getting closer to my destination.

My mission is clear: find artifact A2000 4356 7832, pick it up, bring it back home. As easy as that. Yet I have never been in this sector before; I must rely on the information that appears in my eye.

I listen to the metallic pounding of my heavy boots on the floor, echoing and fading away. My hand wanders over the touch pad in the belt-mounted device at my side and I change the intensity of the rays.

Distant machines stamp out their never-changing beat. The hall I enter lies bathed in dim light.

Although the walls numb the senses with their icy greyness, I am not cold; it is warm in here, maybe 27° Celsius. A bead of sweat runs down my forehead into my eye. I feel a sudden sting, but I do not dare to wipe it away, afraid to lose sight of the thin red lines.

A man comes round the corner and stops in his tracks as he sees me. His mouth opens in disbelief. He certainly wasn’t expecting me—the cyborg—to appear here.

I grin widely and nod in his direction; a mistake. The play of facial muscles changes the position of the light source. The data stream moves out of focus. I knew it, the position of the laser isn’t stable and I’m losing contact with the data server.

While heading forward, I fumble with the head-mounted display, cursing the technology. No time to stand still, they are testing my performance. The light rays come and go, but a stable image cannot be achieved.

Oh, crap.

Suddenly orange lights flash and brakes screech. I turn to my left just in time to see a forklift truck stopping right in front of me. That was close!

“What the hell d’you think you’re doing, Darth Vader?!”

Parts Lists in the Automotive Industry

Needless to say, I am no cyborg and this is not a scene from some cheap sci-fi movie. In fact, the episode is from a feasibility study I ran a few years ago.

I was indeed walking in industrial safety boots through an 800 meter long commercial vehicle manufacturing hall with the sound of machines hammering in my ears.

It is also correct that I was wearing a head-mounted display (HMD) that projected red laser beams directly into my eye via a semi-transparent mirror in front of my face. This retinal laser device really was controlled by a mobile device on my belt with a cable that ended at the back of my head.

Via this HMD, I was given information on how to find a specific small part of a truck that was being assembled, and this artifact’s name, as mentioned above. The task was timed to determine whether performance was comparable to traditional methods using lists on sheets of paper.

To better understand the situation, a little background on the purpose of the part lists is needed. When you buy a new car, you usually want some individualization of the basic model, with extras such as special paint, some shiny chrome parts, a better hi-fi system or sports suspension. Whatever you choose, your car will become more and more unique, as the possibilities of combining extras are almost infinite. This obviously means that each car must have an individual list of extra parts to be assembled.

The same goes for trucks. They are also unique; rough estimates indicate that just two out of 100,000 trucks from any particular manufacturer are 100% identical.

Thus, there is a unique parts list for each truck. Someone has to find the right extra parts for a particular vehicle in a giant warehouse and bring them on a cart to the assembly lines—to the right place at right time. The parts list shows the ID of the truck and the line on which it is being assembled. There then follows a listing of sometimes hundreds of parts with their ID code (e.g., “A2000 4356 7832”), a natural language description, information on the quantity needed and their location. Basically the same data was displayed on the HMD, together with some additional details.

Inhouse Usability Engineering

I have been a usability consultant in the automotive industry since 2003. My job is to test all kinds of new technologies for their potential to facilitate engineering and production work for my employer. In other words, I do not have to make things salable to customers. If we find that a new technology might be useful for our workers, it is my task to make it as usable as possible. The retinal laser device is only one of many odd examples, including cooperative joystick-controlled robot systems and mobile augmented reality devices.

Of course, we don’t create these technologies, we test what can be done with them. We are first adopters who take technology straight from the lab. To me, therefore, user experience does not mean stunning visual effects. I focus on pragmatism, ergonomics, safety for and acceptance by our staff.

We received the HMDs from an external partner. After finding a possible manufacturing scenario, I was asked to ensure the feasibility of the technology. Feasibility here refers not only to technical aspects, but also checking whether the devices can be used as working aids without endangering the health of our workers.

The expected benefits of the HMDs were mainly ergonomic. The workers push their carts round the hall, selecting parts according to the current parts list. The carts are quite large and can only be moved through the main pathways, which means our workers quite often have to walk away from the cart to pick up parts. It would therefore be helpful if they could continuously see the correct ID code. The HMDs also eliminates the necessity of handling paper parts lists, allowing workers to have both hands free the whole time. Work would be more convenient and less stressful, which in the long run leads to better motivation and less errors.

So here is my task summed up: Take some innovative technology and carry out a pilot test of at least three weeks under realistic conditions, focusing on ergonomics (stress and strain of workers), usability (effectiveness, efficiency and user satisfaction), technology (stable and error-free performance) and economics.

Usually when talking about usability, we mean the goals of users. Yet, given the situation within an industrial work process, can we really assume that users have the same goals as the organization? What effect would mandatory use have on the acceptance of the system by our workers? I also wanted to investigate this.

Our User-Centered Design Process

“Your eyes are pretty good, considering you wear glasses. Your 3D vision is excellent and you have optimal color vision. And you will get glaucoma when you are older.”

Did he just say glaucoma?

“But, err ...”, I started. There was no reaction. The chief physician who had just checked my eyes at the ophthalmology clinic was no longer interested in my physical condition.

“Go to your doctor every three years and stop driving when you are old and blind.”

Ok, this is exactly the kind of empathetic doctor I was looking for to launch the first stage of our study—ensuring workers’ physical health. Every participant had to go through a thorough check of his eyes before and after the test to see if being exposed to the laser beam for more than six hours a day would have negative effects. In the end, we had 18 workers as volunteers, all of them healthy and highly motivated to participate in our pilot test.

Naturally, there was also a technical investigation of the lasers beforehand. We also ran ergonomic test series on aspects of the hardware, such as weight, haptics and so forth. The findings for standard all-day usage were optimal. The probability of harming workers’ eyes was zero.

Some ergonomic changes were needed, however. Can you imagine how well a touch pad built in 2003 works while wearing industrial work gloves? The touch point with these gloves on is about 4 cm wide, so we simply replaced the touch pad with a single giant knob, 10cm in diameter. Together with four out-of-the-box cursor keys and one additional key for opening the menu, we had six digital (on/off) input sources. Not much, but enough for the most important features.

Another lab test series evaluated psychological stress and strain caused by the devices. 30 participants were asked to perform intricate tasks of sorting items and solving puzzles while receiving instructions on the HMDs, compared with a group whose instructions were printed on paper. In addition, they had to perform concentration and stress tests, similar to those in IQ tests, between the tasks. Again, everything was fine. The two groups did not show significant differences either in performance or in objective stress or perceived strain.

Next stop: context analysis in the manufacturing workplace. We started by investigating how work processes could be translated into an information architecture and user interface design. To achieve this, we worked in the factory halls during standard shifts for no less than two weeks. This gave us the expertise needed to identify the workflows to transfer to the test system. In interviews with personnel, we determined which functions would improve work and should be added.

After that, the workers took part in card-sorting sessions to reduce the information on traditional paper lists into chunks and rearrange them according to their needs. Together, we created screens and found out how to turn them into interactive workflows.

Then we created fake click-through scenarios, known as demonstrators. These graphical prototypes allowed us to simulate the complete workflow without a single line of program code and without being limited to static screens or linear workflows. They can be created quickly and easily, even in PowerPoint. We simply drew the screen layouts and laid transparent rectangles over the interactive elements, such as buttons. The rectangles were linked to other slides, which then showed the system’s “response”. Our demonstrators thus allowed us to iteratively evaluate design and workflows in expert reviews, formal analytical evaluations using GOMS, and of course in focus groups with the workers.

Finally, we performed pre-tests with workers who wore non-functional HMDs during a normal working shift to find out how to optimize wearing comfort. A creative process started with glue, tape and fabrics, which in the end even allowed for individualized design; some of the workers started to alter the appearance of the device by applying paint and stickers.

After reading about how we performed every state-of-the-art step in a user-centered design process, would it not make a good story if the pilot test would have been a major success? In fact, everything went well except for one thing—acceptance. The participants did not want to work with the technology that they had helped to create. One by one, they stopped working with the HMDs, quitting their voluntary participation in the pilot study.

This was strange, as the system had superb results in usability questionnaires by the very same people; it was rated suitable for the task at hand, easy to learn, easy to control, users could individualize it sufficiently, it was self-descriptive, and it was consistent with users’ expectations for system behavior, as well as being tolerant towards usage errors.

The reasons for refusal, therefore, were obviously not to be found in our own UCD process, reflected in the questionnaire results. What was going on here?

In a subsequent interview series, we came to understand that the workers saw no reason for wearing the “helmets”, as they called the lightweight HMDs. Although all of them agreed beforehand that it would be good to have both hands free while working, they saw it more as one source of information being replaced by another. Even if they did not have to remember ID codes anymore, the overall perceived usefulness was not enough to outweigh the inconvenience of wearing a helmet.

This became especially evident in the contrasting cases of two workers who found the system to be very useful for them personally. The first was new to the job and he still had problems recalling the ID codes correctly. The HMD helped him greatly minimize his error rate. The second was long-sighted and found it much easier to read the augmented information than the written instructions. Neither wanted to give back “their” HMDs, even after the study was over.

To me, this is a good example of UX as the key to technology acceptance in industrial environments, too. As UX specialists, we must therefore always keep an eye on the perceived individual usefulness, not just aesthetics or objective usefulness. Or, as one participant put it:

“Now we look like we’re in Star Wars, but I would only use the helmets if I could watch Star Wars while working.”

About the Author

Henning Brau received his masters degree in engineering psychology at the Technical University of Berlin. For several years he worked as a freelancer in market research and usability consulting. In 2007 he became the program manager for “User-centered Technologies” at a German automotive OEM. Since 2003 he is member of the German UPA, joined its board in 2007 and was elected president in 2008. He co-authored a widely recognized German-language book on usability evaluation methods. Henning is also active member of the national standardization organizations (DIN) working group “User Interfaces” (e.g. DIN EN ISO 9241).

A Day at Acme Corp

I spent a day at Acme Corp recently … you know, the multinational company that makes all the supplies for Wile E. Coyote and other avid inventors. (Hey, I figure it’s more interesting than “all names and details have been vastly changed” etc. :)

Anyway. Acme had a problem: research showed that their website was completely, unforgivably, disastrously hard to use for their customers. And ugly, on top of that, as if it was spat from a template circa 1996.

So I sat down with the executives, everyone with a stake in the online presence, to help them improve the business metrics by improving their website.

Here’s an excerpt of the meeting transcript, more or less.

Me: “One thing customers complained about was the home page navigation. To quote one customer we talked to, ‘I can’t figure this thing out and I’m leaving right now.’ I think it had something to do with the flaming chainsaw animation that follows the mouse pointer around the screen. Is it possible we could remove that?”

VP Marketing: “Oh right, the flaming chainsaw animation. I’d love to take that off the site, really I would, but I just think it’s so neat, and besides it aligns with our brand message of innovation here at Acme.”

Me: “But customers would shop more, and buy more, if it wasn’t there. Wouldn’t you like to reconsider that animation?”

VP Marketing: “Here in Marketing we have to adhere to our brand guidelines, and innovation is central to that, so I’m afraid the animation has to stay.”

Me: “OK—next up is the customer complaint about the 18-level-deep flying dynamic navigation sub-menus. Several customers said all the menus zipping around the screen made them dizzy.”

VP Technology: “I know what you’re referring to. That menu system took our technology team six months to code up, and I have to say it’s the most advanced implementation I’ve ever seen, really an awesome job.”

Me: “The technology is impressive, for sure ... I mean, I’ve never seen 18 nested levels all flying in unison like that.”

VP Technology: “Thanks, man.”

Me: “Uhh—sure thing. But I’d just like to push back a little on this—the customers did say that the menus were confusing. How about a simpler menu, maybe just a few links to the top-level categories, and that’s it?”

VP Technology: “Listen, I’m all for simplicity and ease-of-use and all that, I hear you. I really get it. But I have to tell you, Web technology is moving fast, and if we don’t keep up, we’re going to look like Google or something. A bunch of blue links. Borrring.”

Me: “Allllright. Now we’ve covered the flaming chainsaw and the flying menus, let’s move on to the logo graphic. Some customers complained that they didn’t want to scroll down a full page just to get past the logo, the large stock photos, and the slogan.”

VP Branding: “What did they say about the color scheme? I’m just wondering, because the green and fuscia palette is really supposed to, you know, bring forth associations of innovation and holistic thinking, all while blending in with the flames from the chainsaw.”

Me: “I think I have a plane to catch.” (Exit conference door right.)

About the Author

Mark Hurst is an entrepreneur and writer concerned with the idea of “good experience”—in particular, what enables or detracts from meaningful experiences of creativity, technology, community, and life.

Every spring in New York he runs the Gel conference, spotlighting heroes and innovators of good experience in a variety of fields.

Mark also writes Good Experience as a blog and email newsletter for tens of thousands of readers.

In 1997 Hurst founded Creative Good, a firm devoted to helping business create better experiences for their customers and employees. He runs it with business partner Phil Terry.

His 2007 book Bit Literacy proposed a basic set of skills to overcome information overload. Douglas Rushkoff wrote, “Mark Hurst is the smartest person thinking about ways technology can make our lives easier rather than harder.”

Mark began his Internet career as a graduate researcher at the MIT Media Lab, then worked with Seth Godin at Yoyodyne. He holds bachelor’s and master’s degrees in computer science from MIT and lives in New York City with his wife and son.

Web: http://goodexperience.com

Twitter: markhurst

Facebook: markhurst1

UX Professional Goes Car Shopping

In the winter of 2008 my most excellent auto mechanic, Jake, gave me the bad news: my beloved 12-year-old car should not be driven through any more Michigan winters. Too much corrosion was attacking the frame.

Many car parts can be fixed or outright replaced, but a frame with too much corrosion becomes dangerously weak and impossible to repair. Michigan is in what we Americans call “the rust belt”. The steel in automobiles competes with the salt spread onto the roads during the winter. Eventually, the salt wins because the rust spreads like crazy.

“If you really want to keep it forever as you’re always telling me, get something else to drive in the winter,” Jake said. Jake knows what he’s about. He rebuilt the engine for me at 217,000 miles. Replaced the clutch, too. He also modified the suspension and exhaust system for me over the years as we made the car more fun to drive than it had been straight from the factory.

So this car I’d bought when fresh out of grad school in 1996 was now too rusty to drive all year round. This was a moment of serious emotional import. This car and I had been through a lot together. It was even stolen in 1999 when I lived in Denver. Days after the theft, I bought another 1996 Saturn SC2 in nearby Colorado Springs because I couldn’t order a new one. (Saturn had ruined the model for me with some ugly revisions in 1997, and there were no other car brands on the market that remotely interested me. I wanted the same car back as I had lost!) But then the police found my original car partially stripped in a south Denver parking lot. So I had two 1996 SC2s in my driveway for a few months until my original car was restored and I sold the second one.

280,000 miles is a lot of miles and memories, and the cockpit ergonomics of those mid-90s Saturn S cars are a joy to drive (see my Design Critique episode, 1996 Saturn SC2 Critique[1]). Before General Motors’ inept interference in the late 90s, Saturn proved with the nimble, frugal, two-door SC2 that economical cars could provide terrific user experiences when designed properly. Could I find a car this good in 2008?

Transportation, Lifestyle, and Selection Criteria

Cars are tools like any software, website or appliance. They have utility that some people can separate from any aesthetic, ego or value judgments. To some people, a car is merely transportation and things like styling, ecology, and values projection are not part of the equation. These fortunate people find it quite easy to buy a new car because their needs are simple, and their lack of passion about the driving experience lends them an easygoing attitude that verges on apathy.

I belong to the somewhat unfortunate class of driver who demands a great deal from a car’s user experience. For these people, cars are lifestyles and extensions of their owner’s deeply held values. For many enthusiasts, a car can become like a family pet, with the accompanying vet bills and chores to care for it and help it “live” as long as possible.

User experience professionals are a demanding sort to whom critiquing designs comes as naturally as breathing. I can now attest that this tendency is in full force during car shopping. My basic criteria for my new car would be:

1. Two doors, because there’s just me to get in and out, plus an occasional front passenger. Back seats are superfluous and I’m aesthetically allergic to four door vehicles.

2. Firm suspension so the handling is fun and sporty. None of that wallowing, squishy, marshmallow ride for me. Besides the fun factor, firm rides also give safer handling in emergency situations due to the feedback they transmit to the driver and their tenacious grip on the road.

3. Four-cylinder engine, because there’s just me to drive around plus occasional luggage, and I like using as few resources as possible to drive on—I want ecological fun. The Saturn SC2 can get 40mpg at 55mph, and 12 years later I wanted a car that would not get worse than that.

4. No sunroof because I dislike direct sunlight and mechanical troubles are common as sunroofs age. Also, they add weight at the worst possible place for handling, at the top of the car, far above its centre of gravity.

5. 360-degree visibility, just like the 1996 Saturn SC2 (no blind spots).

6. Good user interfaces and controls in the dashboard, steering and centre console.

7. The dealership experience must be respectful of potential customers and not insult my intelligence nor waste my time.

MINI Cooper

Website Experience

I had admired www.minusa.com for years as the best car brand website I’d ever browsed, until MINI redesigned it in the summer of 2010. The MINI build-your-own-car configurator was especially well done. Over several years I went from admiring the site design to thinking I should test-drive a MINI when the day came to buy a new car. Let this be a lesson to automobile manufacturers out there: a terrific website can entice potential customers into at least walking into your dealerships!

MINI Dealership Experience 1

One Saturday in April of 2008, I drove an hour down to Ypsilanti to pick up my car advisor buddy, Ken, and then head to Motor City MINI in Shelby, an hour northeast. The dealership initially impressed me by letting Ken and myself test drive a MINI Cooper S without the annoying “tagalong” of the motoring advisor. They just verified my driver license and handed me the keys. Now this is how to treat your prospective customers, folks.

My first impressions were to love the torque of the turbocharged engine, appreciate the visibility that was almost as panoramic as my SC2, and adore the brakes, which slowed the car amazingly quickly.

Unfortunately, the cockpit controls are terrible. For example, the turn signal returns immediately to its centre position when pressed to indicate a left or right turn. It does not stay down for “left” or up for “right”, thus forcing the driver to take eyes off the road and look at the blinking lamps to verify they are signalling the proper intent, or even signalling at all, if music is loud enough to mask the audio cue of the signals.

The 2007-2010 MINI’s climate controls and audio controls are the worst I’ve seen anywhere and look dreadfully cheap and childish, like toys. I do not expect, nor want to pay for, cheap plastic exaggerated “Fisher-Price toy” controls in an upscale automobile. The centre-mounted speedometer is enlarged far beyond the classic “Minis” of the 1960s and thus looks cartoon-ishly absurd. Quirky personality is one thing, but there’s a fine line between charming and cloying.

Upon returning to the dealer, I asked to drive the non-turbocharged MINI Cooper. At this point the entire experience went pear-shaped as we were told the dealer did not allow the cheaper model to leave the parking lot! News flash to any car dealers out there: driving a car in a dealership parking lot is not appropriate to the purpose of a test drive, especially when shoppers have driven over two hours to reach the dealership. To make matters worse, when I was able to flag down a motoring advisor and ask a question I had prepared in advance about the car (to see if the staff knew their stuff), the answer was flippantly useless and actually wrong enough to have cost me a lot of unnecessary expense if I had applied it. Finally, some of the staff exuded a “hipper-than-thou” attitude that was extremely off-putting.

I left, intrigued by the MINI, but disgusted by the ineptitude of the staff and swearing never to buy a car from that place. The character of the car was intoxicating, and surprisingly strong enough to make my reservations about the terrible controls seem worth rethinking. I never thought I could admire something so inherently unusable, so deliberately inept, but I began to see that the product was exciting despite some very poor user interfaces. Could it be that a good user interface is negotiable when balanced against other factors in a product?

UX Takeaways

1. Invest in a proper website to communicate a car brand’s unique qualities and make it easy for prospective customers to build their own “daydream car” during their car research.

2. Allow for solo test-drives, especially when two people show up asking for a test drive.

3. Do not waste prospective customers’ time by forbidding trim level comparison drives, answering product questions incorrectly, and behaving like the Fawlty Towers[2] of car dealers.

Honda Civic Si

Website Experience

Trusted automotive advisor buddy Ken told me to test-drive a Honda Civic Si because it was recently redone and good value for fun. Off I went to Honda’s website for the Civic Si and discovered that Honda’s website was, in the spring of 2008, dreadful. It could have been designed 10 years earlier from the look and interaction design of it. None of the personality of the car, nor any effective use of Flash that MINI is so good at for describing options and configuring a car, were apparent. Honda’s website was very static overall; the content was typical corporate bland bad marketing fluff and not at all engaging for what appeared to be a very engaging car.

Civic Si Dealership Experience 1

While visiting my parents in nearby Ohio, my Dad and I went to the local Honda dealer to try a Civic Si. Upon arrival, a salesman announced that the dealer did not allow the Civic Si to be test-driven on actual roads but we could drive it round the parking lot and access lane.

What the hell is going on with these idiot car dealers?

Do they really think a product that costs well over US$20,000 can be test-driven in a parking lot? Is a website or brochure or magazine review going to let a customer experience the product firsthand? Obviously not. Would any UX professional conduct a usability test by telling the participant, “We can’t let you perform any tasks with the product in pursuit of your typical goals, but we hope your session with our product will be enlightening”?

Perhaps my clean driving record and friendly, retirement-aged father’s presence made the dealer think we were car thieves—yes, that must be it. It’s laughable that cars such as the MINI Cooper and the Civic Si, which cost less than $25,000US, are treated like exotic super cars costing tens or hundreds of thousands more. The hostility towards allowing prospective customers the experience of driving the cars on actual roads is inexplicable and unforgivable. We are not talking about Ferraris here.

Well, we had driven for over 30 minutes to get to this point, so drive around the parking lot and access road I did, my Dad in the back and the clueless salesman in the passenger seat. To my delight, the controls of the Civic Si were wonderful. Everywhere that MINI made a stupid decision, Honda made a good one. The dreamy short-throw manual transmission has a sensible shift pattern unlike the MINI, the parking brake is alongside the shifter for immediate use by simply rotating your wrist 90 degrees, the centre stack has everything within reach and I didn’t need an instruction manual to figure it out, plus several knobs were oversized to facilitate gloved hand use in winter, and the dashboard was exquisitely usable. Honda carved the dash into two tiers, the top tier holding a digital speedometer plus two gauges, and the remaining gauges and tachometer in the lower tier. Marvellous! I could keep my eyes on the traffic ahead and still see my speed in peripheral vision. No need to look down even for half a second.

Speaking of vision, the Honda Civic Si’s visibility is poor compared to my first-generation Saturn SC2 and the MINI. To get its terrific crash safety ratings, the Civic employs very thick roof pillars front and rear. These pillars create huge blind spots on every corner, which was very disappointing. You cannot see pedestrians and cyclists entering crosswalks until they are already in front of a fender!

Other problems with the Civic Si included the forced inclusion of a sunroof, an engine that sounds gorgeous under load but has a little less torque than I prefer, and exterior styling that looks like a well-used bar of soap on wheels.

UX Takeaways

1. Do not treat a somewhat inexpensive car like an exotic and disallow test drives on actual roads.

2. A clueless salesperson is NOT necessary on test drives and just inhibits conversation between the customers.

3. Get a website that shows the car off without making users feel they are looking through the pages of a print brochure done by marketing hacks. There undoubtedly exist marketing professionals who are also literate driving enthusiasts. Hire them!

4. Do not force customers to buy options in large packages that compel them to get many items they don’t want just to get a few choices they do.

Mazda 3

Website Experience

Sadly, in 2008, the Mazda website was as lame as Honda’s was that year. Unlike with MINI’s superior website, I again felt I was looking through a print catalogue; Mazda’s site did not take advantage of what websites are good for when communicating dynamically variable information. Building a car online was awkward and information about trim levels and options was not presented well. And I would have to get a sunroof to have the trim level I wanted—plenty of that cursed option bundling was going on at Mazda as well as at Honda.

Test Drive Experience

Local UX peer Mike Elledge from Michigan State University’s Usability & Accessibility Lab had recently bought a Mazda 3 sedan and strongly suggested I try it. Mike is a wise man who used to drive old BMWs exclusively, so I took him up on his offer to drive his Mazda 3—he obviously appreciated good cars. After my bad experiences trying to test-drive cars on public roads with the MINI and Honda dealers, a private appointment with someone who prefers “driver’s cars” and would share his was welcome. Even though Mazda does not offer a coupe in the 3 series, the sedan looked so good to me I didn’t care. (2009’s “face of the Joker” redesign of the Mazda 3 put an end to my appreciation of these otherwise fine cars.)

Driving the 3 was fun and I could see why Mike liked it. Visibility was better than the Civic Si, and nothing about the interior controls annoyed my usability sensitivities. I did wonder about the use of red in all the lighting and gauges. It’s probably good for preserving night vision, but aesthetically I wasn’t eager to see red everywhere all the time in the day. Perhaps it was my cultural tuning to red as a warning colour only.

I also noted the same “force many options down your throat because you dared want one specific option” packaging that plagued Honda. Even if I could stomach driving a car with four doors, having to get a sunroof really annoyed me which was unfortunate as the handling and other aspects were good.

UX Takeaways

1. Stop forcing customers into mandatory up-sell positions when all they wanted were a couple of options.

2. A dashboard full of red lights is not conducive, on first impressions at least, to tranquil, focused driving.

MINI Cooper (Revisited)

Dealership Experience 2

Back in Ohio, Dad and I went to the Cleveland MINI dealer to see if they allowed test drives of the non-turbocharged Mini on, you know, public roadways where cars are expected to actually be driven.

Classic MINI was an entirely different experience from Motor City MINI. Upon walking in to a separate building that housed only a MINI dealer, and wasn’t the back room of a BMW dealer, there was a notable lack of pretension and “attitude” in the staff. Even better, the motoring advisor who approached me seemed surprised at the idiocy I’d endured in Michigan and asked “which MINI would you like to drive first so you can get your direct comparison?”

Off we went and I didn’t mind the motoring advisor coming along for the ride because he actually knew where to take the car for safe tests of its acceleration and handling. He also contributed insightful comments to us about the product. Imagine that! It was obvious he loved the product he sold and enthusiasm is contagious in these situations.

The lack of a turbocharger made the standard MINI seem less exciting, but the superb handling was still there. Unfortunately, so were the dreadful controls inside the cockpit. However, at least MINI allows for an a la carte selection of options, unlike Honda and Mazda. The options may cost more as a result of so much assembly line customization, but the customer has a choice to create his or her own unique MINI and it was good to be back in a car with superior visibility again.

A sad fact of the turbocharged Mini was the unavailability of the traditional MINI slatted chrome grill. Only a black piece of plastic hexagons is used, which makes the Cooper S resemble a Volkswagen in a twisted confusion of brand identity. When I found frequent complaints of reliability problems with the turbocharged 2nd generation new MINI in various Web discussion forums, I crossed the Cooper S off my list. But the Cooper was becoming an intriguing option.

UX Takeaways

1. For goodness sake, let the prospective customer test drive all models on the public roads.

2. Provide a single building for a single brand of cars instead of an afterthought extension off another brand’s showroom.

3. Be friendly and attentive to customers who walk in.

The Inevitability of Compromise

After a successful test drive on public roads of a Civic Si at a decent Honda dealer in Michigan, I had my choice before me:

1. Enjoy the superior cockpit design of the Civic Si, but endure poor visibility and soap bar styling, OR

2. Design my own MINI exactly as I wanted it, enjoy amazing handling and brakes, and endure the worst car interior ergonomics I’ve ever seen.

In the end, my choice of the MINI was based on some emotional reasons that had nothing to do with usability and everything to do with other components of my user experience:

1. The MINI has a large enthusiast community of people who love to drive fun sporty cars. Buying a MINI buys entry into this world of diverse fellow enthusiasts who participate in car club activities on a regular basis.

2. I’d always dreamed of having a sporty British car with a wood dashboard, and the 2nd generation new MINI offered that as an option.

3. The experience of configuring almost every aspect of the car appealed to the designer in me. MINI’s website claims that 10,000,000 configurations are possible with their cars and that no two Minis ordered from the factory are alike. Even if that is marketing fluff, there is an element of truth in it.

By ordering the in-dash navigation system, which I wanted because of my infamous poor sense of direction and frequent solo road trips, I was able to ameliorate some of the worst user interface errors in the cockpit’s centre stack. But I admit that the embarrassingly poor design of the rest of the dash and the controls is always there in my mind, and teeters in balance against the terrific handling and braking and overall charisma of the car. It’s a real study in contrasts.

In Conclusion: The Miracle of Adapting

The experience of tailoring a car for myself was just as fun as it had been in 1996 with Saturn, and the fun I’ve had with the Michigan MINI Motoring Club has been a continual reminder that I made a good choice. There was no perfect choice, but this has been a good choice and that is perhaps the best one can hope for.

It was thrilling and maddening to shop for a car in the first decade of the 21st century. Thrilling because modern cars have so much good engineering in them and are in general more reliable than the classic cars I drool over at old British car shows, as well as being safer.

But it is maddening to see a great car (like the second generation of the new MINI) hamstrung by interior controls that so flagrantly break my cardinal rule of driving usability, which is:

Good car designs let the driver keep eyes on the road all the time. Bad car designs force the driver’s eyes to verify what he is about to do, or confirm what he has already done.

Whether it is simply checking one’s speed or changing the temperature setting of the heater, we should not have to look down and ponder while our car zooms ahead so many feet per second. Saturn knew this in the early to mid 1990s and made a terrifically usable product. How is it that MINI does not, so many years later? I reluctantly admit that in all products, the mere existence of great designs does not automatically mean every brand learns from its peers. Best practices are rarely universally adopted in an industry, if ever.

Every day I smile as I approach my MINI. Then I climb in and frown while I curse Gert Hildebrand and his “designers” at MINI who ruined Frank Stephenson’s first generation MINI with their desperation to be ever more cutesy-cute and different for the sake of being different. Even the headlamps of this 2nd generation MINI were ruined by the “cross-eyed dumb fish” look of the turn indicators being deliberately off-centre. But as soon as I’m moving down the road, most of my revulsion melts away into delight at the handling and braking of the car—this is motoring!

What do I take away from this? I would say I chose to compromise my value of usability for my value of nimble handling, awesome braking, great gas mileage, and customization I was able to do from the factory. Two out of three ain’t bad. I can live with it, because we humans have a wonderful capacity to adapt to bad user interfaces in the pursuit of our goals.

Will we ever have customized production of personal transportation where the customer has control over user interface design and ergonomics of the vehicle, in addition to choices over options such as heated seats, paint colours, and seat fabrics? With the integration of computers into automotive systems, I hope that someday our cars’ user interfaces may be subject to the preferences of us, the users, not a product manager in Munich who wears black all the time and delights in form-over-function designs.

Would such fine-tuning of user interface and control “preferences” by the car owners themselves lead to dangerously bad designs? I argue that it can hardly get any worse than it is now with some car models. We see customization of user interfaces in software and websites with various “skins” and “themes” that product owners share with each other in online forums dedicated to discussing these products. I hope car dashboards and centre stacks, perhaps built with OLED screens and touch technology to allow “soft buttons” and displays, are not far behind.

DISCLAIMER: The author does not want readers of this chapter to in any way interpret this story as an endorsement or promotion of MINI brand automobiles. The shopping and ordering processes were indeed fun, but eight unique warranty repairs in the first 19 months of ownership speak for themselves. Caveat emptor!

About the Author

Timothy Keirnan (Michigan, USA) is a user experience practitioner by day and producer of Design Critique: Products for People podcast by night. He holds an undergraduate degree in audio engineering and a graduate degree in Technical & Scientific Communication.

By day, he works as the User Experience Analyst in a large corporation’s IT department. By night, he produces and cohosts one of the first podcasts devoted to User Experience and its related disciplines. Design Critique started in summer 2005 and continues to encourage usable designs in products of all kinds for a better customer experience. You can find Design Critique at:

Web: www.designcritique.net

[1]. http://designcritique.libsyn.com/index.php?post_id=340718

[2]. http://www.fawltysite.net

Design is Problem Solving—In More Ways than One

It all began on a cold day towards the end of October in 2005. I was rushing up to go over for a client meeting, 5 miles into the city. As I was about to close and lock my computer, I saw a message pop from the Resourcing Team. I gave it a cursory glance, thought with a sigh, “Another hard gruelling project” and locked my computer. However, I thought I had noticed something like a “travel instruction”. So I unlocked my computer and read it in full. It was indeed a new project I was to take up, but to my disbelief, I saw that I was to travel to Singapore in the next 3 days. Of course, I was shocked, unhappy and essentially disturbed since I was to travel at such a short notice.

“Let’s deal with this when I am back from the client meeting,” I thought. The meeting itself went pretty well and the clients were a happy bunch, now that we had turned around their rather clumsy news site into a more “new-worldish site” - in their own words.

I came back three hours later, went through the mail again and called the Resourcing Team. The first thing they asked me “Did you get your ticket yet? What kind of accommodation are you looking for? Please fill in the travel request form and send it back ASAP.” I fought to control my myriad emotions at play and asked them a simple question “Why is it such a short notice?” “Because the project has started yesterday and today, you will be talking to the client at 6.30 pm. Did you not get the invite yet?” was the reply.

Now I lost all my control. There was a shouting match between us, we exchanged non-pleasantries and banged the phone down on each other. But there was nothing that could be done. Well, something could be done, get familiar with the project, get to the documents sent by the client and start the project study. So that is what I did, as all good employees would do.

The evening call with the client happened as scheduled. All of us team members were introduced to the client contact, Bill. I was to lead the project and Alka Mukta was the project director. The project was for 1 year, which, as I was to witness later, extended to 2 years. And Bill, with all his charm, welcomed me on board and said he expected me to start work at the client’s location in 3 days. This meant I had to travel not 3 days from now but in the next 2 days!

I was not surprised. During the day, I had learnt enough not to be surprised. In fact, I had steeled myself to the point that if I did not come across “surprises” every hour it would not have been normal for the day!

A Quick Intro

To those who do not know me, I am a User Experience Strategist. Also referred to as User Experience Architect, Interaction Designer, Usability Analyst, Software User Interface Designer and so on. Though, taken individually, they differ from each other, chances are most people called by any one of those names above will be doing an overlap of all at some point.

My job is to make the experience of using software fit in with the envisioned parameters. Typically, every good software interface is envisioned to behave in a certain way. For example, an application designed to assist people in their day-to-day tasks in an organization focuses on making it most efficient. An e-commerce site encourages the visitors to browse for special products and persuades them to buy stuff online. A social networking web application would want its users to effectively make connections and maintain relationships with the real people in their circles.

In generic terms, this is what my tribe and I tend to do, enable the software and the people to interact effectively so that the stated goals are achieved. Increasingly, businesses have realized the true power of a good Interaction Design. But there are still people, in the heart of the software world, who are yet to appreciate the need for this, as I learned in my client’s place in Singapore.

At Singapore

The Changi Airport at Singapore is a huge enclave with armed guards, pleasant immigration officers and tired, but cheerful, porters walking around. And the familiar smell of the sea mixed with the air welcomed me. I have always liked Singapore, the all familiar, almost-touchable cleanliness, the greenery, and the consistency of weather have all added to my pleasant memories of the place.

The client’s offices in Singapore were like a dream. It overlooked the backwaters, in Shenton Way. In addition, half of the Singapore Skyline was visible from my window. A great start to my onsite assignment. Or so I thought.

I met Bill and he introduced me to a couple of his colleagues. Though they were courteous, I could see their sarcasm when they said “Oh, Usability?” In fact, one of them, Mathew Clarke, a little less diplomatic of the lot, even went on to say “Really what does it do? It’s almost a hindrance, isn’t it?” “Well,” I said to Bill, “that is a memorable start.” He smiled but it carried more meaning than it showed.

The first day went in a couple of mere introductions. Bill gave me some quick updates about the overall project, what it meant to the management, including the President of the Organization, and the vision they had for this product. He said, “OK then, great! Get Started.” I was to learn later that this was his favourite line.

With my off-shore team, in the next 2 days we created 1 or 2 mockups to initiate discussion on the strategic framework . On the third day, Bill took me to “just socialize this with the tech team.” “OK” I said, “if it’s that easy.” As it turned out, it was far more difficult than I thought. The Senior Architect was hell bent upon proving “how worthless Usability was.” We discussed the placement of the “Print” button for about 3 hours and on a stalemate, we decided to end the meeting, promising to continue the next day. His comments were plenty—“Why should Print be a button? I don’t quite like the blue colour. Can we increase the font size? Oh, it opens in a pop up? Hmmm … But that affects User Experience,” and so on. I was wide-eyed and said to myself “I thought this was a strategy related meeting. And a single Print button generally cannot make or break User Experience.” Of course, I did not dare bring that up, lest it take 3 hours more. But I realized that sacred terms such as usability, user experience and the like were used loosely without major thought put into it. And User Interface strategy meant nothing more than what they could see at that point.

I could sense an undercurrent of uneasiness towards Usability. They seemed to hate us and I had no idea why. I even discussed this with Bill but could not get a satisfactory answer. But then, in a matter of a few days, I learned what the truth was. Like most problems, it was a combination of several factors. The unhealthy politics, petty individual egos, fragmented teams that failed to look at the big picture, a fear that it would cost them plenty of time and effort to meet the UI needs and a general lack of understanding of the importance of a good UI—all contributed to a general feeling of uneasiness towards the UI. And the fact that User Interface is so visual and gets very subjective most of the time, makes it all the more complex. One has to be “up for it” all the time—with research, empirical data, best practice info, and a strong hold of the subject. And, of course, the ability to convey all this in relation to the technical view point.

This rather unpleasant start was something not completely new to me. I had experienced a rather similar situation about 3 years before when I was in Dubai.

In Dubai

Dubai is the land of gold, silver and sand. It is the trading hub of the Middle East. It carries a legacy of being the “free state” among the rather orthodox ones such as Saudi, Iraq, Iran and the like. Dubai is actually everything except petrol and the government has business interests in a variety of sectors—real estate, transportation, aviation, and healthcare. I worked in one of its Information Technology divisions that catered to the travel sector.

The situation in my early days there, when I landed in 2002, was not too different from that of my client in Singapore. The Business Analysts were sceptical, the developers were difficult to work with and the managers did not understand what usability was. Wow, not much was left to go wrong!

The first thing I had to do was to educate my manager on the methodology, the ROI and the need to move the UI team up the value chain and to develop strategies for it. Initially, everyone was reluctant to even talk about it. When I floated my ideas to my team, they responded with “Oh, there are too many levels involved,” “nobody understands it,” “we are doing quite well without it,” “we play just the ‘support’ role” and “we don’t stand to benefit too much from it”—and summarily dismissed them.

The grind then began. I had no idea how to take it forward, with this reception from my colleagues. So I put down what was that important ingredient, for each category of people, to enable them to understand. For the high level executives, it was the ROI. For development team project managers, it was the value-addition that they could provide to their clients. For business analysts, it was the effectiveness of the features in any application. For developers, it was the challenge in writing the code and at times, the easiest way to complete a task. And for designers, it was the beauty of the solution. OK, the first step was clear but a long way to go. “At least,” I thought “the problem is deconstructed.”

While I was wondering how to go about the next steps, a friend of mine, who more sympathized with my cause than believed in it, gave me an idea—a brilliant one at that. He suggested a usability testing of the intranet, the management’s favourite child. In fact, the management had made it mandatory, making it the homepage for all employees. They took a lot of pride in this endeavour. “So,” he said “conduct a usability test of the common tasks of the intranet and give a live demo of what the users go through.” This was an exciting plan and to make it more real and to generate a sense of excitement across the organization, we planned a “usability day” in one month time. We campaigned for it through posters, email campaigns and quizzes leading up to the event. The people were sufficiently excited and they came in reasonable numbers for the “Live Usability Testing.” Large video screens were installed at strategic locations and we also webcasted it for those who could not be present.

The recruited employees arrived one by one with a flourish; they were almost heroes in front of their peers. There were16 of them. We had recruited from all types of employees – tech savvy, non-tech, seniors, new staff, managers and developers.

We briefed them, gave them the first task to complete, which was sending a message to a colleague through the intranet and the exercise began. Any fears I had up to that point vanished in the first couple of minutes. 50% of the participants did not even know this was available and 25% of them could not locate the employee list. We could see the others egging them on and almost muttering to them without being able to say out loud—“It’s just there.” This was the most silent Football ground atmosphere, I guess. The CEO walked in and saw how his prized possession was reduced to a non-entity with its users. The CIO was displeased and was seen venting his ire at the Intranet Project Manager. And by the end of the exercise, the intranet team were in another conference room, the meeting chaired by the Project Manager. The silence in there was so loud that it could be heard!

We did not even have to go to the other essential buy-in factors such as ROI, the value-adds from the UI and so on. The point was made and our team was summoned later by the CEO to come up with usability methodology to fit in with the existing SDLC (Systems Development Life Cycle) and create Standards. And it was mandated for all App Teams to go through the UI team in all of their application development. A sweet sense of victory pervaded the team and we went out for a celebration.

Back at Singapore

Now back here at Singapore, in 2005, it was not too different. I realized we needed something as dramatic to get the usability ball rolling.

It was the second Tech Team Meeting, which also included the Tech Program Director, Dave Williams. Dave Williams was rumoured to be a “tough guy,” “uncompromising” and “very smart,” all of them being true. Now, this time around, I went with a rather different approach, learning from my first meeting. I had prepared a list of scenarios of the UI, mapped them against personas and had them handy. Every time a question was raised, I pointed at the personas, scenarios and challenged them for a better solution, since they happened to claim that “Usability and User Experience was not up to the mark.” Slowly, gradually and grudgingly, I received some acceptance from the staff. A handful of people, including Dave Williams, were now convinced that, after all, there was some reason and need in Usability. Since I knew a bit of technical stuff, that I had learnt on my own and from colleagues, I was able to provide them with a couple of solutions to some of their coding problems. That also helped the rapport. But one guy, Mallert Curtis, remained adamant about the “uselessness of user-friendliness.”

“The Alerts guys are ready for you” announced Bill one day. Who and what were the Alerts guys, I wondered. “The business analyst folks that work in Alerts Team, Rachel and Attilio, want to have a meeting with you to discuss the User Interface for setting up Alerts” he explained.

“Oh, is that all? I should be ready at 3 pm to discuss it.” “They are waiting for you at Conference Room 112,” he said and walked away.

“But I don’t have an invite!! And I have lots to catch up on!”

A shrug of shoulders and a spread of arms later, I marched to the Conference Room.

I was greeted by about 8 people all standing in a semi circle and discussing in hushed but serious tones. I started “Hi All, I am here to discuss the User Interface of Alerts.” Attilio, a stout man with a thin moustache, stood with his hands folded to his chest and grunted, “Have you not already created a panel for Alerts in the Dashboard?” “Yes,” I said, “it was but a placeholder only to indicate where an alert will ...” He lowered his hands, put them in his trouser’s torn pockets and stood erect and barked, “But how the f... did you show it to the business?”

“I did not and no, my team didn’t, but probably one of your colleagues did. But what really is the problem here?”

Attilio sighed with the appearance of an impatient teacher tutoring his student. He went back to his favourite hands-folded-across-his chest position and said, his voice gathering pace as he went on, “we are funded a $100,000 and do you think all that you want us to do is possible within this amount”. He offered more grim statistics and how we had effectively made his life hell with the small panel that we had offered in the dashboard design. All of this, rightfully, went above my head and at the end of it all that I had to say was “Please check with your colleagues who requested us to do that.” Another meeting, rather interrogation, ended and I proceeded back to my desk wondering when we would ever be really accepted by all the teams.

Whilst in Singapore I stayed near Serangoon Road. It was also called “Little India”, and for a good reason as it reminded one of India - quite a lot. The aroma of Indian spices greets you as soon as you enter the street. There are many Indian restaurants such as Anaphora, Dasprakash etc., that serve Indian delicacies, and good old Hindu Temples that date back a few decades or more. People throng the multiple Indian Jewellery shops on this road.

My Weekend Out

One weekend, it was about 1 pm, I still had many hours at my disposal and so, looked for the events in the city. “SingEx” it read, “is an exhibition for one and all, the cheapest and the best products all under one roof.” I decided to visit the place and check out the tall claims. I was passing through a stall that advertised the newly launched Singapore Portal that gave information about the city, places to visit, restaurants, bars, etc. It brought back memories of the Bangalore Portal we had launched and how, a long time ago, we had made an error in judgment that cost us to drop an ambitious project. The lesson we learnt was, “Know your audience well, and make all efforts to know them really well.”

MetroBangalore

This was in the year 2000 when the company I worked for decided to launch a portal that covered all aspects of Bangalore. The project and the website were named MetroBangalore and it aimed at covering restaurants, places of worship, public transport information and just about everything in Bangalore. And, as an added attraction, the company director decided to hold a “Miss MetroBangalore” contest. This meant the participants for this contest were all to be featured in the website and the users of the site would vote and choose the best among them.

The preparations began in right earnest. We interviewed potential users, did secondary research and got together some designs for the site. We were left with the problem of getting people to participate in the flagship event of the site.

Our newly joined marketing head had a brainwave that, at the time, I admit, looked “brilliant.” There is an annual exhibition in Bangalore called the ICE Exhibition. Its a very popular exhibition. Our marketing team decided to put up a stall there and prepared brochures, pamphlets and some video material to lure people into participating in the event.

We explained the site’s purpose to the visitors and more importantly, the details of Miss MetroBangalore. We wanted maximum participation here. This was the core around which the entire site was supposed to be launched. But surprisingly, there was not a single entry on the first day. By the end of the gruelling 5 days of the exhibition, where we worked our hearts out, we got about 6 participants. The CEO was furious and, understandably, the morale of the project team was low.

When we did the disaster analysis, what emerged was an aspect we had completely overlooked. Most of these girls came with their parents or families. Bangalore was not yet the “Open Society” as it is today. Many Middle Tier Bangaloreans were rather conservative in nature. In such a scenario, many of the girls who wanted to take part shied away at the last minute or were asked to move on to the next stall by their kin. And of course, like all good users do, they never bothered to return. Also, we never went to colleges or girls’ hostels where we could have got a better hit rate. We did not build in enough persuasive techniques, we could have done with more female staff, we could have done a “counselling session for beautiful skin,” we could have roped in former Miss Bangalore and given it a greater thrust. A lot of “could-haves” but then again, with hindsight ...

The lesson that emerged was crystal clear. We had just not done enough work on understanding who would want to be our participants. We were too caught up in the end users of the portal, the way one should vote, the publicity of it all etc., but we took the participation in the contest for granted. And it was a great lesson, one that I have not forgotten since then: “Know your audience groups well, and make all efforts to know them really well.”

Well, not the best experience after all, but then experience is the mother of the future. Like one of the speakers visiting our offices recently said, “life gives test first and lessons later.” An unforgettable lesson there.

Of course, the current exhibition at Singapore was not so dramatic. It was a regular affair and I had less to do, this time being only a spectator.

Back at the Client’s Offices

I was needed, by Bill, to attend yet another meeting, a demo of an existing module. The meeting itself was uneventful. We were shown their existing screens and the module objectives. We ended the meeting with them requesting a review of their current screens and a “proposed conceptual structure.” I was to learn later the difference in perspectives in terminology. And how different were they! We agreed and put a colleague of mine offshore to get the work started. Half my team was back in India supporting us in our tight timelines. The time zone difference enabled us to give out our requirements at the end of the day and expect something back at the start of the next day.

In the next 15 days, we put together a review presentation that highlighted the issues, in the current module, in terms of information architecture, non-compliance to brand, interaction design issues and content issues. And in the last couple of slides, a conceptual sketch based on our understanding of the app, and it came out pretty well. The day of the meeting, the same team and us met at 9 am in a conference room, all excited to share what we had learnt and get some more insights into their proposed enhancements to carry forward.

We spoke about the needs to redo the IA, pointed out several inconsistent interactions, a great many labelling issues and the overall scheme of things. I thought it was going pretty well. We did not get a single question in any of these slides and I, in all my innocence, thought that was a good sign. Probably my team had done a too thorough job of the review, I beamed.

When it got to the last 2 slides, the meeting had to be extended for another hour. The Conceptual Sketch slides were the ones they were all waiting for. Once we reached it, the people in the rooms dissected it to bits. They offered opinions about how this can be taken forward, what use cases it supports, what data needs to come where and so on. While this collage of activities and noises were going on, I was a bit perplexed. I tried to explain “This is a conceptual sketch, aimed at strategizing for the application, not individual use cases.”

The next question I got was a further shocker. “Where are the remaining wireframes?” “Wireframes?” I said aloud, “these are not wireframes but a structural depiction.” “Oh, OK. Complete the remaining wireframes by tomorrow and let’s continue the meeting again,” came back the reply, as if I had just spoken to a wall. I got the point that there is a vast gap between what the usability professionals mean and how the technical folks understand. Somehow, they understood concept sketches to be “finalized visual designs and concepts.” This event further added to my knowledge repertoire—never take anything the business or technical teams tell you on face value. As it happens in user interviews or business meetings, people explain symptoms and possible solutions rather than the real problem. The intentions of all the people are pretty good, but its the world each one of us lives-in, where we often tend to take the things we take for granted, as understood. For example, there was no need for a review here in the first place and probably if we had dug deeper, we could have gotten their real need, i.e. the scenario based wireframes. Everything else did not make much sense to them.

While we are talking about lessons learnt, a few more things are worth mentioning. While User Interface folks work with a whole picture in mind, technical folks work in teams that code a specific part of the application. For instance, there may be a team working only on the search component. No matter how hard you try to explain the big picture, it wouldn’t matter much to them unless you offer any inputs on the “Search Module.”

And in this case, somehow there was an unwritten rule that nothing must be taken from the existing system. An enhancement is viewed as an upgrade of features and functionalities. Quite often, re-designs are necessary because users find the system overwhelming, cannot understand too many things or just cannot get their primary work done effectively and efficiently. It may just be necessary to let go, when needed, to enhance the overall User Experience.

I can still hear the echo of some developers’ favourite lines. “Do not take away anything from the legacy system,” “Let us design for the worst case scenario,” and “There is a training that Users will undergo, so why are you making all the fuss of making it easier?”

While usability teams work with doing the IA, navigation, task flows and then the screens, the technology usually takes the opposite direction. Their focus lies on identifying the re-usable components to manage development efficiently and coding for the worst-case scenarios. In general, all these often lead to prolonged discussions and the group with the better negotiating power, research and reason get their way.

Finally ... December 2006

My sojourn continued in the hyper-charged atmosphere that took its toll on all caught in the storm. Many sub projects were launched. The development teams needed constant support; there were new wireframes needed all the time. The project had moved to high gear, with not as much as a breather available. A year went by but we managed to hang in there, somehow.

“Can I see you for a minute?” I heard a voice near my desk one day. I looked up to see the tall lean figure of Jean Wylie beside me. Jean Wylie was the Program Director of the project, responsible for its final delivery to clients and reported to the President of the organization. He reminded us of a military colonel but he was a very pleasant man to work with and talk to. Though I had exchanged casual greetings with him when we met in the elevators, we had never really exchanged anything related to the project. Now here he was, wanting to talk to me. “What might it be this time?” I wondered. A goof up somewhere or is it a new app design? I was to find out soon enough.

Jean offered me a seat. I looked around and noticed that his office was furnished quite creatively. He had beanbags, a couple of low chairs and some tables that were laid against the walls, for quick stand-up meetings. Though he looked and behaved like a military officer, his office spoke of a very casual atmosphere that encouraged creativity and problem solving rather than being a mundane complaint box.

“The project is a high profile one, you understand that, right?” began Jean. “It’s right under the scrutiny of the President. His ambitions for this product are sky-high. He wants this to be the biggest sensation of our domain,” explained Jean. He further explained the importance given to the User Interface and mentioned this was the first time ever they had hired a User Interface Team to actually see the project through to the end. “Not a surprise,” I thought, given the lack of understanding I had seen among the ranks here. “And although there has been stiff resistance to it,” he said with a wink, “you guys have delivered.” This was the moment I was waiting for. As a project manager of the UI team, this was the best news I had got in some time. If I was having a telephonic conversation instead of a face to face one, I am sure I would have jumped with joy. In this chaotic atmosphere, with many levels of disagreements and resistance, this called for a celebration.

He continued. “Your team has done a great job. You have exceeded our expectations. The product itself looks grand now and in the few demos we have had with our clients, they have loved the product to the core. We expect a great welcome to our product when it’s launched and are confident it will break our previous sales records. I would like to congratulate you on your excellent work.” I was speechless. I just wished my team was there with me to share the accolades but kept listening with polite thank you’s. He continued: “Now that you have done a great job of getting the designs and the framework ready, I want you to be the ‘cops’ of the design, i.e., bearers of the standards and responsible for the strict adherence to the designs. You are to ensure that all screens maintain the exact visual design specifications and let me know anything you need towards that end.” Now this was definitely a great turnaround for us. “Thank you Jean, I appreciate your good words and will ensure the screens adhere to the exact visual design specs.” I thanked him and left the room. I felt light and returned, almost floating, back to my desk.

This was definitely a great victory to the User Interface Team. With the grind we had gone through, it was great to get the major result every team hopes for, the management’s blessings. Of late, I had even noticed the development teams getting friendlier with the user interface team and participating actively in discussions. They had finally understood the need for the right UI. Now, with this major boost from the management, I smiled to myself, happily confident that from now on, at last, it would be a pleasure to go through the grind.

A happy start, our team agreed.

About the Author

Sudhindra V. Murthy is Associate Creative Director at Sapient and heads the User Experience Practice at Sapient India. Passionate about aesthetics and usability (“a washed car runs smoother”—Don Norman), his interests include exploring and developing interfaces that shape behavior and habits and those that create a positive affect. For over 12 years he has been working on various aspects of the User Interface and Interaction Design practices. He currently is involved in developing techniques and standards for Persuasive Design.

Passionate about aesthetics and usability, his interests include exploring and developing interfaces that shape behavior and habits and that enhance the quality of everyday life.

Sudhindra has over eight years of experience in the field of UI design and interaction design. His roles involved leading and guiding development teams in creating UIs affardable to users and overlaps visual design, human factors design, information architecture, usability, expert reviews and development of standards.

He is also the IxDA Regional Coordinator for the Asia region.

Web: www.sudhindra.in

Twitter: sudhindra

LinkedIn: www.linkedin.com/in/sudhindrav

I Am Feeling Lucky Strike Today

One day, a prospective client asked me to meet him to discuss some work over lunch. The weather was fine and at some point we changed the subject and started talking about websites, their souls and life cycles. Sitting in a quiet Belgian fusion bar in center of Kiev, I compared websites to living beings, suggesting they evolve like any other creature on our planet. The soothing ambient music accompanied our conversation and the imported Palm ale made things even more relaxing. I had to do something to stay focused, so I picked up the cigarette pack that was on the table and started explaining: “Imagine creating a site for Lucky Strike fans!”

I’d like to note that I don’t smoke and don’t encourage others to, either. The problem was, the cigarettes were the closest thing to hand; my iPhone simply happened to be a bit further away.

So, holding the cigarette pack right in front of my face, I said, “We start by launching a site for fans of—let’s see,” I looked at the pack, “Lucky Strikes. Those of us who adore these cigarettes would like to know that we aren’t alone in the vastness of the internet. So we start by counting like-minded individuals. Let’s show an image of a pack of Lucky Strikes to attract brand Nazis like us and place a button that says ‘I’m feeling Lucky Strike today!’ Visitors click the button and we show the number of times it was clicked. That will help our site to get underway and become at least a little popular.”

The pack of cigarettes I was holding was not just a collection of 20 coffin nails; it became a symbol. It became the start of a website starring everyone who visited it. I placed the Lucky Strikes at the center of the table and tried to demonstrate the button and counter with my hands, as if the table were a browser window. “This will be ok for a while,” I continued, “but users will certainly demand the ability to leave comments. Aren’t we eager to hear what they think about our fansite and favorite cigarettes?”

Here Comes Evolution

“We get tons of tweets, letters, and even a phone call from a guy who lives in Australia who likes our site a lot, but says users want to leave comments. So we add a text box for users to write something before they tell us they’re feeling Lucky Strike today. The site—” I said, holding up the pack of Luckies again, “—now makes us even happier; we’re not just counting people, we’re also reading what they think. The comments don’t differ much, though, and, well, half of them are spam.”

“Visitors now come to the site, read comments, write comments, take a look at the numbers and leave. But some of them come back and we experience …”

The Genesis of a Community

“Eventually we get more and more comments, the page numbers start looking like something off a scientific research site. It becomes obvious that we have more comments than a person could read at any one time, especially the conversations between regular visitors. They discuss how to smoke, argue against the use of graphical emoticons, motivate each other, banish spammers and write in flashing, eye-damaging colors.”

We had to stop here while the client took a cigarette from the pack. As he returned this avatar of an imaginary site to me, I continued, “Visitors return from time to time to read new comments—and to feed the trolls.”

“One day, it becomes obvious that the site design is not suitable for the sort of community we have built up. So we remove the image of the pack,” I moved the pack of Lucky Strike away from the center of the table, “and replace it with a logo. Also, it isn’t hard to notice that the discussions have become more factual, diversified and extensive. Most visitors come often and they write a lot. As the site creators, we decide we have no choice but to give them the opportunity to post using blog functionality so that they can write interesting stories and discuss them with readers and other bloggers in comment posts.”

I smiled at the client, saying in a low voice, “It’s the perfect time to go to BAT, the brand owners, and try to sell them the whole project.”

“So visitors come, post stories, tag those stories and we have to deal with it. The core community cultivates its traditions, its elite, its personal idols, etc. The number of registered users is huge, but at this point—how ironic—numbers don’t matter as much anymore. Remember how we started? Counting users. The site has become bigger, better and more interesting. Visitors start to discuss not just cigarettes, but also the community itself. So it’s off to British American Tobacco to start working on the details of the contract.”

“Time passes and at some point traditions connected with the site’s unique content point us towards the leaders of the community. Some of them post ads, some of them are youthful and funny and some of them are gurus ready to answer any question related to Lucky Strikes or anything else for that matter. It’s obvious that the blog structure is no longer useful to organize the stockpile of information we have, because we are receiving new posts faster than a smoker can light up a cigarette. So we redesign and reorganize the site.”

The pack of cigarettes returns to the center of the table.

“The image is back on the site but it’s smaller. We add blocks on different topics, thus minimizing the area for blog posts. It’s important to think about advertising at this point. Content on the site is now pretty diverse, so we have to separate it using graphical elements,” I said, using toothpicks to show separation on the table, “or just space.” Bye-bye toothpicks. I actually like space more.

“Now tons of people visit the site for various reasons, read news, enjoy the images and multimedia, learn something new in our blogs and increase the number of community members by joining themselves and inviting their friends.”

The client was sitting there silently, listening and waiting to see what would happen next to our imaginary Lucky Strike site. The changes and adventures taking place with our site while traveling from a simple counter to a big resource were astonishing and really looked like the evolution of a living thing. At this point, the site became not just an amusing toy but a responsibility and maybe even mass media. The potential BAT contract added another very good reason to like the idea of the evolution of the site. After a pause, with a sparkle in his eyes, the client asked, “So, what’s next?”

“I don’t know”, was my reply. “Maybe Web 3.0, maybe something so new we can’t even imagine it. From this point on, everyone is on their own and we have to try to be the first to know what will come next.”

The client thought about this for a while, took a long drag on his cigarette and finally looked me in the eye: “We’re in business.”

About the Author

Gennady Osipenko is the Creative Director of an ad agency based in Kiev.

Genn holds a Master in Computer Sciences. He has been Working in ad and design for more than ten years—being not only a designer, but also someone who explores how all the things work. As a UX consultant he has been involved with designing and launching some of the biggest Ukrainian news portals and informational sites.

Genn has won several awards. He can be found online at http://genn.org

Blog: http://mega.genn.org/en

Twitter: genn_org

Facebook: www.facebook.com/genn.osypenko

The Stamp

It took me a while to realise that user experience was my calling.

Don’t get me wrong: I had been fascinated by it for years, and was slowly but surely nudging my job description from analyst to information architect. I voraciously consumed blogs, books and Boxes Arrows and dreamt about life as a “proper” IA, but I was young and it was easier to stay in this university town with its cheap rent, beer and women, than make the move down South. However, my interest soon snowballed into passion and I knew that I had to make the leap. I took advantage of a well-timed redundancy offer and set off for London with a hangover and a new haircut.

London was everything I expected: vast, tough and quite unlike anywhere else in the country. I coped with the geographical transition surprisingly well—it was the culture of my new role that was the shock. I had landed an IA job at a well-known dotcom, and arrived at my skyscraper twenty minutes early fully aware that my horizons were about to change drastically. You never complain about an old employer, especially not in a book, and I am not about to here. It was a company that did a lot right and taught me a lot, but it was a big change from my cosy government job in the Midlands.

On my first day I set up my email, replaced the unfathomable mouse I had been given (apparently it was “ergonomic”, although I didn’t see how) and ordered my stationery. My boss then introduced me to the other hundred or so employees as “our new Senior IA”.

Senior? Two thoughts flashed across my mind.

“Shit, I’d better be on top of my game.”

“Shit, I should have asked for more money.”

Fortunately, everyone was courteous and welcoming and I started to orient myself to the job and the city without much difficulty. Sure, the rent was eye-watering and the overcrowding was stressful, but it excited me to be part of such a thriving community. I learned the Tube map and stood on the right side of escalators, eager not to appear an outsider or, worse, a tourist.

The job itself was fast moving and demanding. My employer ran a site that asked users for data, performed calculations and presented results. In many ways it was a pretty simple site. The real magic lay in the complex mathematics whirring away behind the scenes, which fortunately I didn’t have to concern myself with. My job was to make the input and output process as painless and even enjoyable as possible.

It is tempting to think small sites are easy. They aren’t. Every single change to a small site comes under intense scrutiny, meaning successful design is as much about stakeholder management as research and prototyping. In this instance, the scrutiny was doubled. On arrival, I learned that the site had recently been redesigned from scratch. I was stunned. I had assumed it simply needed some attention after a long time on the shelf; instead, what I had seen was recent work! The site was riddled with oversights and compromise, and stories of its difficult birth still lingered. After suffering through this painful redesign process for such a modest end result, management was understandably reticent to undertake more major design work.

Unable to make the sweeping changes I knew the site needed, I chose to steadily improve a page at a time. Boldly, I set my sights on the page in most need of my help. The results page was essentially an enormous data table that the user could manipulate, compare, sort, filter and select—you know the drill. The company earned commission from certain choices. A potential ethical quagmire, of course, but I was delighted to see that the company was very open about its revenue model and took a strong stance of fair play. Just in case, the watching eyes of the regulator provided another layer of security.

The results table was unclear and generally helpful to neither users nor business. Advanced functionality was thrown together with trivial controls, and users struggled to get it to do what they wanted. The page cried out for a complete overhaul, but given the politics and the revenue that flowed through it, I knew the business wouldn’t bite. Instead, I decided to improve it by stealth, fixing its mistakes until it reached a reasonable level of performance.

My eyes scanned the screen for the most egregiously awful problem. Eureka! The “stamp”, a scratchy little image that highlighted the best result. Illegible, ugly, pixellated, it was the sorest of thumbs on a poor page.

Alongside daily work of wireframes and meetings about new products, I made the stamp my pet project, as a way to earn leeway to fix other mistakes of the redesign. Trying to be politically astute, I took my time and jumped through the requisite hoops. I commissioned a series of new designs from our freelancers, passed them around the main stakeholders, sought opinions and explained why this work was necessary. Better visual weight, higher legibility, stronger typography, aesthetically harmonious—a no-brainer. Finally, I restated the case for user experience, explaining that it did not have to be as disruptive and difficult as it had been in the past. Little things can make the difference too, and hopefully this is just the first.

Some people were easy to win over; they thought the stamp was just as bad as I did. Others, indifferent at first, were eventually won over by my sweet talk. After many meetings and patient iterations, we agreed on the design and scheduled the change. I jostled to sneak this change into the user story backlog, and sent the file to the developers.

Ready.

Steady.

Go.

You already know what happened next. Within a couple of days, big red lines started slumping off charts and whispers started to reach me that trouble was afoot. Somehow the “designerly” stamp was not showing the best deal as clearly as the scratchy, illegible stamp. I mumbled something about statistical significance and giving it time, but eventually the data conspired against me in sufficient numbers, and the business chose to pull the tiny image rather than lose any further revenue.

Needless to say, I was embarrassed. My colleagues’ reactions were magnanimous—“I was as surprised as you”, “These things happen”—but I knew immediately it was the beginning of the end. After this failure, even the most minor design change would have to go through A/B tests signed in triplicate under the eyes of a watchful chaperone. I was right. Design steadily slipped down the priority board as the focus switched to more predictable disciplines, and within a few months I had thrown in the towel and moved on.

To salvage some dignity, I should say that it wasn’t a truly ignominious defeat. I enjoyed some notable successes that contrasted this blip, and I hope in my time there I improved the site more than I harmed it. But there’s still part of me that can not believe this small image made such a huge difference to conversion. There’s no sane reason for it to have done so. One might argue in retrospect that usability testing would have uncovered the reason for users’ negative response, but I wasn’t in a position to test each minor change in advance. It seems the site was at a precarious equilibrium. Its rough and ready appearance, all sellotape and glue, somehow worked. The “improved” stamp disturbed this balance and somehow the design made less sense to users as a result.

I’m the critical sort, but when I look back at this episode, I’d do it all the same way again. Instead of being a tale of mistakes and youthful naiveté, it is now a useful reminder to not be too sure of myself. Whenever I begin to feel too comfortable, too dogmatic, I stop and consider how my certainty over the stamp was so easily dispelled. Users can surprise us. Surprises are good.

About the Author

Cennydd Bowles leapt into the world of user experience eight years ago and hasn’t shut up about it since. He now works for Clearleft in Brighton, England and moonlights as a UX blogger, mentor and community evangelist.

Cennydd is a regular public speaker (SXSW, IA Summit), a widely published writer (A List Apart, Johnny Holland, .net magazine) and co-author of the book Undercover User Experience.

Cutting Through the Opinions

It was in the Nineties. Fredrik, a Swede and former journalist, was walking to his job. For a couple of days he had been working as a web editor for a Swedish public website.

Something was rotten on the website. There was this ugly button on the front page. An ugly button with a strange word: “Intranet”. Fredrik didn’t know the meaning of the word, but he did know he hated that button. It made the clean, functional front page a mess. While walking, Fredrik’s mind was occupied with one thing: he had to get rid of that button.

Fredrik was not an anarchist. He was a Swede. Swedes follow rules and regulations. So he knocked on the door to his manager’s office, preparing himself for the battle for the button.

“Intra-what?” responded the manager.

“Intranet,” said Fredrik.

“What in the heck is an intranet?”

“No clue. Maybe I should delete it,” suggested Fredrik.

“Maybe? You have to delete it.”

Fredrik was happy. He logged on to the server using FTP. There it was. The folder with the ugly and strange word. Intranet. If he eliminated that folder, then perhaps the button would disappear? With a satisfied smile, he pushed Delete. And then it was gone. The button was gone. And a big Swedish organization had lost its intranet.

Nobody seemed to care. Nobody seemed to notice. Until three weeks later. A librarian needed to publish something on the intranet. But the intranet wasn’t there.

It was in the Nineties. He didn’t know deleting wasn’t a wise strategy back then. Nor did he know he would be going to Oslo to kill a website some 10 years later.

Oslo

To go on, however—what can a decent man talk about with the greatest pleasure? Answer: about himself. Well, then, I too shall talk about myself[1].

I work with web content in Oslo, “this strange city which no one leaves before it has set its mark upon him.”[2] I love my city. Well, it’s ugly. The lack of planning has turned the Norwegian capital into a mess. Tall, futuristic buildings live unhappily together with neo-Classical architecture. It’s out of control. In the eastern part of the city, the police have totally resigned. I know it. I work there. I’ve been robbed there twice.

My city is like a website in the year 2010.

Here, in one of the most northern capitals in the world, I live my life. Go to work each and every morning. Take the subway to my suburban home at night. I don’t know what I like better, my job or my city.

I used to work as a journalist, a copywriter, an information officer, a UX-guy ... Working with communication is messy. Everybody has an opinion. And here, in my democratic and cold country, we pay attention to different opinions. Is this the reason why most Norwegian websites suck? I like to think so. Our websites are the cacophony of countless voices.

Our websites are like my city in the year 2010.

The Long Neck

There is a guy from Ireland who makes his living from speaking about the long neck. Gerry McGovern doesn’t agree with Chris “the long tail” Anderson. The mantra for Mr. Anderson’s theories is that “inventory storage and distribution costs are insignificant” in the age of the World Wide Web.

Let’s talk about iTunes. It costs iTunes almost nothing to add a new album to their library. If they sell, let’s say, 20 copies for the price of 10 dollars each year, they will earn 200 dollars. Not a sensational amount of money. But with a huge number of these low volume albums, the total would be decent. That’s what Anderson had in mind when he wrote “the future of business is selling less of more”.

What about content? Are inventory storage and distribution costs insignificant? Some web editors seem to think so. But, guess what, it’s wrong. Content is extremely expensive. It needs to be taken care of each and every day. Content is like fresh food. We need to manage the findability, constantly improve it, and delete or archive it when outdated.

If you have the resources to take care of 10,000 pages and still manage the findability; fine. But I seriously doubt the business case.

Maybe we should focus on the other end of the tail, the most important tasks, suggests Gerry.

On every website there is a “book a flight”. It is the small set of top tasks that your customers really come to your website for. The long neck[3].

Think about it. Why do you visit a municipal website? To find out more about the mayor’s occupations? To read the annual report? Or enjoy yourself with some facts about how the bureaucracy is organized? No? On one municipal website, I found that three tasks represented 90% of the users’ demand: apply for a place in a kindergarten, apply for building license, and, finally, get in touch with the right department. It was there on the web page. Buried in the cacophony of countless voices.

After 90 surveys in 15 countries, we know that five per cent of your website delivers at least 25% of its value. That’s your long neck. Amazingly, we have found that most organizations don’t know what’s in their long neck.

Every single colleague preaches their own long neck. Listen to them, listen carefully. Publish whatever they want. You’re on your way to making the most useless website ever; in other words an average website in the year 2010. When you start the journey, remember there is only one exit, the delete button. It’s free. Your next web project is not.

A Huge Website

A cold winter morning in Oslo 2009. Fredrik is standing outside the central station, looking for a guy called Eirik. No one’s there, except some tired humans waiting for their man to show up. And some old ladies carrying their skis.

Maybe he’s thinking something like: “Damn Norwegians. They have no discipline. No respect for appointments.” Maybe he’s longing for home, thinking, “what am I doing in this ugly city?” What do I know? I’m sitting on a subway train with no electricity. No light or heat. There is one thing you should know about my city: The trains don’t work when it’s too cold. And here it is often too cold.

Freezing his fingers off reading the map, he’s starting the short but cold walk through the snowy streets. Heading to the office of his new customer.

Innovation Norway is located in a rather new building, only some hundred meters from the parliament. Owned and run by the government, it’s a proper location.

First, let me tell you a few words about Innovation Norway. This is how they describe themselves: “Innovation Norway promotes nationwide industrial development profitable to both the business economy and Norway’s national economy, and helps release the potential of different districts and regions by contributing towards innovation, internationalization and promotion.” In plain English: they support Norwegian industry.

Innovation Norway has a website. Actually they have a huge website. There are 11 levels in the information architecture. How many pages? We’re not able to count. Nobody knows what’s out there. We only know it’s a lot. And it’s almost impossible to find anything, no matter what you’re looking for.

The website is pretty much like other Norwegian governmental websites. Well, commercial websites aren’t much better. In both cases, senior managers, junior mangers and other loud characters scream about what’s important: What should be on the front page and what the website should really have.

And, of course, there is a web editor. Editor? How I hate that word. Let’s clean up the language, and call it by its real name—web secretary. Web secretaries publish stuff when they are told to. They don’t care too much about the objectives. They don’t know their audience. They only know there is stuff to publish. And they do publish a lot. When you ask them if they know the content on their website, they don’t answer, “nope”. They laugh at you, saying, “are you an idiot? How could I be familiar with the content on a 10,000 page website?”

But Innovation Norway’s website is a governmental one and the web secretary for a governmental website also needs to consider legal issues. In my beloved country, governmental institutions have a duty to inform. And I can assure you, there is a lot of information in those institutions. So, they need an information dump. Nobody cares about the information, nobody visits the website to get informed, and all the nonsense buries the important stuff. But who cares. Respect the law. Welcome to our governmental website.

Fredrik once deleted an intranet. Now it’s time to delete websites. Not by accident this time. As Alan Cooper once said: “If you want to create a beautifully cut diamond, you cannot begin with a lump of coal. No amount of chipping, chiseling, and sanding will turn that coal into a diamond.”

Cutting Through the Opinions

I meet Fredrik in the reception of Innovation Norway. He is cold, but polite. Swedes are polite. The hunt for the long neck has begun[4]. What is the “book a flight” on Innovation Norway’s website?

Some weeks later we have:

1. evaluated the current website.

2. analyzed the goals and objectives of the website.

3. interviewed 20 customers.

4. interviewed 10 stakeholders within the organization.

5. analyzed the customers’ search behavior.

6. examined similar websites for important tasks.

Well, we now have about 1,300 possible tasks. Should we ask the users what’s most important for them? To pick the top 5 from a list longer than the long tail of the Library of Alexandria?

We have to make it shorter, by identifying duplicate or near duplicate tasks and eliminating minor ones. It will take us some weeks.

Final workshop. The list can’t contain more than 100 tasks. Where are the senior managers, junior mangers and other loud characters? They’re sitting here together with us. They have to prioritize now. We’re not leaving the room until we have only 100 tasks or less.

Done.

It’s time to meet the users. It’s time for them to choose their favorite tasks. No more than 5.

After the survey, we know what the customers really want when visiting Innovation Norway’s website. And, not surprisingly, they want money.

Here is the top list:

1. How to apply for funding and grants

2. Start-up grants

3. Financing—how do I proceed?

Now what? The top management has statistical evidence of what the customers want when they visit the website. But are they going to give them what they want? This is the moment of truth. Now they have to choose. Choose between:

1. Understanding the wisdom of the web as a pull medium and rebuilding the web page.

2. Ignoring the customers and building a website nobody cares about. Maybe spend some silver on a fancy Flash animation with no “skip intro.”

3. Keeping the existing site. As an ugly mirror of the city outside the windows.

The top management chose the first option. The long neck.

Spring

Spring 2009. Winter is about to leave my city. As I walk on the slushy pavement, I recognize the salty smell from the fjord melted by the sun. Far in the distance, a boat whistles; its call is passing the harbor. A block, then another, a building, another block, farther and farther ... It is summoning the whole city and the sky and the countryside, and ourselves, to carry us all away, our websites too.

It is time to push the delete button once again. This time, it’s not by accident. It’s time to build something new. Something manageable. Something valuable. Based on facts, not opinions.

Let’s hear no more of all this.

About the Author

Eirik Hafver Rønjum works as a senior usability specialist for NetLife Research in Oslo, Norway—one of the market leaders in the field of user interaction and usability.

Eirik has a degree in information science and literature. Working as a journalist and writer for over 10 years has given him a passion for web content.

As a former information officer and web editor, Eirik is able to see the challenges from his client’s point of view. He has helped various organizations manage their content. In short, he knows what works and what doesn’t. The only way to make quality web content is to adopt a task-centric approach.

Eirik also has lots of experience with concept development, interaction design and information architecture. He has managed several major web projects.

[1]. Quote from Notes from the Underground by Fyodor Dostoyevsky

[2]. The beginning of Hunger by Knut Hamsun

[3]. Definition of the long neck: http://www.customercarewords.com/the-long-neck.html

[4]. The methodology is described more in detail here http://www.customercarewords.com/how-it-works.html

Culture Shock

Welcome to Denmark

Denmark, to an Englishman, can be summarized with four words: beer, bacon, butter and bricks. (Lego of course!) There is another “b”—the beautiful people that live here and that was how I was introduced to this small, fascinating land, through my girlfriend (and now wife). It immediately felt like a place I could live in and Copenhagen has a very human scale to it that is not found in all capital cities.

Making the leap to uncharted territories was always going to be tricky. Doing it in the world’s most severe recession for 70 years was just going to make it a little bit harder. A month before the move, our English mortgage fell through. But we made it, thanks due to a friendly Swedish bank. As the crunch became a crisis, I knew that if we had left it a few more weeks we may never have made the move.

Hello Hello

To be honest, the adjustment period of moving from London to Copenhagen never became an issue as there simply wasn’t any time to settle in. I landed on the 11th August and started work as a Senior IA on the 12th at Hello Group.

The company had grown to be the fourth largest in Denmark in less than three years, specializing in engaging user experiences with a particular focus on appropriate use of technology. My job was to be responsible for the information architecture and interaction design of our solutions and also the concept development of new projects. I had also been hired to provide a UX process for the company (now known as UXBASIS).

It was a crazy time. Not least just getting my head around a new culture, a new home and a workplace that was far removed from the B2B publishing world that I had come from and been a part of for eight years. I was also to become a dad in December, with my wife heavily pregnant and intent on painting the whole house before she gave birth.

Agency life very quickly taught me that work life is harder, more challenging and, although demanding, is generally more interesting than corporate work. I could not foresee at this stage how cultural differences would come into play.

My first project was a pitch for a company who were as Danish as they come. Fritz Hansen is renowned for its beautiful furniture made with the most exceptional craftsmanship, created by designers who go down in history as perhaps the most influential in the post-modern era.

Ten years previously, I had owned my own very small web design firm in Sevenoaks, Kent. It was just before the dot com bust and, if anything, that experience gave me the ability to think on my feet and be productive quickly. What I realized here was that workers in Denmark, although outwardly having a laid back appearance, the underlying work ethic is to work hard during your hours and then have the quality time once those hours are done with. The lunch breaks were shorter, the idle chats around the water cooler just do not occur because the aim is to get the job done. That’s not to say they don’t party but all that happens after hours, from about 11.30pm actually (yes that is UK pub kicking-out time).

Introducing Fritz Hansen

So the first week was hectic as I had been brought in on a pitch to get the FH job. I had to admit it was a little daunting to be working on such a high profile client for my first task. We worked hard in those few weeks to formulate the presentation and I decided to use a process to get the conceptual work nailed. We very quickly drilled down into the different elements of what the client’s vision was for the site. The brief I was given was very comprehensive, and had been written by Peter Svarre, UX director of Hello Group, who was also a partner in the business. This was obviously a client that they would dearly like to have and an impressive name on any Danish design agency’s client list.

Despite the comprehensive brief, the project itself suffered from the halo effect that everybody was excited by the prospect and clamoured to be involved. There was also a palpable fear of failure in the initial team. It meant that everybody had an opinion that needed to be heard, which is something that is very evident in Danish society in general. Companies have flat hierarchies where conversations with the CEO are welcomed from any level of the company. Politics is considered serious business, there are numerous parties and to pursue politics as a career is considered an honourable occupation, a somewhat different view from that of the UK.

The initial project manager had a hard time getting a firm grip on a project that had limitless creative opportunities but had to answer so many business needs on a corporate and a customer level. The team at the pitch stage was chaotic and complex. We had to rely on an external designer to visualize the wireframes as we lacked resources. It was a time that I had to rely on my design management background to brief the designer to produce something visually arresting, whilst still being technically possible. All of this needed to happen to a pitch deadline.

The unusual part for me was that I had to investigate the UX of the website fully to gain a holistic view of what we were suggesting, before we had won the pitch and which had not been clearly defined by the client. At this point we were going off our own assumptions of what we felt the company needed. So the definition of the user experience was for us to map out and explain to the client.

Very quickly it became apparent that Fritz Hansen needed a platform for its company image and communication. Also for the dealers who sold their products, the customers who bought the furniture and architects who used the drawings of the products in their renderings. This was a group of people who all had different demands and on the fringe of the core group we had people who could be best described as fans—those just interested in the many landmark products the company has produced throughout the years.

I produced a concept model, which helped anchor in the groups’ mind what we could do immediately and what may be preferable in later phases. It was a good start and it is something I usually look on to ensure the target groups wants and that needs are satisfied. It is nothing more than a diagram with the user at the centre, their requirements of the site and features radiating out from this start point. This time it was just for a little security, a blueprint or roadmap that at that moment needed a plan to be laid out.

One thing I knew instantly was that this team of people was passionate about the work they were doing. Some were perhaps too emotionally involved with the product and their views began to influence the design. At this moment the account manager was replaced by Lasse Vakgård who had project management experience from another notable big Danish brand—Royal Copenhagen, famous porcelain manufacturers to the Queen of Denmark.

Shifting Gears and the Configurator

Perhaps it was this that immediately transformed the project from a load of creative ideas to something more business focused and tangible. Having a new person on the team helped focus our attention on specific business objectives alongside the design team’s concern for the quality of the user experience.

I set to work on building the information architecture and interaction design requirements for the product configurator. The need of the configuration system was that it had to build any piece of furniture possible, online and with accompanying fabrics. Not too hard you would think but consider one chair has over a 1000 different configurations and you start to see the challenge.

Everything the configurator produced on screen had to be possible to build in reality. No combination of material that could not be made into furniture would be displayed. I pored over the technical details, product catalogues and sample sheets for days. This was a huge inventory to display online and it would eventually have to support online ordering of the products.

The interaction design of the configurator had to be intuitive but also simple. Balancing the complexity of showing the huge range of fabrics and furniture models whilst maintaining a feeling that one could play with the interface to compose different bespoke creations was a challenge. The design of the page needed to relay this information transparently and without visual noise. Step forward Thomas Petersen.

TP’s Design Engineering

The first time I really met Thomas was at the factory headquarters north of Copenhagen. We had just delivered our initial plan for the site and Fritz Hansen had agreed to us building their site. At that stage there was no ink on paper but we were confident that they liked what they saw.

Another element of doing business in Denmark is that there still seems to be a gentleman’s agreement when it comes to a deal. Signatures are a formality and trust is a massive part of a working relationship. The term “partners” in Denmark, really means it, and the strength of a network is much more binding and has more longevity than in many other countries.

Thomas is a founding partner of Hello Group and a very skilled designer. What struck me about Thomas was that he described his vision for the site in very simple terms. He has an unusual knack of telling you how it should be, and not only is he persuasive but you trust his judgments. He describes himself as a design engineer, not a visual or interaction designer because in many ways he thinks about the mechanics of interactions and technical capabilities as he designs. So as we built the interaction plan for the site he was also assessing the technical delivery of the system. He thinks of digital design in a very similar way to product design. It must have a purpose, an end goal that the design fulfils unequivocally and it must look, and most importantly act, like it can deliver on its promise.

Once confirmation came that we had the job and ink was on paper the UX rolled on from site structure diagrams to wireframes. The client, Emarketing manager Louise Juhl, had a great way of getting the most out of us. She had an unenviable task of satisfying her directors and heads of department, keeping Hello Group fulfilling their commitment and planning the strategic direction for phases beyond launch.

New Arrival

What happened next was expected and amazing. I became a father to a baby girl, Lara Kelway on December 13th 2008. Both wife and baby were doing fine but work ground to a halt over the next three weeks. Christmas, from what I remember, was a surreal blur. Spending three days in the hospital after the birth and waking up at 6 in the morning to an earthquake, were one of the oddest experiences and one that people just shrugged off and got on with. Another day in Denmark.

By the time I had returned to work my input into the process had moved on. As I was missing physically from the project it meant I was not a part of the transition from plan to build and I was a little sore about that. I came back and went full on into a new project about intelligent homes, both fascinating and disorientating at the same time.

I learnt again that you cannot be too precious when it comes to projects. In an agency you are a resource that is used and the job moves on without you, it’s a matter of fact and in no way is it considered unusual. But professionally you still retain a responsibility to a project as it progresses. Having the passion for your work invariably means you care about it after it leaves your desk. In an agency you are afforded the luxury of seeing it develop, but it takes an inquisitive nature to pursue how it forms.

Recession Bites and the Site Launches

During the development of the site Fritz Hansen and Hello Group were victims to the recession, layoffs were occurring in both companies. Politics was also playing a part with certain departments wanting to be represented on the navigation structure of the site. The whole process from pitch to launch party took a year and hundreds of man hours.

So what did I learn from this experience? I found that my colleagues were dedicated, talented and unwilling to see the project fail. They put so many hours of their own into making sure the product was delivered to a standard they would stand by and be happy with. At a cost greater than the client paid for.

It was not an easy project and I have no doubt they would approach it differently if they did it again. The configurator has some issues that are being ironed out. These derive from subtle nuances that were lost in development as they were re-prioritized during sprints that fell off the backlog pre-launch. These slight details make the difference, of course, between good and excellent on-screen interactions.

Despite this, the site is a great achievement. It has a CMS that allows the company to manage their own content. It speaks to customers, dealers, architects, employees and fans of Fritz Hansen all in one place. It has an abundance of content and a valuable historical view of the furniture brand that has so much design history.

Cultural Integrity

But something really struck me—culture influenced the design here. It is often something we are aware of but do not consider on how far it impacts us as we design. In many respects any design artefact is a direct outcome of interactions between designers and their environment—the cultural landscape that they operate within.

Consider the culture of Hello Group, a collective of individuals with very different talents and different ways of working. The company has a multi-faceted personality. Fritz Hansen, a globally famous brand with so much heritage and a pressing need to combat the copies from other countries who are counterfeiting their furniture with poor quality and inferior products.

The people at Fritz Hansen also had a passion for their work and common ground was found between these very different companies. This difference in corporate cultures helped to create a positive energy that would be hard to replicate in an internal studio tasked with completing a similar project for another department.

The culture of these companies is also a product of the Danish way of communication. There was a transparency shown throughout to the client, an honesty when things were against us that was appreciated and understood. It made me think how different countries are in the way we try to cover up. In the UK when we are seriously challenged we put on an appearance as if all is fine. The stiff upper lip can easily seem like a shield to hide behind rather than the showing of fortitude to get through things when times are tough. Sometimes honesty is the best policy.

The website is still being developed, refined and iterated upon. Like all good sites it is developing its offering, answering changing goals and emerging opportunities. The site has provided the company with a platform to launch other initiatives from and reflect its brand in a way that is engaging and speaks to so many different audience types. It is a product of a collective vision certainly and a great example of two company cultures combining to produce a site that addresses so many needs.

On reflection, my first project was a success, it launched to acclaim, though surprisingly little fanfare, in the design community. Perhaps another feature of Denmark is you will not see much “blowing of their own trumpet”. Denmark has a lot to offer the world in terms of talented designers and architects and I am still amazed that there is a very small community of UX people here, despite the fantastic interaction design courses offered and attended by students from all over the world.

Design Is Everyday

Perhaps it is because good design is considered just a natural approach to making things here. The design of objects, products, buildings is executed so well because the functional basis of the work must stand up to a public scrutiny that will be completely honest and devoid of what one’s reputation may be. Scandinavian design is unique because of the culture it derives from. Why design something new if it does not do it better? Improvement is another element to the Danish way, a quiet understanding that the first iteration is just the start.

Nothing is complete in the digital environment, it can always be added to, reworked and made better. The Danes share this view, they are progressive in nature, they look forward as opposed to the British fondness of looking back. Even in telling the time the English say half past four, whilst in Danish it is halv til fem, translated—a half to five.

This optimistic and forward thinking attitude has seen some great buildings establish themselves. The Royal Opera House is a case in point, dominating the skyline when seen from the Queen’s palace. Would a new building ever be built in front of Buckingham Palace? I seriously doubt it.

The English Patient

I am still adjusting to life here. The impossible language, the hard winters and interesting customs all challenge you in different ways, but there is a real charm to Denmark. You see it in the lifestyle, the people and the things they make. Scandinavian design has a distinct clarity, an approach that seems too laidback to an outsider but produces outstanding results. Seemingly effortless in their delivery, the secret is the rigour of their approach to work that is present at every stage in my experience. A constant pursuit in reaching the end goal and being successful as a consequence, but never bragging, just moving on to the next challenge.

I am a Scandinavian convert and I can see I am changing. It is the product of living in a different cultural background that is shaping me into becoming something different. I still cling to my own cultural baggage, whether it is Marmite or PG Tips, or the ability to see Match of the Day weekly.

I wonder if these badges of Britain will fade, or become more accentuated and important as my time here goes on. They are a part of my culture and a part of me. Undeniably a part of what I am and what I do has traces of my personal cultural background. Tacitly it exists and reveals itself in my work. Not unlike contemporary influences on design, this personal library of references is ever present. Useful or not, it remains and cannot be removed.

The home comforts will never leave me and thus I fear I will always be an Englishman abroad, maybe fitting in but with that funny accent and island race mentality. But being here has opened my mind. I see things from the other side of the fence because I must, and that can only help me become a better UX designer.

About the Author

James Kelway is UX Director at Hello Group in Copenhagen Denmark. Previously he worked for Reed Business Information, a part of Reed Elsevier, for over 8 years, in a variety of roles. While working as a digital art director, he studied for a Masters degree in Design Practice, specializing in UCD techniques.

After qualifying, he became an information architect and was responsible for the formulation of the business’s information architecture strategy, its implementation among several teams, and the redesign of several major industry websites.

On his blog, User Pathways, James records his findings, as well as developments in information architecture, interaction design, and user experience.

Web: http://userpathways.com

Twitter: jameskelway

Hello Group website: www.hellogroup.com

UXBASIS website: www.uxbasis.com

Fritz Hansen: www.fritzhansen.com

Shaping Spaces

From Archivist to Information Architect

Digitising Finding Aids

I started out as an archivist. As a history student, I found a part-time job writing descriptions of the records of the district attorney and attributing keywords to them. Most of the records concerned petty crimes or car accidents in the 1950s. The photos of the accidents contained contemporary street views otherwise seldom found, and the records of suicides were both gruesome and fascinating.

What made the job interesting was that at the time the archives had just started digitising their finding aids. During my studies at university, library catalogues had gone from card indexes to stand-alone digital catalogues. When I was writing my thesis in the mid-1990s, the latest achievement was remote access to other library catalogues. The complicated and lengthy procedure of logging into external databases was explained on slips of paper taped to the table next to the terminals. Tedious as this may sound today, it was far easier than cycling furiously up and down the hills of Zurich and trying to leaf through the index cards of as many libraries as possible during their restrictive opening hours.

The excitement of this new age and the goal of greatly enhancing access to unique records made my work at the archives meaningful. Moreover, I quickly learned that without the work of arrangement and description, the records in the archives were worthless. The example of a colleague of mine who returned from a cable car company with four huge sacks of paper might demonstrate this. Nobody knew what was in those sacks, and no-one cared to take the time to sort the papers out. In this form, the contents of the sack were downright useless. I’m not sure if anyone ever had the courage to ditch them, or if they are still sitting in some abandoned corner. But dealing with large bodies of potentially messy records and trying to fit them in the context of their origin is an important part of what archivists actually do and they have developed sophisticated methods for it. Standardisation, however, is not their strong point. Therefore, when we began digitising, the challenge was to convert all the finding aids, which were as heterogeneous as the materials they listed, into forms that could be aggregated at a higher level.

Thinking About Users

It was this new possibility of aggregation of data that sparked my interest in users. During an internship at the National Archives of Australia in 2000, I was assigned the task of carrying out a study on how seamless access to archival descriptive data might be realised over the internet. The Australians had already made a fair amount of data available online and as a foreigner I realised how helpless I felt trying to make sense of the results of my queries to the Australian archives. Furthermore, I noticed that the questions the Australian users posed via e-mail could seldom be answered by conducting a database query. Aggregated or not, archival data are not as detailed as users expect them to be and it needs much experience, or the help of an experienced reference archivist, to find the relevant information.

On returning to Switzerland, I started looking for adequate forms to present archival information online. Up to that point, the archives had only created categories of users, rather than categorizing the questions they had asked. However, these categories, e.g. professional researchers, hobby historians or journalists, did not prove to be particularly helpful for designing web access to the 40,000 shelf metres of records. I thus started out by gathering empirical information and analysing several hundred written inquiries to the archives.[1] From this study, I learnt two things in particular:

1. The expression of the users’ expectations, in their own words, did not match the way the archives categorised their holdings.

2. The archives lacked a concept of the process, the research process in this case, that users go through.

First Steps as an Information Architect

I guess these insights sort of marked my birth as an information architect, even though I did not realise this until years later. But explaining to others what I was doing did not become any easier. Most people do not know the difference between libraries and archives, let alone imagine what people working in those institutions do. As an archivist, the easiest way out was to let them believe I was a bookish person and they would mostly stop asking. But when I started doing the work of an information architect, even my colleagues at the archives were not able to understand what I was doing. Today, I usually mumble something about “internet business”, which intimidates most people enough (a woman in IT!) to shut them up. If they insist, I readily admit I have no idea of programming and they usually end up exclaiming that what I am doing is “a far cry from history!”

As an information architect, I later learned that the lack of knowledge about users and their expectations was in no way specific to archives. Or, to put it more precisely, it would be unfair to accuse archivists who deal directly with users of having a lack of expertise and empathy. But conducting a dialogue with individuals, eliciting their needs and knowledge, does not translate easily to the web. On the web, users are usually expected to take care of themselves. That sets the bar high, for users as well as for information architects. I jumped in at the deep end and came up with the idea of a “virtual orientation room” for the archives.

What is Information Architecture About?

The Metaphor of Architecture

I had picked up the metaphor of the “virtual reference room” from Kim Veltman at the summer university in Maastricht in 2001 and transferred it to the archives. My idea at the time was to create functionally different spaces for different stages of the research process at the archives. The spaces were to be connected by “doors” in order to account for the iterative process that research represents. The spaces were on the one hand designated for clustering the different types of finding aids and on the other hand to give the researchers room to conduct their work and store the results. I used the image of the (then still operative) Round Room of the British Library. Recently, I discovered a convincing modern equivalent, the Amsterdam Public Library (Openbare Bibliotheek). The enormous library creates different types of space, cosy corners for reading, ready access to catalogues and other resources close to the shelves, closed rooms for study or discussion, ample space for kids and some breathtaking views of the city.

Having something similar in mind, I was fond of my idea of the spatial metaphor. All I had known, so far, in the digital space had been lists and tree structures. The consultants I worked with at the time, amongst others, from Zeix, the company I would be joining later, argued it would not work on the web. Just take a look at the screenshot below to see a few of the problems:

http://www.post.ch/post-startseite/vps-virtueller-postschalter.htm

1. This post office is completely empty. Both customers and clerks are absent, a sign that it must be closed.

2. The spatial arrangement does not help users to find their way around, and neither the look of the counters nor their location in space make it clear what they are for. The benefit of icons is, as usual, questionable.

3. The metaphor of the post office has its limits. What is the e-mail icon doing there? Services provided at a real-world post office do not necessarily match those offered online.

Information Space

In the real world, spatial arrangement does not always increase orientation either. The reason for spatial arrangement is its necessity. Counters and clerks need room and they have to be arranged somehow. The skill of good architects is to use space to create atmosphere. However, creating atmosphere in the virtual world works differently: by having valuable content, attractive functions, simple and intuitive use and good design. And orientation, in the rather straightforward case of the post office, is best created by clear categories with simple labels.

My approach to the virtual orientation room, however, did have its parallels with “physical” architecture. Its aim was to create different forms of access for different needs, whether it was for users at the very beginning of their research, like foreigners having to identify which Swiss archive might have some material in the first place, or regulars who quickly wanted to check on some details. Catering to the different needs of users as well as different levels of previous knowledge is crucial for all information architecture. Whether novices or frequent users, they should feel comfortable in the process and be confident that they know what they are doing at all times. No matter what data we work with or what may be the requirements of the information suppliers (our clients); while they account for the material we build our concepts with, we must always step in the users’ shoes to design access. This is, in a nutshell, what I believe information architecture is all about.

Real Users

Still, creating access in the virtual world is different from the same task in the physical one. The metaphor of physical architecture works well for the principle of creating access, but I believe it reaches its limits in the way it is achieved. Physical space has its borders, whilst information space thrives on its complexity. More often than not, your user does not know what she or he is looking for. It is not like looking for a certain classroom in a school, or the ladies’ room in the theatre, or the aisle with toothpaste in a supermarket. Looking for information is a complex process and has a lot to do with decision making, something that many humans have trouble with. There are many theories about information gathering I find very useful but will not go into here.[2] In my everyday job, I want to find out about problem solving in the concrete case. Does my mock-up of a recipe database help people find what they want to cook? What are their criteria? Do they make their choice based on a mouth-watering photo, the ingredients they might or might not have available, the time needed to fix the meal, or something else? How do people go about booking a flight? Do they actually book online or just gather information? Do they book immediately, compare other platforms, switch to their favourite airline, or first talk the options over with their partner?

This part of the job is, for me, one of the most enjoyable ones: dealing with real people and their everyday needs, troubles and ideas. While conducting usability tests for our company, I have observed teenagers looking for their future profession, traders speculating in shares in the most varied ways imaginable, senior citizens playing games on their mobile phones; I have watched and interviewed patient, unmotivated, intelligent, conceited, witty, insecure, funny and unintentionally funny people, and many more.

Collaborating on Information Architecture

The Need for Co-operation

No matter what kind of people we are working with, we want to create a seamless experience in the virtual world as well as across the boundary to the “real” world. It takes a lot of study and knowledge and attention to detail, taking into account both the general and the specific structure and the “interior design” as well. Sloppy information architecture results in unfinished structures, stairs leading nowhere, buildings without bathrooms or windows and a cold, impersonal and barren feel, like the virtual post office pictured above. In all but the smallest projects, however, information architects hand over the elaboration of details and the implementation in general to others. I mentioned earlier that my fellow archivists had trouble translating their knowledge and processes into the users’ language and that they were not the only ones. It also holds true for many of the people who continue our work. They are experts at what they do, programming, graphical design, copywriting, etc., but it is our trade, not theirs, to advocate users’ needs. We have to work together to achieve optimal results, but this is often easier said than done.

Obstacles

We often work on projects where the content of the website is created by a large number of copywriters (i.e. content authors) who almost always have little time and often little motivation for this additional job. In particular, they do not take the time to understand the ideas of the new information architecture, even though we take great pains to carefully document them. The same holds true for the programmers. We find programmers adding “search tips” to our lovingly elaborated and user-tested search; instructions we know will confuse rather than help users. We see copywriters creating new containers in the content management system that have exactly the same function as containers already available in our design. More often, however, copywriters make much too little use of means of structuring their content and of guiding their users through the process of focusing on a particular subject.

It is often a frustrating experience and it is easy to put the blame on others. But because we are the people who care about getting the user experience right, and because our clients are always in a hurry to meet deadlines, make money, prevent losing money and make us rush, even if they don’t have the time to review our work, I believe it is our job to develop better means of communicating to others the things that we consider important.

Creating a Common Cause

Recently there has been a lot of talk about “content strategy”, a discipline I believe will help us go in the right direction in content creation or copywriting.[3] Some articles accuse information architects of neglecting the “interior design” of the sites they have designed. I’m sorry to say I can understand this accusation. Many web or graphic designers do not take the content of a web site into account when creating the structure of the site. However good copywriting and good information architecture complement each other in creating a great user experience. Therefore, we have started to integrate more findings of content strategy into our documentation and we are anxious to find out if this will improve results. However, this is still a one-way form of communication. Our meticulousness should show that we care, but the people who read our documentation might also find it annoying.

So should we treat the people who “build” what we have “designed” the same way we treat users? Should we try to make them happy instead of giving them instructions or imposing rules? My answer is yes and no. We should make them happy, but not by giving them the choice of whether they want to implement our concepts or not. It is our expertise and it is our responsibility that what we design will work in the end, and that users will achieve their goals and feel confident on their journey. Our clients are convinced of our skills; after all, that is what they are paying us for. The people in charge of implementing our concepts, however, do not necessarily appreciate our work. Treating them as we do our users is probably not the right answer. They are part of the team and should feel that way. If we want fruitful co-operation, we must convince programmers, designers and copywriters that we are not merely there to cut their budgets. Our concepts and documentation do not interfere with their work, they are the foundation that allows them to concentrate on their own areas of expertise. I believe that as a company and as a profession, we are still at the beginning of this process of mutual understanding, of creating a common cause, and I don’t claim it will be easy.

Speaking of a common cause—in my opinion, the worst thing we can do at the moment is to put obstacles in our own path. At the Euro IA 2008 in Amsterdam (the European Information Architecture Summit), several participants asked me if I was a UX or an IA, a user experience designer or information architecture specialist. I was flabbergasted. I had never considered the difference as being important. At our company, we work as a team and combine different skills and views. As long as people outside our circles don’t even know we exist, let alone understand what we do, we definitely should not get lost in petty quarrels about the definition of our profession. We should concentrate on raising awareness that user experience matters and that there are specialists around who can create information architectures that are convincing for all parties involved.

About the Author

Andrea Rosenbusch is a partner in Zeix AG, Agency for User-Centered Design in Zurich, Switzerland. She specializes in the information architecture of complex websites and applications, particularly in the fields of e-government and transportation. Before joining Zeix, she studied history, economics and linguistics at the University of Zurich and worked in the field of access to digital data at the Swiss Federal Archives for several years. Out of the office, she is usually on the move—physically or in the virtual realms of the web or fiction.

Web: http://www.zeix.com/unternehmen/ueber-uns/team/andrea-rosenbusch.php

[1]. The study was based on the idea of Wendy M. Duff and Catherine A. Johnson, A Virtual Expression of Need: An Analysis of E-mail Reference Questions, in: The American Archivist, Vol. 64, Spring/Summer 2001, pp. 46-60.

[2]. E.g. Marcia Bates, The Design of Browsing and Berrypicking Techniques for the Online Search Interface, in: Online Review 13, October 1989, pp. 407-424, http://www.gseis.ucla.edu/faculty/bates/berrypicking.html; the “Polar Bear Book”: Louis Rosenfeld and Peter Morville, Information Architecture for the World Wide Web, 3rd (revised) edition, Sebastopol 2006; James Kalbach, Designing Web Navigation. Optimizing the User Experience, Sebastopol 2007.

[3]. E.g. Rachel Lovinger, Content Strategy: The Philosophy of Data, in Boxes and Arrows, March 26, 2007, http://www.boxesandarrows.com/view/content-strategy-the; Kristina Halvorson, The Discipline of Content Strategy, in: A List Apart No. 274, December 16, 2008, http://www.alistapart.com/articles/thedisciplineofcontentstrategy.

How to Love and Understand Your Audience by Probing Them

Introduction

Now that I have your attention, I’ll let you in on what I’m really talking about.

The probe I’m referring to is a cultural probe, which is an in-depth, ethnographic research tool used to generate real audience insights—without spending thousands of dollars or investing months of effort.

In this story I’ll share with you my recent experience of using one. I’ll talk about how it enabled us to be innovative in our product design and share some of the tips I picked up along the way.

An Interesting New Project

Once in a while a project turns up that has nothing to do with directly improving the user interface and everything to do with developing a deep understanding of the audience. Typically, this is because the stakeholder who owns the product wants to obtain an insight into the needs, behaviours and philosophies of their audience. Armed with this, they can forge a product strategy that meets both user needs and business goals.

This is the story behind one such project. The client was a large music ticketing site in Australia. The goal was to generate a comprehensive behavioural model of what the audience was doing in the music space (i.e. how did they find out about gigs, what was it like to attend a gig etc).

Opportunity to Experiment

A great user experience is grounded in the insights gained from understanding users’ needs, behaviours and motivations. One powerful way of gaining this insight is by simply observing users in their natural environment, often over a long period of time by means of ethnographic research.

For this project, ethnographic research was precisely what was needed, but we didn’t have either the time or the budget to do a full scale longitudinal project

This constraint provided an opportunity for me to experiment and apply an alternate method that I hoped would achieve similar results without the long timeline and expense characterised by pure ethnographic research.

Enter the ‘Cultural Probe’.

What is a cultural probe? Well, to help understand the principles behind it consider the first lunar missions. Humankind, up to that point, had very little understanding of the nature of the lunar landscape, so to find out more information we sent probes to the surface of the moon to transmit data and visuals back to Earth. This information was then used to construct a model of what the surface of the moon was really like, without a single human having made any direct observations.

A cultural probe can be thought of in a similar fashion, but instead of a probe being sent into space it is sent into the lives of an audience, returning rich data and information which the researcher can then use to construct a model of their lives.

Sounds complicated, huh? Well, honestly, it’s not. Typically a cultural probe is simply a paper or video diary that the participant keeps for the duration of the research. The idea being that in lieu of the researcher directly following and observing the participant in their everyday life, the participant recounts it for us.

The Problem With Traditional Probes

Paper or video diaries and other traditional forms of cultural probe are often problematic for several reasons. Firstly, they are largely asynchronous and self referential (i.e. I talk about my day through a frame that I think is important). So, for example in a traditional probe, at the end of each day the participant would record the significant events that took place during the course of the day in their diary. Unfortunately, much of the minutiae and richness of the everyday is often lost or forgotten in this edited and processed view that the participant takes in their diary entry.

Also, there are other issues such as the participant sometimes just forgetting to write their diary entry, or the participant’s handwriting being difficult to read or simply they are capturing a lot of interesting information, just not about the right thing (i.e. the topic of the research).

A New Digital Approach

One way of mitigating these problems is to adopt a digital capture approach, a continuing series of snapshots of the participant’s interactions in the digital space as they happen. For instance, capturing the web pages they are looking at, the videos they are watching or the comments they are making to their social network. All of these can be captured in a single stream to a platform such as a blog.

In this way, it’s possible to keep an eye on the participant in real time (by watching their blog) and encourage them if they aren’t contributing, or nudge them in the right direction if they are getting off track.

This was precisely what I wanted to do, to utilise a blog as the means with which the participants in the study could capture their online activities. This idea brought with it several other advantages such as the recording mechanism being in the same medium and context (the web) that I was trying to find out more about. It also meant I could automatically capture some of the participant’s online activities such as their Facebook statuses, tweets, emails, instant messages etc and integrate them into one feed.

This “live” capture of the participant’s lifestream would also ensure a more realistic, natural record of their daily routine than asking them to fill out a diary entry alone. Furthermore, it closely connected me to the participant, allowing me to monitor updates to the probe as they happened.

Lastly, having a digital-only record also made analysis, versioning and distribution a whole lot easier.

Lifestreams

But what is a lifestream? Today, it is pretty common for most people to capture vignettes of their life in digital format. From the emails they send, to the status updates they post on Facebook or Twitter or the text messages they send to friends and the photos they upload to Flickr.

Lifestream is an aggregated view of all these things, captured chronologically in a single stream.

The Research

Recruiting

Before I could start capturing lifestreams, I needed to find a way to recruit the right participants for the research. Some of my colleagues had, in the past, used a tool called Ethnio to recruit participants directly from the sites we were studying. This seemed like the right approach for my study. To recruit directly from the site meant that occasionally a visitor to the site would see a lightbox screener asking them whether they would like to participate in the research and offering an incentive to do so.

This may at first glance seem disruptive to the user experience but you do get to control the interval at which the screener appears (anything from 0.01% to 100% of site visits). Therefore, dependent on the timescales for the research you can change the frequency to achieve your recruiting aims whilst causing minimal disruption.

So, for instance, if the timescales are short, you could set it to 50% for a very short period, in which you might expect many replies, and then it can be turned off. If, however, you have a long lead time before the research starts, it is best to set the frequency low and harvest participants slowly, whilst minimising disruption to the site.

We didn’t have much time in this case, but we did have a heavily trafficked site. This meant that I could start quite high, reap a lot of recruits in a short time and then turn it down. This approach worked well.

Tips on Creating a Screener

1. Keep the screener as short as possible, ideally less than 10 questions.

2. Speak your audience’s language.

3. Be very clear on incentive, location and time commitment.

4. Don’t offer the participant options such as a variety of dates or time to choose from. Select one date and time and then see who is available.

5. Factor in a good amount of time to organise the recruiting process.

6. Sort and prioritise the respondents; create 1st, 2nd and 3rd tier lists and backups.

… and then:

1. Pick the people who most closely match your criteria.

2. Let those who were not chosen know you might contact them in the future for focus groups and further research.

3. Ring the people you want

1. It’s much faster and reliable than email.

2. Ensure they have enough time to participate and they understand the obligation.

4. Send privacy agreements in advance.

5. Make a follow up call to quickly explain the process.

6. You’re good to go …

Over the course of a week I managed to recruit the seven participants I wanted. It was time to turn my attention to finding the tool I would use to capture their lifestreams.

Selecting the Probe Tool

For the purposes of this research, I wanted a freely available tool and one that was easy to configure and get going.

After a bit of testing with different blogging type platforms, I narrowed my selection down to three:

1. Wordpress

2. Posterous

3. Tumblr

Wordpress is becoming the de facto blogging platform on the web and is highly configurable with plenty of plugins. However, I just found it a bit too hard to setup and scale correctly for my purposes.

Posterous was great and was very easy to use. Unfortunately, it didn’t have the ability to capture an RSS feed, which I thought was critical. With an RSS feed I could pull in a participant’s activity from most external 3rd party sites that they might be using (Flickr for example).

So, I turned to Tumblr and found it offered just what I was looking for. It was easy to use, well supported by a community and had a number of great features that would be critical to the research.

It offered a very simple mechanism, a “bookmarklet”, (that is a button that lived on the browser, that when pressed saved the page to the Tumblr) for the participant to capture videos, emails, images, text, audio and IM conversations as they engaged in their normal online behaviour.

It also facilitated simple aggregation of multiple digital streams, pulling in things like Twitter or Delicious streams. The participant could then, optionally, add commentary around any of these.

Useful Plugins

In addition to being an excellent foundation product, Tumblr has a number of third party plugins which augment the default capture mechanisms. One example is Dial2Do, which allows participants to record voice memos on their phones which are then automatically transcribed and sent to the Tumblr. So, for instance, if the participant wasn’t in a position to type, but wanted to capture a moment, they could make a quick call to Dial2Do and record their thoughts. These would then be uploaded to their Tumblr.

Perhaps the most critically important feature of Tumblr, though, was that the participant could email it. This was hugely important, since email is a communication medium that all the participants were familiar and comfortable with and furthermore didn’t require them to login or access an external a web page.

This was crucial, as most of the participants were browsing the web during office hours and didn’t always feel comfortable loading Tumblr at work. Email was a much less conspicuous, more natural medium for them to capture their thoughts, and they could still attach images, videos or other files which were ported into the Tumblr page.

Running the Probe

Pre-probe Interview

Before starting the primary research phase in earnest, I organised a 30 minute training session on the use of Tumblr. Typically, I’d get the participant to start making a few entries, recording images and videos as well as getting them to send an email or SMS to their Tumblr (thus getting its email into their address book). In this way, they left the session feeling comfortable and familiar with the tools I was asking them to use.

The Probe Itself

The participants were then asked to return to their normal lives for a week, and use the Tumblr to capture any of their thoughts or activities around music.

It was interesting to see how the different participants got on running their probes over the course of that week. Some really took it in their stride and were blogging straight away, even going so far as personalising their Tumblr (adding avatars, making it the colour the wanted etc).

Others, however, required a bit of encouragement. This is one of the great benefits of this kind of probe; you can see results as they happen and act upon them if you need to.

For those that had, after a few days, done very little I sent a gentle email encouraging them to participate. For others who were not quite capturing the information I was looking for I was also able to nudge them in the right direction by again giving them a call or dropping them an email.

I made it a point, as well, after a few days to email all the participants anyway to let them know they were doing well and to encourage them to keep going. This worked really well, as it turned out many were looking for the sense of validation that what they were recording is what we were looking for.

The results of the probe were quite amazing. The Tumblrs were a really rich source of information we would never have been aware of otherwise. We saw pictures from gigs, status updates to Facebook and Twitter, and had an unprecedented view into the ecology of websites they were using to find out more about music.

Post Probe Interview

After the week was up, I brought the participants in and asked them to take me through their Tumblr and tell me about what they had recorded and why.

This was the most critical part of the research. It is important to remember that it is not the data in the probe that is the most useful thing. Rather, it is the story the participant tells you around the data. Here is where you find the richness that gives the design researcher the deepest insights.

Here are a few points I’d make about this process:

1. Ask participants to take you on their journey.

2. Get them to reflect on what they’ve actually done rather than deal with conjecture.

3. Ask open questions to get at the why, such as “What were you thinking about when you posted this?” or “How did you feel about seeing your favourite artist live?”

4. Start with the item they are discussing but focus on the context, what happened around this item, why did they add it?

5. Get them to “show and tell” on activities.

In practical terms, here are some other things I want to share with you about conducting post probe interviews:

1. Record the screen if possible, use Morae or other screen capture software to record audio and video of the session. In this way, as the participant reflects back, shows you websites or emails, you have the ability to go back at a later date and watch it again.

2. Transcribe if possible: a record of the interview will be particularly useful when you come to the textual analysis. But do not do it yourself, it will distract you too much from the interview.

I suggest you either:

1. Pay a professional service, give them the video of the session and ask them to send you back a transcript.

2. Replay the audio or video after the session has finished and transcribe it manually.

3. Have two people in the session, with one taking comprehensive notes. You will have to depend on the second person’s ability to take comprehensive memos. Brief them beforehand on the material that will be covered and the specific information you are looking for. Also keep eye contact with them in the interview to ensure they’re getting down the important points.

The post-probe interview was probably the most rewarding part of the research for me. The Tumblr the participants generated came to life in the stories that they told.

Analysis

As you can imagine, after carrying out the probe study I was left with a tonne of raw data. Turning it into something useful was the next real challenge.

I decided that a mental model was the best way in which to present the results. So, I set about generating a meaningful mental model that mapped the audiences’ motivations, thought-processes and the emotional and philosophical context in which they were operating.

The generation of this model required many hours of effort. I used Grounded Theory to codify the textual data I had generated from the interviews. From this I then grouped related data into concepts and categories which related to levels of abstraction in the model. These were all captured into a spreadsheet and then transformed into visual mental model.

The model ended up being huge, around six meters long. It contained hundreds of conceptual groups along an x-axis. Each of the conceptual groups contained a series of users’ behaviours, philosophies or feelings towards a single concept (for instance “going to a gig”).

It became an immensely useful tool for the product team who now no longer make “guesses” about audience behaviour or needs, they can now simply reference the model for answers. This allows faster, more informed product development decisions to be made.

It was also a great learning experience for me. Just creating the model submerged me into the mental space of our audience and product design and strategy level insights soon followed.

Conclusion

This was a fascinating and difficult journey, but one which was ultimately very rewarding because of how valuable the research became to the product team and for the lessons I learnt on carrying out this type of research.

Deeper, ethnographic research like this is often where the miracles in product design happen, where innovation is born. By living with your audience for a while you can generate models of their lives; you can look for areas where unarticulated opportunities exist, or where current systems break down. By looking for the gaps waiting to be filled you can see new product opportunities. It is when these opportunities are turned into solutions that we see innovation.

About the Author

Chris Khalil is Director of User Experience at News Digital Media (NDM) where he leads one of Australia’s best and most respected UX teams.

He has over 13 years experience in the field and in his time has turned his hand to the design of such things as: thermonuclear power plant control panels, immersive augmented reality environments, seismic simulators, intelligent agent interactions, workspaces, SaaS products, traditional websites and virtual worlds such as Second Life.

As well as his design work he has carried out HCI research at leading research faculties such as Loughborough University (UK), University College London (UK) and XeroxParc Europe, Cambridge (UK).

He has a PhD in Human Computer Interaction, a Research Masters in Telecommunications and degree in Electronic Systems Design.

You can read more of his thoughts on User Experience on his blog.

Blog: www.chriskhalil.com

Twitter: chris_khalil

Using the Right Tool for the Job—Three Methods of Testing the Redesign of Guardian Jobs

I wanted to tell the story of a project to redesign Guardian News & Media’s Job website, which was carried out during 2009. Guardian Jobs[1] is one of the newspaper’s most successful digital properties. In a time of financial uncertainty, particularly in the media sector, it was important to make sure that any changes to the site improved not just usability, but also the commercial performance of the web property. I was assigned the project shortly after joining The Guardian on a full-time basis as Information Architect, and looked at it as an excellent chance to demonstrate the value user-centred design processes could bring to the business.

Strategically the project had two aims. One was simply to give the design a refresh, so that, whilst it retained its own personality, it felt more in line with the look and feel of the main guardian.co.uk site. The second was a business aim. In print The Guardian has additional daily supplements for specific sectors—“Media” on Monday, “Education” on Tuesday, and “Society”, which covers health and social issues, on Wednesday. These carry a significant amount of recruitment advertising, and we wanted to reflect those key sectors much more on the jobs site.

Guerrilla User Testing

In the early stages of the project I carried out some “guerrilla usability testing” of the existing site at the London Graduate Fair, which was held in Islington. With a long history of being involved in Graduate recruitment, The Guardian was a sponsor of the event, and Guardian Jobs also had a very central stand in the exhibition. The stand featured several laptops where people could browse the Guardian Jobs site, and also the Guardian Careers site[2] where we publish information and content to help people through their working lives. To carry out the testing we replaced one of those PCs with my own MacBook.

For guerrilla testing, I use the Silverback App software[3] which simultaneously records the user’s on-screen actions, whilst also recording their video and audio via the webcam. The footage turned out to be really useful, if not elegantly shot. In fact several people did not quite appear in shot at all, and I got some excellent footage of the tops of people’s heads or torsos. This wasn’t a huge problem though, as I had still captured their voice and their on-screen actions.

I didn’t have any kind of formal “script” for the tests. Instead I asked people questions around whether they had ever used the site before, and what other jobs sites they had used. Then I would show them the site at http://jobs.guardian.co.uk, and get their opening reactions. Looking at our statistics we know that users of Guardian Jobs have a tendency to browse rather than search. Depending on what they did first, I would ask them some questions which either explored the way they browsed for jobs, or searched for jobs. I also tried to find out whether they used “jobs by email” alerts, and whether they searched for jobs via social networks like LinkedIn.

The first couple of students I approached recoiled with horror at the idea of being video-recorded whilst using the web. I learnt that the easiest way to get co-operation was to say something slightly more ambiguous like “the laptop will record what you do” rather than “you will be videoed”. It wasn’t strictly an untruth, but it was being a little bit disingenuous. I also didn’t try to get the subjects to sign any kind of consent or rights release form. For that reason, I’ve never shown the footage to people outside of the Guardian offices. Whilst it was pragmatic, to increase the number of people willing to take part in the testing, it is a shame, as I think we got lots of lessons worth sharing in it, not just about the Guardian Jobs site, but about the attitude of graduates to job research on the web. And some lessons to be learned about good and bad practice as a tester.

I put together a five minute clip-reel to show within Guardian News & Media, and, to give it some context, I filmed myself giving a little 30 second introduction to the concept of guerrilla testing, and setting the scene. Rather than show each user sequentially, I arranged the clips thematically around the questions that had been asked of them. I used caption slides to display the question and then followed that with quick cuts of various responses, making sure that I covered the spectrum of views that had been expressed.

This wasn’t formal testing, so I didn’t come out of the session with any specific user interface recommendations. However, we had established that graduate jobseekers seemed less likely to be on services like LinkedIn for job-seeking, were very unlikely to find Twitter based services useful, and wanted “jobs by email” alerts to be very specific. I also got clips that demonstrated students looking for their first job both by browsing an industry sector like “engineering”, or selecting entry-level criteria, like “graduate jobs”.

Online Taxonomy Research

One of the things that we wanted to ensure we got right with the new site was that the labels we used for jobs matched both the expectations of recruitment advertisers and that of the audience. It is no good having a jobs category called “Internet”, if your audience is looking for jobs with the search term “web”, and your clients want to post adverts in a vertical called “digital”.

In order to make progress with redefining the categories, I first of all made a spreadsheet with all of the existing categories and sub-categories on The Guardian’s site. Then I looked at broad first-tier competitor sites, and captured their visible job classification schemas. For the areas of job hunting that were particularly of value to us, I also investigated the job categories on vertical-specific recruitment sites. I also had help from the experience and knowledge of the sectors that my colleague Piers Jones, the Jobs Product Manager, has. At the end of the exercise, for each of our key areas I had a record of our existing taxonomy and some synonyms for key terms used on other sites.

I had wanted to do some card-sorting exercises to validate our proposed taxonomy, and to find the terms and labels that we’d missed, but covering all of the different job sectors effectively would have been prohibitively time-consuming and expensive.

However, I am very lucky at Guardian News & Media. We have a Research & Customer Insight team, which can help organise all sorts of research. We also have an already recruited panel of over 40,000 regular Guardian users and readers, who we can ask to take part in surveys. So instead of face-to-face card-sorting, we did some online survey testing, where we asked existing job site users which sector they were looking for work in, and then got them to validate our choices of sub-sector labels in that area.

Progressing the Information Architecture

An important part of a project for me is to sketch out lots of different possibilities for the information architecture of a site. Producing a lot of variations allows you to explore different ways of displaying key information. I usually start with pencil and paper, and I’ll often do my sketching away from my desk so that I can not be interrupted by email, the phone, or a compulsive urge to check Twitter every twenty seconds. The Guardian recently moved into some fantastic new offices at Kings Place. As a result, I can sit on some soft seats in what we call “trainspotter’s corner”, which overlooks the platforms of London’s busy Kings Cross mainline station. There are always trains pulling in and out and plenty of hustle and bustle. Alternatively, I sometimes sit in the canteen. This is on the other side of the office, and overlooks the decorated narrowboats, which are moored in Battlebridge Basin, on the Regent’s Canal. This is an industrial revolution era canal that runs through London, and the section that links Islington to Camden runs along the back of The Guardian’s building.

The early sketches in this project show that I played around with the idea of the browse categories appearing as left-hand navigation, with the categories ordered not alphabetically, but by the number of jobs available in each sector. After producing a series of sketches, I would meet up with the product manager to discuss some of my thoughts and the options available. The feedback from that session would allow me to narrow down the design into a more formal set of wireframes.

For me getting the “fidelity” of wireframes right means that the amount of detail varies from project to project. For the Guardian Jobs redesign, as my ideas on the layout became firmer, I worked on some wireframes which were indicative of “zones” of content. Instead of content, I indicated the layout with labelled boxes of varying shades of grey, indicating their purpose and function. I find this useful, as it means business stakeholders are able to look at the relative hierarchy of the information on display without being distracted by things like the choice of imagery and icons, the colour, or even sometimes the particular story chosen to represent the “news” section.

As my wireframes progressed, I settled on an approach where the top “browse” section of the page would have a tabbed interface. The initial homepage view would be a top-level view of “All” job categories displayed. The tabs would feature the key verticals to the business and, when selected, they would display one of a series of templates, either including specific jobs, news stories, or user-generated forum content from that category, alongside a drill-down to sub-categories relevant to the sector.

The basic layout at this point had browse and search sections at the top of the page, with a panel listings the services available on the site alongside an advertising slot. Underneath that, a narrow left-hand column featured “promo” content, and there were sections for news, excerpts from the user forums, and a slot to showcase video. A small section above the video slot was allocated to offer recruiters the chance to place advertising on the site.

Having got to some wireframes that I was reasonably happy with, and a set of categories and sub-categories that we thought would work, it was time to progress to some formal usability testing.

Lab-User Testing With Madgex

The Guardian’s job site is supplied by Madgex[4], a specialist jobs board software company based in Brighton. As well as doing the technical build for the new version, we commissioned them to carry out a usability study on the proposed wireframed design. Their user experience specialist is Dr Harry Brignull[5], and he worked with myself and Piers Jones to define the testing script.

As well as the wireframes of the new homepage and sub-sector homepages, the test followed the end-to-end process of registering on the site and applying for a job. These sessions, overseen by usability testing moderator Simon Johnson[6], were extremely productive for us. When it comes to asking for budget to fix things, there is something incredibly powerful about having video footage of users struggling to complete certain key tasks on a transactional website. A report saying that “there is a problem with area x of the site” can sometimes be dismissed as the design team striving for perfection, or wanting to make change for change’s sake. It is much harder for people to shrug off watching their site fail to work for even people who are being guided through it in a controlled fashion.

What I was most interested in finding out was audience reaction to the new homepage structure. One of my key learning points from this project was that I certainly made mistakes in the way that I commissioned the testing. We had decided to recruit two people from each of the vertical sectors that we were hoping to have a higher profile on the site. Since we were going to be using an HTML prototype that meant I had to make a clickable HTML page for each sector.

As we were only testing the principle of taking this approach for the different sectors, rather than the actual content, I believe that we could have comfortably only tested people from two of the sectors and I could have produced less versions of the design. As it was, with simultaneous pressure from other projects, I didn’t allow myself enough time to deliver fully-fledged versions of the eight different tab states needed. I built the prototype using Axure and the time restriction meant that we ended up presenting users with a “mixed fidelity” prototype to assess. Some elements on the page were pure wireframe. Other elements featured the visual design and typography from the live site, as I had ended up having to use images, which I had cut and pasted, from the existing site.

Despite the obvious drawbacks of this approach, the testing was extremely useful in shaping the final design. We were able to categorically dismiss the tabbed design. The idea had been that the tabs would also change content on the rest of the page i.e. selecting the environment tab would change the advertising, news stories and search terms tag cloud on the page to all be environment themed. We established that the way users understand tabs means that they were definitely only expecting changes in the “bounding box” at the top of the page and did not notice any changes elsewhere on the page, especially if the transition took place on a section buried below the fold at the time the tab was selected.

Throughout the process, I had always envisaged that the changed state of the tabs would be delivered by a page reload, rather than any AJAX-y on-page effect. For bookmarking and, frankly, SEO purposes, this was to provide new top-level URLs like jobs.guardian.co.uk/environment. Whilst dismissing the tabs, the lab testing process did validate this “sub-sector homepage” approach. Test subjects from all the different sectors confirmed that they would find a “sector homepage”’, which combined the jobs from their vertical with news and careers advice relevant to that job area, useful. We therefore settled upon using a second-tier of navigation to display these sub-sector homepages.

Visual Design Process

Having finalised a set of wireframes, the visual design process was then a collaborative effort between the design team at the Guardian’s HQ and Madgex. The aim was to produce a design, that incorporated our understanding of The Guardian’s house style, and marry it with the knowledge Madgex have of producing jobs board software for a variety of clients. After a couple of iterations the design was finished and signed off, and the build could begin. The new homepage and the sub-sector homepages launched at the beginning of December 2009.

Lessons Learnt

As I mentioned earlier in my story, these are tough times for the newspaper industry, with an advertising downturn affecting revenues from display, classified and recruitment advertising. One of the clear metrics for us was an increased search engine presence for the main sectors we cover and there was an immediate uplift in our rankings from re-organising the site and adding the new tier of themed pages. There was also a commercial gain in having more sellable “slots” for featured advertising on the sub-sector homepages.

I’ve always been a fan of iterating designs, rather than “big bang” total relaunches, as it allows you to incrementally improve performance all of the time. Our next task is to take what we have learned from redesigning the homepage and apply those lessons to search results and individual job listings on the site.

What I was particularly pleased about in this project was how we were able to combine three different types of research to produce a reasoned overview of the direction that the information architecture and design should take.

The online survey validated our taxonomy choices, with real members of our audience and users of the site. The “guerrilla” testing at the Graduate Fair gave me compelling anecdotal evidence that our target audience would definitely use multiple browse paths and so we needed to facilitate those. The lab testing confirmed that sub-sector homepages would be useful to job seekers in our target verticals, but that tabbed navigation was not the way to make the functionality clear to them.

Alone, none of these research methods would have given us definitive answers—but combined they have helped us to deliver a much improved user experience with added commercial, SEO and usability benefits.

For me personally, the most satisfying thing is that this project successfully established the principle of “guerrilla” testing playing a role in our product development process. On subsequent projects I’ve tested The Guardian’s incredibly successful iPhone application by filming people using their phone over their shoulders with my Flip mini camcorder, spent hours in cafes ambushing unsuspecting customers to get them to try out different aspects of guardian.co.uk and enjoyed a day trawling London’s major art venues looking for people to interview who like “culture”. It is not the most scientific of research methods, and I would never use the clips as the basis for any statistical analysis, but I find a regular dose of putting our website in front of people and asking them about it helps me to act as the “voice of the user” within the business—and enjoy it!

About the Author

Martin Belam is an Information Architect and writer based in London, with a decade of experience working and consulting on products and services for global brands and institutions like Sony, Vodafone, the Science Museum and the BBC.

Since February 2009 he has been Information Architect in the Guardian’s web development team, working on the guardian.co.uk website.

Besides his role at The Guardian, Martin Belam acts as one of the contributing editors for FUMSI, commissioning articles and writing editorial for the ‘Share’ practice area in the magazine aimed at information professionals. He blogs about information architecture, journalism and digital media at www.currybet.net

Web: www.currybet.net

Twitter: currybet

[1]. http://jobs.guardian.co.uk

[2]. http://careers.guardian.co.uk/

[3]. http://silverbackapp.com/

[4]. http://www.madgex.com/

[5]. http://www.90percentofeverything.com/

[6]. http://squaxor.posterous.com/

How to Avoid Wasting Millions on Your Product Development

Today, we have a little story to tell. Some might call it a parable about the dangers of not doing consumer research early in the product cycle. Others might describe it as a true story about a past consulting project and a UI (User Interface) parable of sorts for our times.

The team, which we’ll refer to as the “Oxygen team” for this article, had everything going for them a high tech team could hope for.

They had solid committed resources from an established company. They had a team of 40+ employees, comprised of very smart and talented people from all disciplines including dev, test, pm, marketing, and others.

And they worked at one of the “hottest” companies at the time.

The Oxygen team was working on a web based application targeting small business owners. More specifically, the team was creating a web-based application for small business owners to create websites. It was an early web application as at the time, back in 2000, this was a unique thing that no one was doing; everything was still box, or CD based.

Like many internet teams, speed was of the essence. They wanted to have the “first mover advantage” and be the first to market.

Does this story sound familiar?

The team had been developing this product for more than a year and the total project costs were well in excess of a million dollars.

My role and involvement with the team on this project was as a consultant. I was brought in for several weeks to help the team complete this project before moving on to consult with another team the following month.

After a week of team interviews, assessment and preparation, we moved on to the actual usability test. The first day of the usability test arrived. The team was quite interested in the usability study since they had never seen one before. My supervisor was in the room the entire study, observing me too. So I was nervous to say the least! We were all sitting on the “observer” side of a typical expensive usability lab set up at a big company (i.e. two rooms separate by one way glass). Imagine an eight square foot observer area, with six of us crammed into that space to observe.

Drama in the Usability Lab

The first participant, Joe, walked in. We did all the usual things we all do in a usability study. We built rapport so he would feel comfortable giving honest feedback. We did a little pre-interview about his background and experience in business. And then we started the study.

The build was not quite ready for prime time. It kept crashing so our participant was not able to complete the tasks because the software was so unstable. This prototype was highly interactive and the team was relatively deep into the actual coding and development so we were using a working build rather than a paper prototype. Ideally, if user research had been brought into the product development process much earlier, inexpensive paper prototyping would have been a valuable and cheap way to conduct an iterative test right from the start.

The development team decided they needed to tweak things a little bit more. So I went into the room and asked the participant if he would be willing to stay for another session and he agreed. (Of course he received double compensation for his efforts.)

So, fast forward an hour and we’re starting the test again. Everyone seemed a bit “keyed up” and nervous tension filled the air. The team had been working so hard and for so long, but they had still never actually observed a customer using the product.

Joe started the test and was struggling. About 30 minutes into the session, he clicked on a link to go to a page and suddenly there was a LOGIN window on the computer screen!

At this point I was confused.

To be honest I was probably sweating a little bit too.

“Uh, what is that?” I asked Janet, the lead developer sitting beside me on the observer side of the usability lab. “Oh, that’s the login screen. We designed the system to time-out after 30 minutes for security reasons,” she replied. (This was the first time I’d heard or seen of this “feature”. Janet went into the room to help log the participant in and Joe started asking her why there was a login screen).

So Janet walked over to the participant side of the usability lab. And that created an unusual and very interesting situation; suddenly we were observing not just the participant interacting with the website. But we were observing the frustrated participant now face-to-face with the person who created the website. And the person directly responsible for their frustration!

It would have been humorous if the tension in the air was not so strong. And it was neat to be observing the end user actually interact directly with the person creating the product. Joe was so frustrated at this point that he was a powder keg ready to blow. He was quite irritated and it was actually quite entertaining to see him sharing that frustration directly with the developer, rather than to the usability professional as is usually more common. As an aside, many usability practitioners have had the experience of conducting some really solid research and then being met with some level of skepticism or defensiveness by the developers. So it is always nice when the team can experience that feedback directly from the end users.

We went on with the study …

Joe continued with the list of tasks that represented the core things that a customer would want or need to do in order for this product to be successful. Since the prospective customers were creating a website these tasks were fairly straightforward, they had to be able to create some pages and format them to look like some sample pages they were shown.

There was one “little” problem though, the product was very confusing.

In order to create a website, of course, the first thing you need to do is create a single web page. When Joe started using the site, however, he was confused by the formatting options. So he wasn’t able to select the right type of page to create. Then after he had selected the wrong type of page to create and realised it didn’t look right, he wasn’t able to fix it!

Overall, the success rate for selecting the right type of page to create was only 50% and that meant that half of the participants could not choose the right kind of page to make. Then, after they created the page, they often were not able to format the page correctly. They experienced a major slow down in their task flow as they tried to decipher what the final page layout would look like from reading the accompanying text descriptions. Users had to read through text descriptions and it took them a very long time to find a page that matched the description of what they were trying to do. All of the participants, except one, selected the wrong page to build. Later, they tried to “fix” the visual appearance of the page and tried to change the layout, but the real problem was that the page type was incorrect.

The user interface was so ineffective that the participants could only make five to seven pages in a 90 minute session.

At the end of the study, we asked the participants to do some user interface ratings. These were standard questions usability folks often use about satisfaction and their experience using the product during their session. These ratings were on a seven point Likert scale. And the ratings for this study averaged nearly two points lower than any other study I have conducted personally or been involved with during the last decade! People are usually positive when evaluating products in the usability setting, so that was revealing.

During the post test debrief, Joe had scathing feedback:

“The instructions were unclear” he said. “The procedure leads one to believe it is ‘step by step’, but it is far from ‘step by step’. Descriptions are unclear, as are certain instructions. Moving about from one point to another in the program to check one’s progress, or see how things look, is very clunky. In other words, it is difficult to get from point A to point B for purposes of editing, or seeing one’s progress. It is not a user-friendly program. It is much, much too time consuming to get through. It is so far from intuitive that one almost needs either an experienced personal guide or an “Oxygen For Dummies” ancillary guide.”

OUCH!

Anytime a user tells you they need a manual to use a website, or even a software product, it’s usually a bad sign! And the emotional tone and depth in this one sample comment was also a bit alarming. Needless to say, it was crystal clear that the product was not ready for prime time.

As I mentioned earlier, I was in a consulting role at the time and transitioned to a new team and project following the completion of this usability test. But this test really made an impression on me and I remained quite curious about what the outcome of this project would be and how the research would be utilized in the product development process.

Several months after the study, I learned that the company pulled the plug on this product and the “Oxygen” team was dissolved.

At the end of the day, a company with extensive resources and deep pockets was unable to move a product so severely flawed forward. It was simply easier to pull the plug than to try to salvage this effort. Most companies don’t have anywhere near the level of resources (time, money and people) that this company had, so the issue would probably have surfaced much earlier in a smaller company.

What Is the Moral Of the Story?

As history shows us, while it’s great from a marketing perspective to get to market first, it’s even more important to get a great user experience to market. Apple is a great example of doing the right thing versus rushing to market. For many years they were criticized for not having a mobile phone. They did the right thing and only shipped when they were ready. The result as we all know was a huge game changer and they have achieved market dominance in a very short period of time.

The moral is: test early and test often. Don’t let this type of usability failure happen to you, your team, your product, or your company.

If you pick up an old text book in human factors they always talk about how it “used to be” so expensive and time consuming to conduct usability testing back in the 1960’s or so. But its 2010 now and there is no excuse for not doing usability testing and other forms of consumer research, even at the earliest stages of your product development. A case study like this one of “usability gone wrong” helps to remind us of what happens when user experience research is not a part of the lifecycle of a product or service from the very beginning.

Cheers to better user experiences for our customers in 2010 and beyond!

About the Author

Jay Eskenazi is a Usability Expert and Website Psychologist and Partner at Customer Experience Labs, LLC—an Innovative Customer Experience Research firm specializing in helping companies improve their revenue via usability testing, eye tracking and hybrid research.

Jay’s research career spans 20 years, and he has worked in user experience research since 1999. For nearly a decade prior to co-founding Customer Experience Labs, he served as an internal usability consultant and expert, helping to drive product improvements via user experience research—first at at Microsoft on their top e-commerce channels and then at Expedia, Inc. where he created and then served as Director of User Experience Research for more than seven years.

Jay earned his B.A. in Psychology from University of California at Santa Cruz, an M.A. in Communication from University of California at Santa Barbara, and an M.A. in Psychology and a Ph.D. in Clinical Psychology from Alliant International University in San Diego.

Jay Eskenazi lives in Seattle, Washington.

Web: www.customerexperiencelabs.com

Twitter: customerexplabs

Facebook: http://www.facebook.com/pages/Seattle-WA/Customer-Experience-Labs/74824355957

Style of Change

It was a beautiful morning, the sun burning away quickly the not-so-uncommon fog of the moor countryside north of Munich. Our workshop started with fifteen minutes delay, the group arrived late flying in from Hanover, but fifteen minutes, hey, we can make up for it during the day.

What does the stage look like? I am the User Experience Evangelist at Microsoft Germany. In this role I manage Microsoft’s relationships with its partners, software and multimedia, or creative companies that deliver user interfaces, and have a substantial impact on determining user experience. I also work with software-development companies, enterprises and companies in all sectors really, as long as usability, user experience or human-centred design is involved. The group that arrived with an air of curiosity that morning at our German headquarters in Unterschleißheim had a problem. This problem prompted a colleague to call me.

Sven: “Hi Clemens, got a sec?”

Me: “Well … it depends …”

Sven: “A partner IT company from Hanover … they are working on … well, they ask … lately they were trying … it is about their user interface, the new one.”

Me: “They want to rework their user interface.”

Sven: “Yes, as I said.”

Remark: Dear reader, you might have noticed that even within a company, a colleague was careful to bring up this issue for fear of being misunderstood. He was very cautious as he wanted to make clear that there is NO problem with the partner itself, only with that crappy thing they were doing to the user interface. This was something he did not know anything about, that he had no solution to and that did not really affect his daily work—something he expected me to take care of.

Me: “What is it?”

Sven: “They want to discuss some issues and show you the current state of their work. They adopted the ribbon for their new release.”

Me: “Just a moment … what do they do?”

Sven:” They develop software for logistics. They have a lot of clients. Most of their portfolio is legacy stuff.”

Me: “What do they expect?”

Sven: “Just a fair discussion of their approach, some insights on their strategy, I think a day will do.”

Me: “Ok, send me the details, we will find an appointment.”

Sven: “It’s kind of urgent …”

Me: “What do you mean by urgent?”

Sven: “Next week … ?”

Me: “O … K ...”

So we sat down, set up our equipment and made the routine introduction round. They quickly came to the point, a painful point. After a recent acquisition, they had to include two other logistics products into their new portfolio. Together with their own three applications, the formula they tried to come up with was 3+2 = 1 and they kind of felt that a user interface developed in 1998 would be somehow inadequate. I agreed. Interestingly enough, they were using usability buzzwords left and right, using them in a wild and sometimes a little bit romantic way, but not exactly in a consistent way. So I kicked off with a one hour bird’s eye view of user experience and usability. Then the ribbon came. Since we introduced the ribbon (aka Office fluent UI) in Microsoft Office 2007, a lot of software companies sought to adopt this design. After some initial confusion, the users started to like and to prefer it to the old cascading menus of earlier versions especially after looking at the published presentation, “The story of the ribbon”, (held by the product team guy) about the way we got there. So, they presented what they had done to the ribbon up to now, ending with the mention that they had recently run into some limits regarding the integration of 75 modules of their software into ribbon design.

So they got ribbon in ribbon, tab in tab, scrolling in forms—pick your personal nightmare and you should come pretty close to what we were facing.

Now, there are several ways to break the truth to engineers. Some folks prefer to work towards a discovery, so listeners can learn along the way what they caused. Others want to sell a usability test and let users be the herald of the bad news. Then there are the ones that come straight to the point. Most often, I prefer the latter approach. So I told them, that I get paid for telling the truth, not for being nice. That was well received. One respondent wanted an open visor discussion. One looked for learning something and one wanted real, original feedback. Then I said, on a scale from 1 to 10, 10 being very good, 1 being pretty bad, their approach was a good minus 20! That was not well received and caused some irritation. They had adopted the ribbon specs as laid out by Microsoft so how could it be minus 20? Technically, they were correct; the ribbon has been developed according to the specs. But a ribbon is not only a technical element, it must also be easy to use by the user. Then my favourite part came when the IT Lead said that they know exactly how their users work, since they have known them for years. Borrowing from my Microsoft colleague Arnie Lund the quote “know thy user, you are not thy user” I got my torpedoes ready.

Everything they showed me was technically well implemented, performing, working smoothly and fast. That was great and I told them so. But step by step I pointed out their fundamental mistakes in interaction design, the design of user controls, even in using their colour scheme.

“How many of you are trained in user interface development?” I asked.

“5.. no 6 People” the UI Lead replied.

Me: “How many of you are trained in human-centred design or Usability Engineering?”

UI Lead: “None.”

Me: “Trained designers?”

UI Lead: “Um … none.”

Me: “Anyone trained in User Experience Strategy?”

UI Lead: “No one.”

Me: “How many of the company decide on the user interface?”

IT Lead: “Well, the leads … 6-8 people.”

Me: “You are telling me that 6-8 people spend their time deciding upon something what they have no fundamental knowledge of, something that they are not trained in?”

IT Lead: “…”

Me: “So, you guys can implement a user interface, we’ve seen that. But you are not trained to design a user interface, to create a concept and devise a user experience strategy. You have no idea how to do it. And that is because you have never learned it. And that is OK, because being a UI developer; it is not your job, you have other responsibilities. The problem that you have is not your 75 modules into the ribbon issue, it is that you have no one that can take care of what to do in the UI.”

IT Lead: “…. You are right.”

Then the workshop started.

About the Author

Clemens Lutsch is a User Experience Evangelist at Microsoft, Germany. He has a record of more than 16 Years in projects in the field of User Experience, human-centred design, Usability, UI design, requirement management and strategy. His expertise covers different industries and markets, as operative provider of designs and solutions and also as consultant and trainer that conveys the benefit of Usability and User Experience as part of development of interactive systems.

He represents Microsoft in national and international standardization work on UX and Software-Ergonomics.

Clemens Lutsch is board member of the German Usability Professionals Association.

Blog: http://blogs.msdn.com/clemenslutsch

Xing: www.xing.com/profile/Clemens_Lutsch

Escaping the Waterfall

Heyday

It has never felt better to be a mobile user experience designer than today. To be honest, it has been a rather long time since I was a true design practitioner myself. I traded in the role of the creative problem solver and user advocate when I jumped on the corporate ladder somewhere in the late 1990s. In my most recent roles, I often find myself acting as a design strategist and facilitator whose greatest contribution can be in setting the direction and creating the infrastructure and opportunities for the true user experience designers in my design team. I try to maximize their design talent, so that eventually, through our products and services, people can connect in new and better ways. Sometimes this design work is pretty straightforward, and sometimes more challenging; after all, we are talking about an industry where devices and services, bits and atoms are converging in creative and surprising ways, and user experience design is an extremely visible domain in mobile devices product development, where almost everybody has an opinion or even a financial interest.

From 2008 to early 2010, I was heading the UX design team in the Maemo unit of Nokia, now called MeeGo. We were designing the user experience for high-end mobile devices that allow users to live their Internet lives when they are mobile. This is about browsing the web, messaging with your buddies, doing your emails, subscribing to web feeds, locating your position and navigating, listening to music, discovering and installing new applications, making cellular phone calls and internet calls—basically allowing people to be productive and to have fun when equipped with their mobile devices. These multi-functional miracle machines are based on the Maemo or MeeGo Linux operating system and many of the users and fans of the products belong to the open source developer community.

In the autumn of 2009, Nokia launched the N900 device[1] that was the culmination of a long period of human-centred design work. We had taken the previous-generation Linux internet tablet UI design as the baseline, and had then incorporated the user feedback we already knew about, redesigned the stylus-optimized UI elements to be usable with fingers, designed basic mobile device functionality, like cellular telephony and text messaging, tested meticulously with users and iterated the designs, while the implementation marched forward. After the product launch, the user experience designers who had worked on the project for so long were finally able to breathe a happy sigh of relief while listening to feedback from the people who had purchased the device. It has been gratifying to hear users and media praising the product, but as professional designers, we also need to appreciate criticism, bug reports and improvement suggestions with a humble and open mind. There was already a soft launch of the N900 at the maemo.org developer summit in Amsterdam earlier that year, where hundreds of units were given to the participants. We then listened closely to the feedback from these early adopters and were able to incorporate some of the related design improvements into the first software updates for the device.

Design Delivery in the Early Days

When I started as a newbie interaction designer and a usability researcher at the Nokia Research Center in the mid-1990s, one of my first projects was the interaction design to the successor of the seminal Nokia 2110 phone[2]. We had a number of parallel design teams working towards the same goal, each producing a prospective mobile phone UI concept. Those were then prototyped and user tested during a ‘world tour’ across Japan, Central Europe, and Silicon Valley. Eventually, the best UI concept, dubbed “Jack”, was selected and then implemented, initially in the Nokia 6110 phone[3]. The code name Jack was chosen for this small-footprint UI, since we were working at the same time on the new Nokia smartphone UI, later to be known as Series 60, and we needed code names for both designs. Someone suggested the names Jack and Averell, two of the four Dalton brothers in Lucky Luke, the best-selling Franco-Belgian comic series. Jack was the shortest of the brothers, and Averell the tall one, albeit perhaps not so smart. The Jack UI took the 2110 UI design as the baseline, simplified and clarified the interaction logic, while adding numerous new features and introducing a GUI for the first time in a Nokia phone. We had a whopping 84 by 48 pixels at our disposal on the display, all in black and white, although at that time, pixels were not completely square, so fonts and icon design were somewhat more restricted than today.

The detailed design delivery process at that time can be characterized as a waterfall-style[4] creative-design-meets-technical-writing process that then handed over to software implementation. The creative design phase took several months. There was user testing and prototype validation being done, and the design delivery was documented in long and very detailed, mostly textual, user interface specifications, covering interaction design, visual design layouts, graphical elements and localization texts. We used paper prototypes and interactive design prototypes running on a PC when testing in a lab context with real users. For longer-term user testing, we also built tailor-made handsets with prototype software. The software implementation teams then started to work their coding magic, which eventually resulted in prototype software working on prototype hardware. At some point, this combination started to be robust enough for usability testing in a lab setup, and eventually, for friendly user testing with Nokia in-house test users. The findings of this user testing phase were then fed back to the design and software teams, and we still had time to make some corrections to the user interaction flows, visuals and terminology before the product launch.

Agile Software Development

The agile software movement[4,5] started around 2001, when a group of software thinkers gathered to come up with ways to improve how software is developed; at the time, the prevailing development methods emphasized heavy documentation, and the group felt that this was neither efficient nor effective. This gathering produced the Agile Manifesto[6], which emphasizes

1. Individuals and interactions over processes and tools

2. Working software over comprehensive documentation

3. Customer collaboration over contract negotiation

4. Responding to change over following a plan

The agile approach to software development tries to adapt software development practices to the dynamic world around the software development organization. Development work is prioritized and divided into meaningful packages that are developed in an iterative and incremental manner, each iteration and increment trying to deliver software that is, at least theoretically, shippable. The most widely used agile process framework or method is Scrum, where each iteration, lasting usually from two to four weeks, starts with the development team making a plan for that phase. The whole development project starts by capturing the customer needs in the form of user stories or similar.

I have come to learn a lot of agile software development philosophy and methods in the workplace, but perhaps even more at home. Coincidentally, my wife Maarit is one of the leading agile software development champions at Nokia. Through following her agile evangelization efforts in the company, I gradually started to think how agile methods are actually quite similar to professional modern user experience design practices, and how user experience design could fit in the agile software development process framework.

The Good, the Bad and the Waterfall

The waterfall product creation process, when applied to human-centred design, sounds really lucrative when you think about it. First you identify your target users. This usually comes somewhat automatically from the business strategy of the company or from the interests and aspirations of the product marketing or development team. Then you go out to do user research, using various ethnographic or contextual inquiry methods. You then turn the user insights into user needs, develop personas, and spell out user tasks. The tasks then form the basis for the user interface design work, supported by visual design that is done to appeal to the target users, from Mid-West farmers to Shanghai business people. When all the design is done and documented in Flash simulations and Word documents, you hand these over to the implementation team and surf to the next cool design project.

In certain circumstances, this approach can be made to work[4]; but in the new Maemo product design and development context, it no longer gave us what we needed when it came to the design quality and schedule.

For a start, there is no time to do the design work inside a black box and only proceed with the implementation afterwards. You need to run these tasks simultaneously to speed up the total process. Information design and interaction design are very often deeply intertwined with the technical architecture. Secondly, modern digital interactive products are so complicated that one can seldom get the design right during the first round. You must validate your design with users and go back to the drawing board to fix things that did not work. Thirdly, when developing a mobile communications device, you really cannot find out all the twists and quirks with a fake design prototype; you must also test the appeal and usability with prototype software running on prototype hardware connected to the mobile network. Only this type of user testing will give you real user feedback that can be used to iron out real problems with the device or service you are building; only real software and hardware connected to a real network will enable you to measure realistic response times and performance, the essential constituents of the real-life user experience.

All this requires an iterative and incremental approach to the design work in a typical product creation project. The creative user experience design work needs to be synchronized in an appropriate manner with the software development activities that, in a modern setup, are executed using various agile software development methodologies.

UX Design Manifesto

We arranged a UX design and development practices workshop in late 2007 with Alistair Cockburn, one of the software visionaries behind the original Agile Manifesto, and produced a UX Design Manifesto, among other things, since we felt we needed to crystallize some of the foundational drivers of our improved mode of operation in design and product creation. In our UX Design Manifesto we boldly stated:

We are uncovering better ways of designing user experience

by doing it and helping others do it.

Through this work we have come to value:

Collaborative, proactive human-centric design over last-minute validation,

Desirable design over documentation,

Fewer and better features over more features.

That is, while there is value in the items on the right,

We value the items on the left more.

The Best of Both Worlds

I have heard some of the proponents of the agile software engineering movement say that there is a fundamental mismatch between agile methods and human-centred design because “human-centred design always wants to involve the users in the design and development process, and in an agile process there is no time for that kind of overhead.” One concrete example is user testing. Planning a user test, writing a test script, recruiting test users, setting up a testing facility and equipment, running the test sessions and producing a findings report can easily take a week or two, or even a month if you need to run the tests on the other side of the planet; the agile software development team usually will not be happy or willing to wait for this kind of a delay.

This does not have to be so. As a matter of fact, the original Agile Manifesto does not explicitly exclude any elements of human-centred design.

There is no fundamental disconnect between these two approaches to product creation. As an example, Nielsen[7] and Patton[8] have elaborated on the applicable ways to integrate user experience design with agile software development. Based on my experiences in various Nokia product development environments, I would highlight the following best practices:

1. Assign UX designers to work in Scrum teams. Separating UX design from the software implementation may be practical in certain cases, such as with the use of a design vendor or software subcontractor several time zones away, but usually the maximum efficiency and effectiveness is reached when designers, developers, architects, marketers and testers work together. Sometimes this integration requires all disciplines to show some extra flexibility, e.g., when it comes to the physical workplace, but most often, this cross-disciplinary collaboration is highly beneficial and leads to a better quality product within a shorter total development schedule.

2. Treat UX design a bit like architecture development; the big rocks need to be turned first. Just as there must be a software architecture blueprint before the coding starts, there needs to be a UX architecture blueprint, covering the foundational elements of the information, interaction and interface design. Preferably, the software architecture reflects the UX architecture needs. UX design can and should move one or two sprints ahead of the agile software implementation sprints, in order for the more substantial design exploration and design decisions to be made, based on possible user testing, as appropriate. During the software implementation sprint, the UX designers will then support the software engineers, and the sprint will deliver both the software and the corresponding design documentation. If your product development is organized in a number of parallel software projects5, a master UX blueprint and design management function will enforce cross-product UX consistency and quality.

3. Establish a continuous user testing and feedback loop mechanism. Agile development aficionados sometimes claim there is no room for UX work in their project because there is no time to start setting up usability tests during the fast-paced development sprint. Oddly enough, these same projects often run into difficulties at the end, when it is found that the delivered software is so difficult to use that users simply don’t get it, and even the sales team supposed to sell it doesn’t either. To be able to run user testing effectively and efficiently, one should set up a mechanism where the test facilities, test users and testers are readily available. If your development project is large enough (and if the product will actually have users!), you may even want to set up weekly or biweekly user tests even before you know what is going to be tested. In a large project, there are always new designs and software to be tested, and it is a lot faster if the test facility is pre-booked and test users have been scheduled.

4. User stories build UX quality. A ‘feature’ in agile jargon denotes the smallest possible combination of related functionality that can be marketed to consumers. A feature consists of one or more ‘user stories’. User stories define what the software project will implement. Write the user stories in the user’s language, and do not just try to camouflage technical requirements as user stories, which can easily happen in an engineer-driven product development culture. A user story describes a requirement from the real world, like: “As a user, I can rotate an image both clockwise and counter-clockwise and can save the new orientation permanently.” At some point in the process, there must be one or more test cases associated with the user story, so that the project team and the customer representative can verify that the user story is ‘done’.

5. Use appropriate levels of UX prototyping fidelity. Rapid UX prototypes, made, for example, with paper prototyping techniques, can help the design team to resolve major design issues very cost-efficiently in the early phases of the design and development process. Later in the process, higher-fidelity prototypes, such as interactive Flash or QML simulations, are more useful when the more detailed interaction design and visual UI layer is being developed. In the optimal case, you are able to use a rapid prototyping tool, such as Qt Creator, that integrates directly with your production software development environment. Often, it is useful to treat the design prototype as part of the requirements specification for the implementation work, and then use that as the iteration baseline.

6. Definition of Done to acknowledge UX. The agile movement was started by programmers for programmers, and as such it did not have any strong linkage with human-centred design. Luckily, there is the Definition of Done—one of the key tools the agile practitioner uses to ensure that, at the end of each sprint, the team has a potentially shippable product. The Definition of Done should include checkpoints to guarantee that the user story is in place and sensible, that there is design work being done if the project is working on something that has a user interface, that there is adequate user research and testing being done, as appropriate, that the user testing results are approved by the product owner and that the design documentation delivered by the sprint is in line with the software that is delivered. So, there is no real rocket science here, but sometimes you really need to start with the basics, even to ensure that there is a competent designer allocated in the project. What we’ve observed is that a new software development team sometimes does not really see value in user-centred design, user testing or even having access to user experience designers. Only after they have delivered their first product to the real people out there, do they usually start to acknowledge the value that the UX practitioners can bring to the product development work.

7. Designers are not users, neither are developers, and vice presidents certainly aren’t. Whenever a product is being developed for users or consumers outside the development organization, the designers and developers should follow human-centred design principles professionally, i.e., not use themselves to represent the target users—unless they do represent them, of course. Designers need to be mature enough to kill their darlings, developers should not deliver architecture and code that only tries to minimize the development effort or just to show off their coding wizardry, and vice presidents should not force the inclusion of their pet features in a narrow-minded manner.

Epilogue

There are variations and nuances to the aforementioned principles, based on the magnitude of the design and development exercise, whether it is new development from scratch or incremental development on top of an earlier product release, whether the available designers can be co-located with the software development team, whether you are introducing some ground-breaking new innovation or something your competitors have already made familiar to the users and consumers out there, whether you are developing a web service or an embedded software product, who and where your users are, and what the schedule constraints are. Product design and development are really all about people, about the cross-disciplinary team collaborating and communicating to develop something appealing and usable to the real people out there. The combination of human-centred design and agile development is a good approach to make this happen, when applied consciously and with understanding of the product design and development context.

About the Author

Harri Kiljander is a user experience design leader and design strategist with 20 years’ experience in the software and mobile communications industry. He is currently leading UX design and brand development at F-Secure Corporation, creating computer and internet security products and services to protect the irreplaceable.

Before joining F-Secure, Harri worked at Nokia in various UX leadership positions, most recently heading the UX design work of the Maemo unit, designing appealing and usable mobile computers powered by Nokia’s Linux-based Maemo operating system, now called MeeGo. Prior to that, he was responsible for Nokia’s corporate UX strategy development, and worked in various UX design management and research positions in Nokia’s Internet service, research and development, and brand management teams in Finland and the USA.

Harri holds a Ph.D. in Interactive Digital Media from Helsinki University of Technology. He also holds a number of patents in the area of mobile HCI and is a co-editor of the book Mobile Usability: How Nokia Changed the Face of the Mobile Phone.

His other interests include architecture, photography, sailing, and raising two creative children.

[1]. Nokia N900. 2009. http://maemo.nokia.com

[2]. Nokia 2110. 2009. http://conversations.nokia.com/almanac/nokia-2110

[3]. Lindholm, C., Keinonen, T., Kiljander, H. How Nokia Changed the Face of the Mobile Phone. 2003. McGraw-Hill, ISBN 0-07-1385142, 304 pages.

[4]. Giudice, M. Can’t We Just All Get Along? Human-centered Design Meets Agile Development. 2008. http://bauhaus.id.iit.edu/externalID/presentations/drc08_mariagiudice.mov

[5]. Kettunen, P., Laanti, M. Combining Agile Software Projects and Large-Scale Organizational Agility. 2006. http://research.nokia.com/publications/combining_agile_software_projects_and_largescale_organizational_agility

[6]. Agile Manifesto. 2001. http://www.agilemanifesto.org

[7]. Nielsen, J. Agile Development Projects and Usability. 2008. http://www.useit.com/alertbox/agile-methods.html

[8]. Patton, J: 12 Best Practices for UX in an Agile Environment. 2008. http://www.uie.com/articles/best_practices/, http://www.uie.com/articles/best_practices_part2

UX Then and Now

I entered college in 1969. This is a 40 year retrospective of both the UX profession and my career in it.

College—1969-1974

I did not have a clue as to what I might do after college. Back then, in America, we did not even think about careers while in college, the world was our oyster, and we focused on exploring what was interesting. Not to mention various ways to change or save the world! It was, after all, the late 60s and early 70s. A liberal arts education, largely self-defined, was considered the best route to a successful career.

I went in thinking I might focus my studies on English, I loved to read and write, but early on discovered the field of Psychology. I sensed this might be a good field for me, but floundered around in classes on clinical, social, perceptual and behavioural psychology; I managed to eke out a major, but was not really grabbed by any of it. I just sensed that B. F. Skinner, the famed psychologist who believed you could only study behaviour, as mental processes were invisible, was missing the important stuff!

Having grown up in a very isolated, small, rural environment (an island in fact) with a single mediocre high school, I was also still grappling with the culture shock of living in a city for the first time and adjusting to an Ivy League subculture and academic standards. After just a few weeks into my third year at college, with my requirements for a degree in psychology all but done, I bailed out and took a year off. Not a very productive year, but it did convince me I needed to finish college and gave me more focus. I went back the next year and mostly completed a secondary degree in music, great fun and very satisfying, but hardly on any career track. Then towards the end of my college years, I enrolled in a very new offering in the psychology department: Cognitive Psychology. Bingo! I knew I had found my passion.

Master’s Degree—1974-1977

Still having no real thoughts about a possible career, I applied to graduate schools that offered cognitive psychology programs, excited to study in this emerging and fascinating field. At the University of Denver in Colorado, besides learning about human cognition, I also learned about computers.

I had no experience with computers until I got to graduate school. There were, of course, computers back at college in the very early 1970s, but they were generally only accessible to students specializing in engineering and certain sciences. Back then, it was punched cards and teletype machines at first, but by the end of my Masters’ Degree (my third year in graduate school, 1977) I was working with a DEC PDP-11, a 16-bit mini-computer about the size of a chest of drawers. By this time computers had become practical and affordable enough to find their way into other academic disciplines, including psychology. I learned how to program in Fortran for the purpose of running statistical analyses for my thesis advisor, and for my master’s thesis I built a computer model of human learning and problem solving, as well as programming an online problem solving task for my research subjects. Along the way I also did research assistantships, studying behaviour in a primate lab, and conducting research on IQ with subjects in a state penitentiary.

After a summer off, living in London, I transferred to Tufts University in Boston, MA, to complete my Doctorate. Near the end of my first year there (my fourth year of graduate school ending in 1978), I discovered that no grant money was available for the summer. Up until that point, my whole graduate school career had been funded by research assistantships which paid my tuition and also offered a barely-poverty-level stipend to live on. I still had not spent more than a second or two considering what I would actually do when I grew up. Hmm. Should I go home to my old waitressing job for the summer, or try to find a real job in Boston? It was the Spring of 1978. I was 27 years old, with four years of college and four years of graduate school under my belt, but as of yet, no experience in the real working world.

Doctoral Degree and First Job—1977-1981

I perused the wanted ads and noticed a lot of jobs available for computer programmers. There were lots of high tech jobs, but very few people coming out of college with any concentrated training in computer science. Few, if any, degree programs yet. Companies were hiring anyone smart and motivated and providing on-the-job training. I did have some skills programming in Fortran so I applied for a job in a very small startup consulting company, founded and run by three MIT graduates. I did not mention that I only needed a summer job and expected to quit and return to my doctoral program after the summer. Much to my amazement, I was hired. Once I started, I discovered I had co-workers working on doctorates in English Literature, History and the like.

Come Fall, I was really enjoying the job—especially the pay! I found out later I was the lowest paid professional in the company at $10,000 USD a year, but to me, after living on graduate school stipends for four years, it felt like I was rolling in money. I did not want to give it up, so I convinced my graduate program to allow me to keep a full time job and finish my doctorate around it. I only had some independent studies, some exams and a thesis left to do. They were reluctant, being a completely academic and unapplied sort of program who looked down their noses at industry, but grudgingly gave permission.

I spent the next three and a half years working very hard; 50-60 hour weeks programming, travelling and trying to complete a doctoral degree at the same time. But I was young, single and full of energy and motivation. At work, I learned to program in Basic, worked on DEC timesharing mainframes and brought my handwritten draft documents down to a word processing department. We were experimenting with a brand new cutting edge technology in the office—email. The only people I could email were my co-workers on the same floor as myself, but we were trying to stay ahead of the curve. Fax machines were the latest thing.

But while programming was engaging, challenging and fun, I was really pretty bored with the business applications I was building, and generally still much more interested in psychology than technology. Nevertheless, I was enjoying my ever increasing pay, and as I approached 30, I actually started to think for the first time about what I might do for work after graduate school. My only real prospect with a PhD in Cognitive Psychology, a very academic field with few practical applications at that time, was to become a professor in a university and teach and do research, for a fraction of my salary as a programmer and likely in someplace I would not want to live.

For my doctoral thesis, I conducted research in to what extent people who are untrained in formal logic, use it in their everyday problem solving activities. Research finding: they do not. Little did I know that this research and finding would be so relevant to my future career. Engineers trained in, and fascinated with, formal logic, were designing user interfaces for people with no similar training or interest. Usability is very much about recognizing this basic fact and rectifying it by bringing knowledge of cognitive psychology into the design process.

As I approached the completion of my PhD thesis (it took me another four years beyond my masters, as I was working full time while completing my degree), I still needed to fulfil two other requirements: a foreign language, and a competency exam in a secondary area of specialization. Somehow I managed to satisfy the language requirement with Fortran! I guess programming languages were still new and glamorous enough back then (1980) to be considered comparable to human languages. And as for a secondary area of specialization, well, I discovered there was a little known and much disdained subfield of psychology taught in my department called “Human Factors Psychology”. Having never really heard of it before, let alone taken any courses in it, I scrambled to study for an exam in that area.

At that time the field of Human Factors had been around for maybe 35-40 years, having emerged in WWII, but was very focused on the design of military equipment and other hardware products. Human factors in software design was just a gleam in a few peopIes’ eyes at that point. But now I had glimpsed the possible connection between psychology and technology. I tried to interest my small company in supporting me in exploring this connection, but failed to do so. It was time to move on.

UX Career, Corporate Jobs—1981-1984

And this is how I found myself, in 1981, 30 years old, with a doctorate in Cognitive Psychology and four years working in a software development company as a programmer and technology consultant to big businesses. And, lo and behold, in fact the field of software usability was just beginning to emerge from the parent field of Human Factors right at that time! Serendipity at its best!

Somehow I found a headhunter who specialized in placing traditional human factors professionals; and he found me a job with Honeywell Information Systems in the Boston area. They had two human factors professionals on staff, but their background and work was primarily in hardware and industrial design and they were in a different department altogether. I was Honeywell IS’s first dedicated software usability professional, reporting directly to a software development department. Neither they nor I had much of an idea what I should actually do!

I remember my first year there, Dr. Ben Shniederman was brought in to teach a one day course on software usability, and I first met Dr. Susan Dray, my long time friend and well-known colleague, who introduced me to the Human Factors Society annual conference. In this way I started to connect to others pioneering in this emerging field. Honeywell IS at the time was selling hardware and software office automation systems, competing with Wang Labs. No one had heard of WYSIWYG back then, and there were no graphics in software user interfaces, all text and numbered menus and monochrome screens. For example, in a Word Processor back then, you might be faced with a black screen and a menu in green upper case text which took up the entire screen (no windows of course, just a screen) such as this:

1. OPEN

2. PRINT

3. COPY

4. MOVE

You would enter the number of your choice in a fill-in field and then press the Enter key, after which you would be similarly asked for parameters such as directory names, document names and printer names. Once inside your document, if you wanted, for example, to make a word bold or italic, you would have to enter special characters before and after the word in question, which would be translated only at print time. The mouse was a cutting edge device not yet widely used. Everything was keyboard driven. I did user research and wrote Style Guides and built a business plan for growing the usability function in my software department, creating a role as yet largely undefined. I think at that time my title was “User Interface Designer”.

I moved on to Wang Labs after a year or two at Honeywell IS. More hardware and software office automation. Jonathan Grudin, another well known pioneer in the field, joined the company while I was there. We had a colleague there named Carrie Ehrlich who not only had usability skills but also organizational skills. Most of us back then came from a similar background with advanced degrees in cognitive psychology.

Carrie single handedly created, grew and managed a sizable usability department at Wang that was more effective and had more impact than many do today. The way she accomplished this was very clever and remains one of my favourite stories from these early days. Without anyone’s permission, or request, Carrie decided to run a usability test (probably the first ever done at Wang) on a major new release of Wang’s flagship product, after it was publicly announced but just before it was released. She managed to talk several very high level vice presidents into serving as test users (probably none of them had ever before actually used any of the products they managed.) As she knew would happen, they all failed miserably to figure out how to do the simplest of tasks in the software, which shocked them into grasping the importance of the user interface.

The first thing that happened was that the product release was delayed, practically unheard of back then once a product was publicly announced, until its user interface problems could be addressed. Then, practically overnight, Carrie was assigned to report directly to one of these vice presidents, grow a department of usability expertise and integrate that expertise into Wang’s product development departments. She was given significant power and support from very high up to do so.

In 1983 I attended the very first conference dedicated to software usability, a precursor to the formation of ACM SIGCHI and the first SIGCHI conference. The Apple Macintosh was the latest thing, and Windows had its first GUI user interface, a fixed pane (vs. overlapping windows) environment. Wang was struggling to keep up with these developments.

UX Career, Academia—1984-1986

That year, I also left Wang Labs for an assistant professorship in the College of Computer Science at Northeastern University in Boston, Massachusetts, where I taught what were probably some of the first courses in the country on software usability, design and methodology, in a computer science curriculum. It was then and there that I first began to develop the methodology ultimately documented in my 1999 book The Usability Engineering Lifecycle (Morgan Kaufmann Publishers).

Two interesting things came about during my time at Northeastern University. First, a publisher recruited me to write a text book on software usability. Ben Shniederman’s first book was newly out, opening a new market with practically no competition in it. I started writing, but it was slow going and took me until 1992 to get the book published: Principles and Guidelines for Software User Interface Design, Prentice-Hall. The interesting thing to me about this “ancient” book of design guidelines, is that in spite of the fact that most of the examples in it are from mainframe or very early GUI platforms, pretty much every principle is still completely relevant to present-day GUI desktop applications and web sites. The principles just have to be adapted to the changing capabilities of technology. But since they are quite general and based primarily on human cognition, they are essentially timeless.

Second, I wrote a business plan to found an institute for usability research within the College of Computer Science, and started an effort to raise funding from software corporations. As it happened, this institute never came to be, so I moved on.

UX Career, Consulting—1986-Present

By the end of 1985, I had come to the conclusion that neither large corporations nor universities were the right work environment for me; and I launched my own consulting business in January of 1986, jumpstarted with some regular consulting work with my past employer, Wang Labs. Early clients included other high tech vendors and universities, and some financial institutions.

I bought my first personal computer, a boxy little Apple Macintosh with a single floppy disk drive. I tried to learn how to market my services, but was not very good at it. Fortunately I was perhaps one of the first full time consultants in software usability in the country, and clients found me. I had no website back then, and my business came almost entirely through contacts I made teaching in the tutorial programs at the SIGCHI annual conferences, and then by word of mouth. My laser printer cost $3,500, and I spent a fortune creating and mailing brochures in response to inquiries.

Also in 1986, I joined with other usability professionals in the Boston area to host that year’s SIGCHI conference. I met other pioneers like Marilyn Mantei, Raoul Smith, Arlene Aucella, Aaron Marcus, James Foley, Dick Pew and many others, who remain good friends and colleagues to this day. We had a grand time working together on this early conference. I also first presented a tutorial I taught for many years called “Managing the Design of the User Interface” which was the foundation that evolved into my Usability Engineering Lifecycle methodology.

As my practice took me all over the country and to other parts of the world, I also wrote books, as mentioned: The Usability Engineering Lifecycle published in 1999 (Morgan Kaufmann Publishers) and Cost Justifying Usability with Randolph G. Bias in 1994 and 2005 (Morgan Kaufmann Publishers), as well as contributing chapters to other books. Around the time of the publication of my Lifecycle book, I started referring to myself as a “usability engineer”. Only relatively recently, say in the past three or four years, have I started calling myself a “user experience engineer.” I like that term a lot, as it allows that a good user interface requires more than usability, it may also entail great graphic design, and effective marketing and sales (i.e., persuasion) techniques as well.

Reflections

When I was a professor in the College of Computer Science at Northeastern University, students had to commit to specializing in computer science in their first year. It was a five year program that included regular internships in local high tech businesses. I remember I would often be advising students on what courses to take. I would see students in their fifth year and close to graduation who would ask my advice on whether to fulfil a few remaining electives with courses on, say, compiler design or database design. Which would improve their resume? I advised them to take this last opportunity to try some courses outside the computer science college such as English Literature, Psychology, Anthropology, Music or Art. They were always appalled at this advice as they were, unlike my generation in college, very focused on preparing for a career, and saw no value in taking courses outside their computer science specialty. Sadly, I think that is still true of the current generation of students, reinforced by poor economic times and job shortages. College has come to be viewed almost like a professional trade school.

But I think my story attests to the value of a liberal arts education. You just never know where your interests will take you, and what new fields will emerge that will require interdisciplinary skill sets. I have always felt that I had an edge over professionals who came from narrower backgrounds. I felt I had more perspective and a greater breadth of knowledge that helped me think outside the box. And while I have seen successful UX professionals develop from many different backgrounds, I also remained convinced that the best academic background for an aspiring UX professional is cognitive psychology.

I now have a 17 year old daughter who is about to graduate from High School and go off to college. She is a very talented singer and musician whose aptitude emerged at a very early age. She has had a great deal of training, has done very well in state and national competitions, and has met, performed with and been recognized by an amazing variety of very successful professional musicians (see www.katiemayhew.com) all by the age of 17. Probably any conservatory would take her. But, she will be attending a liberal arts university (albeit with a conservatory affiliated with it)—both her preference and mine. She will take psychology and biology courses as well as music and theatre, and probably other subjects neither of us can even imagine right now will draw her interest as she matures. Even for someone with such a clear focus and talent from such an early age, this feels right to me.

My independent consultancy is now in its 25th year—not much younger than the field of UX itself. At various times I was tempted to grow a business (that is, hire employees), but am glad I resisted that temptation and remained an independent consultant. I have enjoyed the autonomy and flexibility of being completely independent. I have had to reinvent myself several times, as the technology and economic climate changed, and I am sure I will continue to do so. It’s much easier to do this when you are a one-person business. I am now working on my latest re-invention and I expect 2010 to be a very exciting year. Stay tuned!

About the Author

Dr. Deborah J. Mayhew, internationally recognized consultant, author, speaker and teacher in software and web usability engineering since 1981.

Dr. Mayhew is known as an early pioneer in software and usability engineering and user interface design. Beyond her native USA and Canada, Dr. Mayhew has been invited to consult, teach or speak in countries in Europe, Asia, the Middle East, South America, and Africa.

Deborah Mayhew’s highly regarded books have been sold in many different countries.

The Story is the Thing

Here’s something I believe in: stories are what make us human. Opposable thumbs? Other animals have those. Ability to use tools? Ditto. Even language, in and of itself, is not exclusive to human beings.

From my amateur reading of science, as it currently stands, the story behind our stories goes something like this: the human brain evolved with an uncanny knack to recognize and create patterns; and through some strange twist of natural selection, gradually over millions of years, our brains started turning the incredible power of that pattern-making machinery on ourselves, until we became self-aware.

Aware of ourselves—our own faces, bodies, journeys, homes, children, tools, and everything else around us. Over eons, we went from being creatures that lived in each moment as it came and went, to protagonists in our own myths. Everything in our midst became the material for making stories, strands of moments woven into tapestries that we call things like “nation”, “family,” “love” or “discovery.”

And “design.” Because design is, ultimately, a story we make. And designing is an act of weaving a new story into an existing fabric in such a way that it makes it stronger, better, or at least more interesting, and hopefully more delightful.

An Origin Story

My identity as an information architect happened accidentally, and gradually. I just kept doing things I liked, that people were willing to pay me for, until I woke up one day and realized I had a career. And the things I liked doing were invariably surrounded by people’s stories.

One of the earliest jobs I had out of college (after trying my hand at carpet cleaning, waiting tables and telemarketing) was as an office manager in a medical office. It was 1990, and this office of five or six providers was running entirely on a phone, a copier and an electric typewriter. No computer in sight. Every bill, insurance claim, or patient report had to be typed anew … as if the 80s had never happened. I talked the owner into getting a computer and a database management package—sort of Erector set for database application design that I’d seen at a computer user group a year before—so I could make the office more efficient.

It would’ve been pretty easy to create a quick application with a minimal user interface, if I were the only one using it. But the owner also had a couple of people helping in the office part-time who needed to use the system too—people who had never even used a computer before. Did I mention this was 1990?

So I had a challenge: how to make it work so that complete computer newbies could use it? It was frustrating, fascinating, and probably the single most important experience of my work career, because it was a crucible for acknowledging the importance of understanding the user.

To understand the people who were to use the application, I had to talk to them, get a sense of what they’d done before and what sort of forms they had used in the past. What sorts of technology? What terminology was going to make sense for them? How do they tend to learn—by written instruction or hands-on activity, by rote or through improvisation? I learned these things by watching and conversing. Eventually I had enough of a sense of those “users” that I had a full story in my head about how they came to the experience of this particular application, in this particular place.

I wasn’t conscious of this at the time; and I was working completely by intuition. I would’ve done a better job if I’d had the experience, methods and tools I’ve picked up since. But looking back, the experience itself has become a story I tell myself when I need a rudder to remind me of my direction as a designer so that, even when I have nothing else to go on, if I just watch, listen and absorb the stories of the people for whom I’m designing, my design will be heading, at least generally, in the right direction.

An Architecture Story

Much later, about ten years ago, I was working at a web design agency, and our client was an organization that acted as a sort of confederation of research scientists, universities and technology corporations. The organization funneled research money from “investor” companies to the scientists and their students in the universities, and in return the companies received “pre-competitive” research and dibs on some of the brightest graduate students when they graduated.

Their website had evolved like so many in those days—having started from a few linked documents, it had grown by the addition of ad-hoc sections and content created in response to member requests and complaints, until it had become a horribly unwieldy mass of links and text.

We had been called in to clean it up and organize it. That sounded straightforward enough. But when we started interviewing its users, we found people who were unhappy with the organization and its community in general—scientists who had become more entrenched in their own sub-disciplines, and divisions between those managing the community and those merely dwelling there. Not to mention the natural enmity between academics and business leaders.

We realized that the web site had become a visible instantiation of that discord: a messy tangle of priorities in tension. A new information architecture would mean more than just making things more “findable.” It meant trying to make a digital place that structurally encouraged mutual understanding. In essence, a more hospitable online home for people with different backgrounds, priorities and personalities. It was a chance to create a system of linked contexts—an information architecture—that could help to heal a professional community, and in turn strengthen the organization founded to support it.

That project provided an insight that has forever shaped how I understand the practice of information architecture: the web isn’t just a collection of linked content, it’s a habitat. And the structures of habitable digital places have to be informed by the stories of their inhabitants.

A Survival Story

Much more recently, I had the opportunity to work with a non-profit organization whose mission was to educate people about breast cancer, as well as provide an online forum for them to share and learn from one another.

When interviewing the site’s users, it soon became clear how important these people’s stories were to them. They would tell the tale of their cancer, or the cancer of a loved one, and in each case the story was one of interrupted expectation—a major change of direction in what they assumed to be the storyline of their lives.

I learned that this website was merely one thread in a great swath of fabric that the site would never, ultimately, touch. But the site was most valuable to these people when it supported the other threads, buttressed them, added texture where it was needed, especially when it helped fill in the gaps of their stories: How did I get cancer? What do my test results mean? What treatment should I choose? What can I eat when getting chemo? How do I tell my children?

They wanted information, certainly. Articles full of facts and helpful explanations. And the site did that very well by translating medical research and jargon into information people could use.

But even more than the packaged articles of information, so many people wanted—needed—to share their stories with others, and find other stories that mirrored their own. The most valuable learning these people discovered tended to be what they found in the forum conversations, because it wasn’t merely clinical, sterile fact, but knowledge emerging organically from the personal stories, rich in context, written by other people like them.

One woman in particular lived on an island in the Caribbean, and had to fly to the mainland for treatment. There were no support groups around her home, and few friends or family. But she found a community on this website; one that would cheer her on when she was going to be away for tests, console her or help her research alternatives if the news was bad, and celebrate when news was good. She made a couple of very close friends through the site, and carried on relationships with them even after her cancer had been beaten into submission.

Here were stories that had taken hard detours, but had found each other in the wilderness and got intertwined, strengthening one another on the new, unexpected journey.

This work, more than any other I’d done before, taught me that stories aren’t merely an extra layer we add to binary logic and raw data. In fact, it’s reversed—the stories are the foundations of our lives, and the data, the information, is the artificial abstraction. It’s the dusty mirror we use to reflect upon ourselves, merely a tool for self-awareness.

It was through listening to the whole stories as they were told by these digital inhabitants that I learned about their needs, behaviors and goals. A survey might have given me hard data I could’ve turned into pie charts and histograms, but it would’ve been out of context, no matter how authoritative in a board room.

And it was in hearing their stories that I recognized that, no matter how great my work or the work of our design team might be, we would only be a bit player in these people’s lives. Each of them happens to be the protagonist in their own drama, with its own soundtrack, scenery, rising and falling action, rhyme and rhythm. What we made had to fit the contours of their lives, their emotional states, and their conversations with doctors and loved ones.

The Moral of the Story

Design has to be humble and respectful to the presence of the user’s story, because it’s the only one that a person has.

Stories can’t be broken down into logical parts and reconstituted without losing precious context and background. Even though breaking the story down into parts is often necessary for technological design, the story lives only if there’s someone who can serve as a witness to the whole person, with a memory of his or her story as it came from that person’s mouth, in that person’s actions.

Keeping the story alive keeps the whole idea of the person alive. Whether we use “personas” or “scenarios” or task analysis or systems thinking, the ultimate aim should be to listen to, understand and remember the stories, precisely because the stories are the beating heart of why we’re designing anything at all.

So, now, when I’m working on more mundane projects that don’t touch people in quite the same way as some of the others I’ve done, I still try to remember that even for the most everyday task, something I design still has to take into account the experience of the whole person using the product of my work. That, after all, is what we should mean when we say “user experience”—that we seek first to listen to, observe and understand the experience of the people for whom we design. We honor them in what we make when we honor their stories.

About the Author

Andrew Hinton is Principal User Experience Architect at Macquarium, a UX consulting firm headquartered in Atlanta, GA.

An internationally recognized speaker and writer on IA and UX, Andrew has been designing information systems in one way or another since 1991 for Fortune 500s, small businesses and non-profits alike. He helped start the Information Architecture Institute in 2002, and currently serves on its Board of Directors. Andrew is a big believer in the practice of information architecture, which (to to his mind) concerns the design of contexts and their connections in digital space. Andrew lives in Charlotte, North Carolina, blogs at inkblurt.com, and tweets via @inkblurt.

Chapter 3

“The other day when I was walking through the woods,

I saw a rabbit standing in front of a candle

making shadows of people on a tree.”

Stephen Wright

Three Stories

One

During our 2009 visit to Helsinki with my partner Jo Wong, our taxi picked us up on a cold morning from our friend’s place in Lauttasaari, an island about 3 kilometres west of Helsinki’s city centre. We were on our way to a business meeting and running a little late. As we arrived at our destination, the driver noticed that I was playing with my Nokia E61i; I was texting a colleague to announce our arrival. He glanced warmly at me in the driver’s mirror, started to smile, and reached into his pocket. He then turned around quickly and held up the same model Nokia E61i, waving it in the air and saying proudly, “See, Nokia too!” At that moment, it was clear to Jo and I that we were not only officially in Finland for the first time, but we were also visiting the home of Nokia, and its people who are very proud of their home-grown product.

It also made me proud to be experiencing user experience with the people of Finland themselves.

Two

The other night, I was watching a documentary on TV about the evolution of the camera, wireless radio, air travel, morse code, the automobile and the underlying need for people to communicate outside their local communities. Humans need to travel and explore. As I enjoyed dinner with my wife, we both laughed at the effort and number of steps needed to start the Model T Ford, the weight of the first cameras used to record film footage (without sound) and the restricted time of the recordings, the open cabin of the first flights, and so on.

We really do take so much for granted and in doing so, become spoilt about both the technologies and luxuries around us. Yet, in 2010, we still face some challenges about what it means to move forward together in sustainable ways. We still have so much work ahead to improve products and services and the experiences we want to give to each other. So as I look at my own home with TV, Wii, wireless internet, iPod touch, laptops, mobile phones, desktops and other modern conveniences, perhaps the question that arises is how much more do we all really need?

Three

On a recent trip to the USA, I was reminded of something very important. I had been invited to speak to students at CMU’s HCII[1]. This was my first visit, and my impression of Pittsburgh was that of a place going through a renaissance, with a layer of creatives and future thinkers rising up from an old economy of steel mills. A grounded place with wise and passionate people. There were some delays during my week in Pittsburgh because of the severe weather conditions caused by snow and storms—but it gave me more time with friends and also an opportunity to see the city and prepare for my presentation.

A small group of students had turned up for the presentation and I had chosen to talk from the lectern, partly because the presentation was being filmed and also because it seemed like the right place to present from, since I was the “invited speaker.”

But I had missed the opportunity to really move away from the lectern and sit with the students at the table to have a more personal discussion on the topic of UX and Selling UX. A good friend and colleague said to me later when he picked me up from CMU “it’s really a presentation to your peers,” and so it was.

Remember, regardless of where you are in your life, remain grounded, remember your beginnings, and treat everyone as both your peers and equals.

About the Author

Daniel Szuc is Principal Usability Consultant at Apogee, a usability consulting services company based in Hong Kong—www.apogeehk.com.

Daniel has over 10 years experience in User Experience and previously worked on a usability team for Telstra Australia and has lectured about usability and user experience in Hong Kong, China, Singapore, Malaysia, Australia, the USA, New Zealand and Japan. He co-wrote a Usability Kit with Gerry Gaffney which is an implementation guide providing best practices and guidelines for usability teams.

Daniel is the Vice President of the Usability Professionals Association (2010) and holds a BS in Information Management from Melbourne University in Australia.

[1] .http://www.hcii.cmu.edu/ in Pittsburgh

Hundred and Ten

“One day, a Water Rat called Bilargun was out hunting and he spotted a Duck in the distance. This duck was called Daroo, and Bilargun wanted Daroo as his wife. He snuck up on her and escorted Daroo back to his den. Here, he fed her and nurtured her. Together, they were very happy and Bilargun told Daroo that whenever she was in danger to slap her tail on the surface of the water. After a while, Daroo had a brood, but quite an unusual one. The offspring each had 4 legs and a fur coat like their father, and a beak and webbed feet like their mother. That offspring’s descendants can be seen nowadays, and they still use that same warning sign, and have the characteristics of a bird and mammal.”[1]

How the platypus came to be during Altjeringa, the Dreamtime. Traditional Australian story.

One

It is a cloudy May afternoon and I am reading a book, drinking some coffee and trying to find a way to make you grasp what I understand by information architecture. I put the book down and get back to the keyboard. I sip the last of the coffee and stare at the few lines I have written. I can not decide if they say anything at all. I decide they do not, I want it to be personal, as I believe design is like that, personal, and it can get complicated if you do not want to end up lecturing. I think of ways I could make you see me and tell the story without explaining it. I think: What do I do? I design information spaces. But I have always been designing. It has always been there. I hear the light tip-tapping of rain on the window. It was raining then.

Two

I was around 9 or 10. It was a methodical process: I was not a particularly methodical kid, but I could discriminate. This required method and some application. I used only regular-size exercise books, not too thick, not too thin, which only came in a yellow cover, God only knows why. Those had enough pages, but not too many. I had my tools and sufficient space on the table. I knelt on the chair and then I got going. Cover first, as this had to be redesigned carefully. I drew some kind of frame in inks and pens, usually something with an insane amount of Art Nouveau flourish on the corners, and then glued in a new sheet of heavy cloth paper inside the frame itself with white solid office glue. I still remember the smell of the thing, and its distinctive metallic container[2]. You had to apply the glue with its own small brush and make the paper stick properly. Trying to avoid bumps and lumps was hard work. Then I waited for the glue to dry, sketching dinosaurs or doing one of the many things that only seem important or interesting when you are just about nine. When I checked back after ten minutes I had a yellow exercise book with a framed, empty light space on the cover that opened up a world of possibilities and just called for more work. A five-step procedure kicked-in: find a title, decide a style for the hand-made lettering, figure out an image, draw the image, write the book from top to bottom; first draft is the right draft. This could take up entire afternoons for weeks, as the story would come up as I was writing it. Changes crept in due to a sudden inspiration from a Jules Verne novel, or a Donald Duck comic book, or something I saw on TV. But I do not remember ever finishing one single story: that was not where the fun was. The fun was in the possibilities, in the kick-off and in the design.

Three

When it comes to design, I do not believe in invention. I believe in interpretation, in pushing forward, in changing direction and in reaction. I see us move on largely by shaping and reshaping what we inherit from the past. This is pretty much everything I can say about my practice: it is never conjured, often derived and always the fruit of experience. I did not really know what, and why, worked back then, and I do not know now. I only know that at a certain point everything flows and communication is possible.

Four

I was in my early thirties. When I moved into my teenage years I did not get to spend much time with my mum. We just lived in the same place and that was all. This changed when she got ill and needed help, but even then, even when she was actually too sick to do anything more than move around her apartment or be driven somewhere by car, she fought fiercely and heartbreakingly for her independence. But I remember one occasion, some ten or twelve years ago, walking with her to some narrow backstreet shop or office not far away from the Cathedral in Parma. It was a small, new place inside a really old building, all timbers and bricks and carefully lit passages. I really do not remember what we were there for. Something bureaucratic, I imagine, as those were the only things where she would sometime indulge herself to a little help. Whatever it was, we finished early, and I just asked her if she fancied walking a little more and have a coffee in the Oltretorrente; the neighbourhood across the Parma stream where she grew up with her parents and her ten brothers and sisters after World War Two. Parma is a relatively small city in the North of Italy, lying just far enough from everything, the sea, lakes and mountains, it still maintains a rather peculiar interest in its feudal traditions. Like factions, for example. The Oltretorrente is the popular heart of Parma, the place were you were to be born, or grown up, or had to live, if you were to consider yourself a real Parmigiano. People from there could tell which street and sometimes which building you were from just by the way you spoke the local dialect. We walked past the many shops of one of the main streets, and crossed the bridge over the stream. The remains of the old Roman bridge are still half there, but it is now neglected and stretching over dry land, as the Parma has changed its course over the centuries. We walked left and entered the older, winding streets looking for a café. Then I noticed something: the city my mother saw in front of her eyes was a totally different city from the one I saw. While for me it was a geography of places and street names I knew from reading signs or from having been there before, she was following a personal cartography which was all people and persons. “We turn left where Gianni used to live when his father worked at the shoe factory”. “That’s Maria’s bakery. The second window on the right, second floor, that’s where your aunt Eva used to work as a maid before getting married”. “You remember Alberto? His mother’s family used to live just across the street from where we used to play as kids. Right there”. “Now let’s turn right at the house where the old Signora Pezzani used to sell her eggs and cheese, there are more shops over there”. I had to keep on reminding her I had neither the slightest idea who these people were nor where they lived forty or fifty years ago. If we wanted to move around at all it had to be second right or third left or keep straight on, for me. Her world was precise, but so intimate and so personal that I was not a part of it. It was a secure, conversant world, but it was a smaller, hard-to-communicate world.

Five

My dad put it straight down to me one morning just before my first year of the Italian equivalent of High School was about to start: “First day I find out you go to that school so you can boast, you are coming to work with me right away, young man”. He was a plumber, and he meant that, so I took his advice very seriously. I went on to become an architect, so I could command plumbers around in my houses, and thanks dad for that.

Six

“I do not like it”. “You might not know that now, but you are going to like it. A lot”. Italy in the 1980s had two different High School tracks: scientific and classical. I chose scientific. This amounted to a lot of different social expectations, perspectives and outcomes; but in the end, and after some rough confrontations with some of the students from the other pond, we agreed it was all about either having maths (as we did) or Greek (as they did). Latin was for everyone, five years of that. Also Art History, three years, both squads. This was it. I was 16, attending my 3rd year, and was looking at a picture of Piet Mondrian’s Composition II in Red, Blue, and Yellow. You know, the iconic painting with large primary coloured squares. I had just stated I did not like it, I meant it, and our Art teacher was commenting on my dislike. And he was right, of course. In time, I would find that Mondrian and Malevic, and so much of what is abstract art, were telling me something. Understanding teenagers that way is a precious gift, but this teacher was a long-haired, bearded, left-wing dispenser of questions, not answers; and this was the real treasure he shared with my classmates and me. He taught us the value of “it depends” when we needed to smooth out the edges of teenage cockiness. This was so many years before Eric Reiss started considering it just one more unnecessary step in the verbal click stream. I still have troubles relating the two, as if my “it depends” is actually something different from what Eric is stigmatizing. I get what Eric is saying now and why, and I agree, but “it depends” was not something you took for granted in Italy in the early 1980s. For the first time a teacher was telling us that asking the right questions was much more important than believing you had the right answer ready at hand. Reality is complex, kid, get over it. Oh, and by the way: welcome to the world of grown-ups.

Seven

I was 12. The curtains were partly drawn in the silent sitting-room at my grandparents’. I remember cicadas, so it must have been summer. My grandfather was working on one of his paintings at the table, standing, as I remember him doing most of the time, and I was sitting alongside drawing something and peeking at what he was doing. He had all his gouaches ready on a handmade palette, which looked as if he had been painting for millions of years, and was carefully building complicated patterns of multi-coloured dots into a scene which sported a Gothic church, the Sultan’s palace, towers and domes from some remote Russian province and leopards. Lots of leopards. My grandfather had worked his way through life landing a large number of wildly different jobs, as was common at the time; a family of thirteen was no joke even back then. Among other things, he had been a nurse, a travelling salesman, a professional musician, and a restaurant owner. But all of his life he had wanted to be a painter and could not afford it: after all there was no money to be made there. When he retired, he finally bought himself some colours and some brushes and started painting wherever he could: loose sheets he stole from grandchildren, spare plywood planks, a cardboard from a package, everything was good enough for him. He filled more than a thousand canvasses with images of the Opera he loved so much, and of all the places he wanted to see when he was younger and dreamed about, signing on as crew and cruising to other parts of the world. The Sultan’s palace, and the towers of Russia. He painted an amazing waterfall on a Formula One racing track box I owned, the cars just diving down into the blue water. To this day I do not know how he managed to snatch that away without me knowing. He was rather protective of his work, and was not very interested in showing, promoting or selling his stuff. After a few reluctant exhibitions which one of my uncles tricked him into doing, the critics started to take note. In a matter of years he was very well known and an internationally respected “naïf”, and then “art brut”, painter. He did not care, he was not there for that. He was there for the dots and the pleasure of turning to me, or to one of his innumerable nieces and nephews and asking “It’s a nice place, isn’t it? What else should we put there?” In an interview, he was asked “Benassi, why do you do that? Why do you paint?” The answer was damn simple. “Because I want to go to places I’ve never been before.” I still believe that is a pretty good answer. It tells you a story and lets you figure it out yourself.

Eight

I am 44. I have been married quite a few years now and I have a daughter who is 10. We live in a small university town in central Sweden, and in my daughter’s world the Internet, computers and mobile phones are a fact of life. She makes no distinction between physical and digital, and there is no such thing as virtual in her vocabulary. She has this game for the PS3 called Little Big Planet, a cute little platform game we play together. You can customize the way your character looks by dressing it up to be either a sackboy or sackgirl, in any way your creativity suggests. From ninja to cowboy to peacock to Jack Sparrow, you name it, you do it. And you can share your costumes with a vast online community, build levels and share these as well. These are her dolls. She dresses them up as chefs and then builds a level with kitchen appliances, and bakes videogame muffins. She is not scared of the possibilities.

Nine

My mum had the small world of the Oltretorrente as her universe, personal and mostly incommunicable. Communication is helping my daughter make the world her neighbourhood. She uses a webcam to talk to friends who are thousands of kilometres away, and she plays online with kids from the other side of the Earth. The perception of space and place and the way she experiences “being there” is necessarily going to be different from her dad’s, who, when her age, considered kids living two blocks away as a different tribe. Her world is getting smaller physically, but it is increasing tenfold semantically. It is cyberspace, and it is not the consensual hallucination in 3D Gibson envisioned in his early novels, but a layer which is becoming tightly integrated into the world around us. It is nothing like the TV I had when I was a kid, it is actionable, it is a place my daughter and her peers will live a large part of their lives in and they know it. It will always be there and they are not scared of the possibilities.

Ten

I design those information spaces where people like my daughter are going to live. I help shape the links, the connections, the semantics, and ultimately the map people will travel on. And in cyberspace, as Andrew Hinton is fond of saying, the map is the territory. That is why I call myself an information architect; because, in all frankness, I see no radical departure from what I did when I used to design apartments and buildings. My teachers designed the shops we visited for our weekly fix of music. We bought LPs, and these required shelves. I design the shops today’s teenagers visit for their fix of music. They download MP3s, so I design the paths to these in cyberspace and ways to store and find them in a place that has no necessity for shelves. My teachers designed the offices that people would visit to gather information about their taxes, their health or their civil duties. I design the way for people not to visit them and still receive the information they need. My teachers designed the houses, I help design our place in cyberspace: I am sure my daughter will appreciate it.

About the Author

Andrea Resmini is an information architect with FatDUX, a leading UX firm based in Copenhagen, Denmark, and UX practitioner, researcher and scholar at IDA, University of Borås, Sweden.

A long time IT professional, he holds a MA in Architecture and Industrial Design and a PhD in Legal Informatics and he has been practising information architecture since 1999.

Andrea currently serves as president of the Information Architecture Institute, chairs the Italian IA Summit, and is an associate editor for the Journal of Information Architecture.

[1]. Knights, A. J. (2007). The Platypus. All Empire.

http://www.allempires.com/article/index.php?q=The_Platypus.

[2]. A true product of an earlier age of design, you can find pictures of this incredible metallic packaging all over the Internet. One is here: http://images.manufactum.de/manufactum/grossbild/23354_1.jpg

Technical Capability is Only Half the Story

A Story

Once upon a time, there were two internet companies that had recently introduced interaction design teams. Both of these companies managed to hire talented interaction designers (IxD). While they did hire some good IxDs, they were not following a User Centered Design (UCD) process.

Their process was basically as follows. The product team would come up with the information architecture (IA) of a new product and the interaction design team would come up with the user interface (UI) and iron out creases from the flow given to them at a low level (micro IA). Changes would be made to the product once it went live, based upon studying how it was performing through reports from the Management Information System (MIS) and web analytics.

Now this was not a very optimal method of doing things. It would often be the case that after going live, the IA and UI would be modified. This would have been perfectly acceptable except for the fact that these modifications were to be made on high level structures—both in IA and UI. This, of course, was not easy to do, since the entire web application or website rested on these high level structures. All of this cost the company dearly in terms of time and money, which was being spent on issues that were never anticipated.

At this time, none of the companies were conducting any form of user research or usability evaluations. The interaction design teams in both companies were aware of this and around the same time, both teams, frustrated with the state of affairs as they were, and for the good of their respective companies, decided to try and introduce UCD techniques into their organizations.

The interaction designers thought that conducting user research would help them provide product management with better inputs for developing a better IA validated by representative users. Not only that, it would also help them design a better UI by validating its ease of use throughout the Product Development Life Cycle (PDLC) through conducting usability evaluations. Both teams managed to grab opportunities for usability testing during development of new products around the same time.

After a year had gone by, one team had managed to set up a small unofficial but recognized user research group which their company was quite pleased with. Not only that, they had a pipeline of projects to keep themselves busy for the coming months. On the other hand, the second team was faring rather badly. Nobody wanted to let them conduct any usability tests. A new product was in the making and they did not get to conduct any user research for it either. Their plan to introduce UCD techniques into the organization had pretty much failed and they were beginning to give up because of the lack of results they had seen. They were unimpressed by the response of the organization. Likewise the folks in their organization were unimpressed by the result of this group of interaction designers, who they thought would have saved time if they had simply stuck to what they were assigned to do in the first place.

If both these teams were very talented and technically capable, what exactly did one team do so right and the other so wrong? They both had the same destination, but took different paths in order to achieve it. The successful team put in extra effort, just as much as it did to technically implement its usability evaluations, to make sure that all their stakeholders—business leads, technical leads, product bosses, programmers and marketing folks—were happy and upbeat about the entire process, right from day one, whatever compromise it required. The other team simply conducted usability tests and cold bloodedly revealed its findings, which basically rather openly razed much of the work that the other teams were doing.

Takeaway

When you are trying to introduce UCD techniques in your organization and your goal is to ultimately integrate UCD into your organization’s Product Development Life Cycle, then arming yourself with technical capability is only half the story. The other half is your team’s ability to effectively deal with soft issues and successfully engage with stakeholders. With either part missing, you will not be able to go very far.

Technical capability is your team’s ability to make use of their collective knowledge of user research and usability evaluation along with IA and IxD methods so they can use the correct one or a combination of them in order to find out who the users are for a product and what they want and need. They can then validate assumptions about how users will use a product, and gather information continually about how easily the product being developed can be used by its intended users.

If you have strong technical capability (and by that I mean having a good understanding or experience of how to execute UCD techniques), you will naturally be able to demonstrate how valuable UCD can be when used on a project. But doing so is not as straightforward as it seems. When you try to do so, you will be met with varying levels of skepticism and quiet opposition. This is because, while you are in essence trying to simply improve the efficiency and effectiveness of the overall product life cycle, it is often interpreted by the others as showing inefficiency in the current way they are working, which is not a good thing for them. Nobody wants to look bad, especially when they can avoid doing so.

In order to implement your technical skills, you need to get hold of opportunities to demonstrate value in the first place. Then, you need to be appreciated for the work you are doing and get the right noises made so stakeholders and other influential people in your organization hear about the value the product has derived out of it. Going further, you need willingness from your stakeholders to take a few pains themselves in order to help you get further projects and set the ball rolling. In order to do so, you will need to effectively deal with soft issues all the way and successfully engage with your stakeholders. Otherwise known as ‘soft skills’, I will refer to it as soft capability.

Who are your stakeholders? They are everyone and anyone who is affected by your actions. This includes folks in product or project management, business, programming, analytics and marketing. That’s a lot of people, and that’s just how much opposition you might face when your user research actively crosses their paths. Folks from the product team may already go with the marketing guys for conducting interviews with users (they probably do focus groups too). The product guys already use sales and customer checkpoint data to keep a pulse on what the user feels about the product and the programmers simply don’t agree with the itsy bitsy changes you make to the interface and flow to enhance the user experience as it increases their work load in an already tight plan.

You may think that soft skills are not unique to the situation I’m describing and that they are required in any sort of occupation across the industry. That’s correct. But the difference here is ‘how important’ is it? The difference is about ‘good to have’ versus ‘required’. Let’s say, if an organization has a systematic usability process in place, then technical capability basically translates to successful implementation of UCD techniques for you. Here, dealing with soft issues, just as in any other work area, will help increase efficiency of the department. But if you are trying to introduce UCD methods into your organization, then technical capability does not translate into successful implementation. It is here that technical capability is indeed half the story, and ‘soft’ capability is the other half. You will be able to get a better understanding of what ‘soft capabilities’ are and how and when can they be used in the following two stories.

Example 1—The Key Keepers

Continuing from the previous story, this story puts a lens onto the team that tried to introduce user centered design (UCD) methods into its organization but had very little progress after a year.

One of the first opportunities the folks who wanted to try and introduce UCD techniques into their organization got was not on a company product but rather on their intranet. They had been assigned to work together on the redesign of the often complained-about search page, search results page and a new Collaborative Question Answering (CQA) feature. The interaction designers managed to convince the Vice President of Engineering, who headed the project, to give them the opportunity to conduct a series of usability tests on the new search that was being developed. They were unable to get him to let them conduct usability tests right from the beginning—from ideation into paper prototyping and then low fidelity wireframes, since he thought their time would be better utilized at this point devoting time to simply getting the UI design off the ground, based on stakeholder and product inputs. In any case, this would be a trial usability test and he could not afford to assign any resources on experiments. However, he did agree to let them conduct usability tests once they were ready with interactive prototypes since they would have achieved something concrete by then. In addition, he also agreed to let them do the same in the next iteration for CQA development as well.

The Vice President (VP) was quite pleased about the initiative taken by the interaction designers. Steve Krug’s book, ‘Don’t make me think’ had been lying on his work table for quite a while now and anybody who entered his cabin was sure to catch a glimpse of it. He had read a bit of it and it did make sense, though he would like to see results rather than simply reading about how usability could improve a product on paper. He enjoyed talking about how he was trying to bring ‘usability culture’ into the company and considered himself quite the usability evangelist. All in all, the interaction designers could not have found a better person to get an opportunity from because things were already slightly in their favor, thanks to his positive outlook towards usability. Now all that was required was to show him that this stuff really worked!

When the time came, they set about conducting their usability tests. Their plan was an elaborate one. It was longer than the VP expected, especially since he had asked them to simply send over a quick one page plan by email with the dates of the test as well as a short high level overview of what they would be doing, along with the test scenarios and tasks. The plan they mailed over attached as a lengthy eight page word document, had too much information in it according to the VP, and he simply called one of the three interaction designers over to his cabin and asked him to explain how they planned to proceed. The VP wanted all eight test sessions to be done in a day and wanted to to see the findings the very next day. The interaction designers however said it would take them at least two days to conduct the usability tests and then another two days to analyze the data after which they would have the report ready with the findings he wanted. So the usability test was not to wrap up in a maximum of two days as the VP would have liked to have it, but would take around a week, something he was not too pleased about.

The interaction designers chose to set up camp in a larger war room. This would be their usability lab which would allow one facilitator, a note taker and an observer for each session. They mailed everyone on the intranet project mailing list, informing them that there could be one observer for each of the eight sessions, and anybody interested could mail them back to book a slot. When the VP thus decided to drop by on a test session, he was requested to come for the next one since there was already an observer in the room. In the next session, when he chose to ask a few questions while the participant was undergoing a task, he was not allowed to do so and was requested to make a note of any questions he wanted to ask and ask them after the test, in the end during debriefing.

In order to keep a pulse on what the tests were revealing, he had asked the interaction designers to give him a summary of the test findings at the end of each day. But they were not very keen to do so as they did not want the findings to be known and spread by word of mouth before they could present a report of findings to the intranet team once all the tests were done. When the usability tests were over and they were analyzing session videos and making notes, the VP came by and enquired about what direction were the results generally pointing out to, and what the findings were, since by now they surely would have a fair idea of it. Being the guy who was introducing usability tests into the organization, he wanted to have a look at the results before they were presented to everyone else so he could generally talk over lunch with his colleagues about ‘how most of his assumptions were validated’ by the test. It was his baby, after all. However, the interaction designers were vague about it again; they really did not want everyone to know the results before they presented the findings and recommendations, thinking it would dilute the whole effort.

Eventually the day arrived for presenting the findings. It was presented to the VP and most of the leads from the programming and product teams, in addition to a few other programmers and product folks working on search. The presentation was well made and the recommendations were convincingly put forth. All in all, there were reluctant but agreeing nods to the findings. The report did not speak much about what was working well in the search and SERP (search engine results page), perhaps there were indeed not many positives. The report concentrated on the utter failure of the facetted search which was neither noticed nor understood by most of the participants, the excessive unused elements that cluttered each search result listing and also how the positioning of the search user interface failed to imply it was to be used for both global and local section searches. The report also let the interaction designers vent their frustration because they had pointed out the issues with facetted search and positioning of the search UI to the product team and the VP at the time of paper prototyping, but they had not paid much attention to it at the time. This point too was made clear during the presentation quite a few times.

Once the presentation was over, a bunch of programmers impressed with the empirical findings went over and congratulated the interaction designers on their work, although they now had a lot more UI fixes to make, thanks to the usability test recommendations that were agreed upon. And this was all the praise the interaction designers got. They barely received any praise from any of the senior folks on the project.

The report did not make the VP look good in any way. In fact it made him look bad. And so was his experience interacting with the interaction designers from the first day of planning for the usability test right up to the end with the report. The findings criticized most of the project at a structural level, constantly reinforcing the message that related risks had been pointed out but nothing has been done about them. What started out with a positive outlook towards usability had transformed into a bad exercise for him.

The VP’s final take was that the project could be seen as a waste of time since it took up a week and most of the findings they agreed upon were very minor changes they could have done without. At this stage, the plan could not accommodate structural changes and the VP, along with other heads, dismissed the results and quickly agreed that the sample size was too small. And this made it easy for them stuck to their gut feeling that the facetted search would do just fine. The same was the case for the search UI positioning in the page. The VP also managed to get the product leadership’s consensus that the data was skewed and was bent towards supporting the viewpoint of the interaction designers.

That was pretty much the end of their UCD gig as long as they were on this project under the VP. He spread the word about how difficult they were to work with, how they were not being aligned with project goals and that they could do with more professionalism. The VP also cancelled his earlier agreed plan to let them perform usability tests in the next iteration when they worked on CQA. With the VP spreading such a negative influence, it was not going to be easy for them to get opportunities to conduct usability tests or user research on other projects in the future either.

Takeaway

Who are the key keepers? Those who give you or your team the opportunity to implement UCD techniques, some form of usability evaluation or user research on a product are the key keepers. Usually higher up the organization chart and very influential, they hold the keys to the kingdom—the kingdom where you can get to keep yourself busy improving the user experience of products by incorporating UCD techniques in not just a few, but all projects. While they hold the power to give you a continual list of opportunities over time, they also hold the power to close the gates and shut you down. In other words, they make or break your group. Make sure you never make them look bad in any way at the expense of trying to achieve perfection. Because ultimately, if they decide to not like your work, it will not look good, however good you may think it is or it actually be. Looking back at the story, there was nothing really the interaction designers had actually done wrong, but they could have made a few concessions for the VP. They could have sent over a one page email plan as the VP had requested, they could have allowed him to attend any usability test session he wanted and let him ask questions in one of them before they requested him to hold them till the end, and they could have provided him with a summary of findings at the end of the day, just the way he wanted. When it came to the report, cushioning in hard findings with a lot of good stuff to say about the project, even if it was superficial, would have harmed nobody. They should also have avoided venting their frustrations about how the findings were in line with what they had pointed out as risks earlier. If they had done this, it would have been much more likely that they would not have been shut down. By capitalizing on the VP’s initial positive outlook, the same exercise would have come to a very fruitful end.

So if there is anyone you should use your soft skills on across your range of stakeholders, the key keepers are the ones you should use it with most, because their voice matters the most in terms of getting approval for the UCD activities you are trying so hard to introduce as a better way of executing projects in your organization.

Example 2—Stakeholder Goals Over User Goals

This story is about a group of interaction designers who were newly hired by a company that had grown huge and done very well making business to business (B2B) portals in the apparel domain. As in the previous story, it was primarily the product team which shaped the information architecture (IA). The interaction designers did not have much of an influence in determining IA although their inputs were taken for micro IA. Their main task was to come up with the user interface. No form of user research or usability evaluation existed and the interaction designers saw the current product development process as a grossly inefficient process. They would often have to go back to square one from a stage where the UI was not only prototyped to high fidelity but was being developed by the programming team as well.

It was thus not surprising how much they wanted to introduce usability testing which they would like to see happening throughout the software development life cycle (SDLC) from beginning to the end. This would help not only them but the entire project teams to deliver products faster and with less time and effort wasted.

A year down the line after a lot of talk, two interaction designers managed to break through with their product head. He wanted to use their help in understanding the major pain points their users faced while using one of their portals for fabric manufacturers and traders. He also wanted to know how best they could go about improving their portal in relation to the pain points that were to be figured out.

The product head gave them a week to do all they wanted as long as they did it on a zero budget. The interaction designers’ plan was to first conduct telephone interviews to understand the most common problems their users faced, after which they would follow it up with a usability test to validate those concerns. But since they had just a week, they decided to only conduct telephone interviews and present their findings to the stakeholders. Taking into assumption that things would go well and the stakeholders would be impressed with what they would uncover, they would then ask for another week to conduct usability tests.

After getting a list of phone numbers out of the customer database, they began their interviews. In four days, they worked extremely hard and managed to successfully complete 100 semi-structured interview sessions. They spent another long, hard day affinity diagramming. Once they completed data analysis, they put in a few extra hours at the cafe below their office. After many a cups of coffee and bagels, they were ready with their report which they would refine over the weekend.

Monday came and they presented their report to the project stakeholders. Besides letting the stakeholders know what was working well and a number of interesting UI concerns they had uncovered, they talked about how much their users complained about the clutter on the homepage and the search engine results page which was mainly due to a lot of banner ads and featured listings. They pointed out that participants were unaware of the free registration option which was hard to locate on the portal. The report also mentioned that participants found faceted search very difficult to understand since the portal used full page refreshes instead of partial page rendering (PPR). In addition, they let their stakeholders know how participants were taken to the portal’s registration page instead of the product details page when participants used a search engine to search for the best prices they could find for the fabrics they were interested in purchasing. By the end of the meeting, everyone was tired and the stakeholders were not impressed. The interaction designers were not in a good mood either. What happened during the meeting was that while there was agreement on a few findings, most of the meeting went on arguing about how most of the findings directly clashed with either business and marketing goals or could not be implemented due to technical limitations. The stakeholders did find some of the findings useful but thought there was too much signal-to-noise ratio. In their opinion, the interaction designers were not aligned with business goals or the technical constraints the project was working within.

In fact, the stakeholders agreed to work on certain features based on their findings that they thought made sense but asked the interaction designers to skip the usability test which the product head had earlier agreed to because they did not want them to validate concerns that could not be addressed, since they clashed with business goals and technical constraints.

The interaction designers’ hard work had gone waste and they did not get any user research opportunities thereafter for almost another year. In addition to other findings, their findings revealing clutter on the website due to ads and paid listings were actually not revealing at all to the stakeholders who had known all about it, but this is where user goals and business goals clashed. Ads and paid listings were a substantial portion of their revenue and the trial user research activity was not going to change their business model.

Takeaway

More often than not, business goals and user goals differ. When trying to introduce UCD into an organization, this is something you should take note of. When you get an opportunity to conduct UCD activities, you are trying to demonstrate value.

Begin by showing that you are aligned to business goals unless you want to start off on the wrong foot. When you focus on findings that are essentially user goals clashing with stakeholder goals, then you are diluting the effort and impact of your activity.

So focus on and present findings that do not clash with business and marketing goals in order to get maximum mileage from your effort. If it is of any consolation, as your stakeholders begin to trust you more and give you more UCD projects, you can then make your case down the line, after establishing credibility with them and all the data collected over multiple research activities, if you foresee an alternate business model for increasing revenue.

Also, respect technical limitations. There is nothing you can do about them. Avoid making recommendations that cannot be incorporated due to technical limitations. Making the recommendation does not magically lift those limitations. An ideal solution is not a solution, a realistic one is. So concentrate on what is achievable and you will do much better.

About the Author

Abhay Rautela is a usability engineer based in New Delhi where he works with a leading internet products company as Senior Human Factors Engineer and looks after usability evaluation and user research across projects. In the past, he has worked in information architecture, interaction design, web accessibility and visual design for various Fortune 500 companies.

Abhay is a member of the executive of the International Federation for Information Processing Special Interest Group 13.1 on Interaction Design & International Development. He is also a member of the ACM SIGCHI and has been a student member of the UPA in the past.

Passionate about Human-Computer Interaction, Abhay writes on usability engineering at Cone Trees[1]. He is also the curator of The UX Bookmark[2] and UX Quotes[3]. As a community evangelist, he heads the New Delhi UX Book Club[4] and the SlideShare Web Accessibility[5] group.

Abhay is also a passionate electronic musician and has recently released tracks on various record labels under the name, Sound Forest[6].

Twitter: conetrees

LinkedIn: http://in.linkedin.com/in/abhayrautela

[1]. http://www.conetrees.com

[2]. http://www.theuxbookmark.com

[3]. http://www.uxquotes.com

[4]. http://uxbookclub.org/doku.php?id=new_delhi

[5]. http://www.slideshare.net/group/web-accessibility

[6]. http://soundforest.net

Broken Soft Drink Machines

London, Heathrow. Like a blood cell being pumped from the heart’s ventricles back into the outer arteries, I had left the exhilarating mass reunion scenes at the arrival hall behind me. At the bus stop, the first vehicle brakes with fizzling sound, I get in. A quick ride later, I was cutting through a dark, early September night alone on my way to find a place to sleep on Brunel University campus. What am I doing here, again? Right, I will be speaking at a conference the next day on playability and biometric player measurement, a topic I have been passionate about during the past years of undertaking Ph.D. studies in Digital Game Development.

Finally, I found the booked accommodation, a student room on campus. Dirt stains glared from the second-hand furniture and the bathroom did not reveal where the shower ended and the toilet began. Nothing says you are still a student like campus accommodation. Trying to find a comfortable position to lie on the squeaky little bed, my thoughts drifted away from this stressful day to the time when I decided to enter the academic rollercoaster.

Scientists vs. Rock Stars

U2’s Bono once said: “As a rock star, I have two instincts: I want to have fun and I want to change the world.” I had the same instincts; only at the time I was a computer science student (or more precisely a computational visualistic student, trying to combine the joys of beautiful code, visualizing information, and pretty graphics). Don’t get me wrong, I know that geeks have come a long way to popular culture since—but those were the days, when Transformers were kid’s toys, the big bang theory was only really appreciated by cosmologists and to become a guitar hero you actually had to learn how to play a real guitar. While I learned to play the guitar in high school, my skills never rose to a Jimi-Hendrix-level, so I figured by going to University, I might actually get a good shot at doing something that I like and also have the possibility to change the world, or at least a tiny part of it. In a nutshell, I had the best intentions with choosing my area of research. However, the topic of digital games was at that time not really considered by my peers as a smart career decision for both a profitable professional or a successful academic future. While games were already establishing themselves as the favorite pastime of many people, the motivational power of fun and positive feelings when playing games had not made its way into the marble hallways, wood-boarded lecture auditoriums and solitary offices of the world’s ivory towers. The success of digital games today is due to their unique ability to provide people with fun experiences and motivate them to train their skills. Something which I would find out about in the following years as well. People rarely succeed unless they have fun in what they are doing.[1]

While much of the focus of regular computer science is on computing and information theory or the real-life application and development of information and communication technologies, studying digital games seemed like an ideal opportunity to become a wanderer between the worlds. Ever since I spent sunny afternoons playing Boulder Dash on my father’s old Commodore C64 computer, the magic of the machine flickering in pale shades of blue before my eyes had fascinated me. So, I first made game technologies the focus of my studies, but my interest soon shifted to focus on players and how they interact with games and entertainment technologies. UX in games is more focused on the pleasurable interaction of the player and the game, while UX in normal software focuses on the software’s utilitarian function to achieve contextual goals. Let us consider the following example: the UX of a plane pilot is certainly shaped by his thoughts about the functionality of the software he is using and his feelings about the contextual impact of incorrect operation of such software. He needs to double check his actions with the co-pilot and monitor the software with high concentration at all times, because pressing the false button at the wrong time will have a much bigger impact on his life and that of the people in the plane than when a player interacts in a game. Here, the impact is powerful, but merely virtual, and because digital games are simulated virtual environments, actions can be undone and behavior can be trained by playing them. This is a huge part of what makes games so entertaining, the user empowerment without short-term real-life consequences. But how do you achieve individual entertainment? Why do humans like to play and have fun while doing it? What impact does playing have on their thoughts and behavior? We need to study game systems and human interaction to get a detailed answer to these questions.

The Joy of Interaction

Like a puff of smoke these thoughts and memories soon fade as I find myself back on the bed in the student dorm room. I should get up as I am starting to feel a bit thirsty and am supposed to meet my colleague Joerg. We used to be childhood friends, but then our paths diverged until recently I got back in touch with him when I visited his university. To my utter surprise we found out that we had developed similar interests and worked within the same area now. We instantly reconnected as we talked about the games we liked, where we saw general benefits of usability in entertainment products and how we could see great potential in studying games to explore essential facets of user experience requirements for non-entertainment products. And in today’s understanding of usability, we can indeed witness a growing importance of hedonic qualities of user-product interaction that are concerned with entertainment values and a new thinking about the beauty of Interaction Design. I must admit that I still get a tingling rush of excitement when I witness true emotion or affection in a human being that comes from the joy of interacting with a machine.

The fun and motivation provided by game-like interactions are pretty strong in motivating people to change their behavior, so that we can leverage gaming principles making everyday objects more fun. A good example for this approach is the current Swedish Volkswagen advertising campaign which is focused on what they call “the fun theory”[2]. In the advertisement videos, simple gaming principles are applied to everyday activities to make them more fun and enforce behavioral change in people. The examples from the ad campaign are (1) turning a bottle bank into a gaming arcade machine (you score points for inserting the correct bottles and flashing lights provide you with very positive feedback), (2) turning a subway staircase into a piano to enforce taking the stairs over the escalator, and (3) emulating a really deep garbage bin through sound feedback to enforce people to not throw garbage on the ground. All of these examples have one thing in common: clear goals (behavior change), clear options, and clear feedback, thus providing an instantly clear relationship between user action and game goal. These are great examples of how regular product and software development can benefit from researching fun in gaming.

Hassenzahl[3] said that a user-product experience can differ between individuals, situations, and over time. He also found that products cause different emotional reactions. For example, when I put money into a vending machine, I expect to receive goods that I want. If this works according to my expectations, then I am likely satisfied with the product. Hassenzahl would say that we have achieved our behavioral goal. As we have seen in the examples before, there are clear design principles from games (e.g., clear goal-action relationship, limited options, feedback) that will make achieving the behavioral goal much easier for us and provide us with real pleasure. Pleasure, for example, may be related to a surprise that happens in user-product interaction. These surprise moments are usually playing with our expectations and provoke a sudden shift in our attention. Games thrive on surprise moments and attention shifts to engage users in interaction. A successful example of this is the gameplay mechanic called quick time events, which has become popular in games like God of War (Sony, 2005) and Resident Evil 4 (Capcom, 2005). These games feature moments, where players are interrupted during a cinematic sequence and prompted to press a combination of buttons or execute a certain move to steer the game’s narrative in a certain direction or simply to avoid losing the game. Creating an interesting attention shift or surprise moment may actually be quite hard to design as balancing attention to progress in a game puts a player under cognitive stress. Finding the right balance of such stressful cognitive processing moments and more relaxing recall of learned interactions with a virtual environment is one of the things that makes games fun.

Csíkszentmihályi[4] was one of the first to note that a balance between personal skill and experienced challenge may lead to a feeling of higher consciousness, which he called flow. This concept was developed during his studies of self-motivated behavior of artists, chess players, musicians and sports players, but it can be applied to digital gaming and interactivity[5] perfectly (good examples can be found in [6],[7]). The activity itself leads to feelings of high enjoyment and self-fulfillment. However, Csíkszentmihályi also noted that boredom will kick in if the challenge is too low and too much challenge will lead to frustration. Little did I know that I was about to find out about the frustration that comes from too much challenge in human-product interaction.

The Quest For a Drink

My cell phone rings and puts me back into reality. It is Joerg and he asks to go check for some soft drinks as he is also quite thirsty from the flight—it is surprising how the new restrictions of preventing you to carry along liquids on airplanes sometimes result into real shortages of drinks, when you have a hectic schedule. I agree to search for a zip of water and we soon find ourselves strolling on the University campus. Not much later, we encounter our first soft drink machine, hoping to get a drink quickly and quench our thirst. Out of order! “Look,” says Joerg and points to two other machines next to this one “they are all empty.” Indeed, all three machines do flash red lights to us. “Bank holiday!” We smirk at each other. Rest assured that it will be hard to find an open shop around midnight. This is a suburb. The quest for a working soft drink machine begins.

For a little while, we stroll around the campus and come to discuss the ideas of self-motivated activities. We both seem to agree on the fact that one of the most powerful aspects of digital games is that they engage you for a longer period of time. Successful games either challenge you to solve a complex puzzle and keep you cognitively engaged by giving you only as much hints as you may need or they present adrenaline-pumping visuals and audio that appeal to you on a visceral level. Thus, whether a game is successful or not is largely dependent on its visual and auditory aesthetics as well as its gameplay dynamics. Prior research suggests that products that have high aesthetic value or attractiveness are also perceived as being more usable than products with a low aesthetic quality[8],[9],[10]. Aesthetic appeal of games might be one important driver of game experience, but incorporating affective gameplay (in which the game world reacts to fuel player emotions) in addition to visual and auditory aesthetics has become an important factor of successful sales, demonstrated by games like the Grand Theft Auto (GTA) series (Rockstar Games) or The Sims franchise (Electronic Arts). A major caveat of this success formula is that currently not much is known in industry or research how to best design for affective gameplay and only recently have we started to use affective measures to evaluate player emotions.

In a way, another driving factor of digital gaming is the quest for information and applying the knowledge that one has to acquire such information to proceed further. Somehow, the situation we were in now was similar to this as both of us had only limited information on where to get a drink at night on a holiday in England, but we were determined to extend our limited information space by exploring the environment. As darkness crawled along on the sides of the campus pathways, we were considering the options given our prior successful quests for drinks. At this time of day, we thought it was possible to find liquid refreshments at either:

1. A soft drink machine. The most common way of getting refreshment after hours. Advantage: You can take the drink with you. Drawback: The machine might be out of order.

2. A pub. Might be specialized in selling alcoholic beverages. Advantage: Might be a way to get a soft drink. Drawback: Might be long walk off campus.

3. A water fountain. Not as common in England as in the United States. Advantage: Instant water goodness. Drawback: Might not be available in this country or campus.

The list shows how limited our information space was, given that we were thirsty and only making assumptions about our unknown environment. Like headless chicken, we were really confused and wanted to find a soft drink machine and go back to the dorms when we encountered security guards at the campus information center. Finally, a place brightly illuminated and hopefully the end of our quest for a drink.

Strolling Around

We quickly reported our problem and the guards told us the location (not far away) of a building with a soft drink machine inside, we decided to go and try that one out. If it was out of stock as well, we should return and find a solution together. The lady speaking to us was really nice and I always enjoy listening to a clean English accent. Should not be more than a five-minute walk for us. Or so we thought.

As we came to a road leading us off campus, after 10 minutes of searching around, we figured that we had probably taken a wrong turn. Having no campus and walking around at night were certainly handicaps we had to face on our quest. So, on our hike back we discussed handicaps in general. In games, a handicap is a concept that is probably taken from Golf sports. When playing golf, a handicap allows a player to deduct a number of strokes from his score to adjust his abilities to those of a less-experienced player. This way, golfers with different abilities can compete with each other, leaving the other rules of the game intact. Such handicaps are also popular in digital games that rely heavily on skill, especially on motor skill. For example, a classic game that stands out in its use of radically teaching a player motor skills for interaction is Street Fighter II: The World Warrior (Capcom, 1992), a fighting game that relies on certain controller pad and button combinations to execute powerful special moves. While more casual fighting games like Super Smash Bros. Brawl (Nintendo, 2008) allow a good amount of special moves to be carried out simply by button smashing, the classic challenge of Street Fighter II was to precisely learn and time the attack movements to overrule the opponent. I remember childhood days, when I had blisters on my thumb, because I practiced the Shōryū-ken (昇龍拳: “Rising Dragon Fist” move of the Ryu and Ken characters in the game) all day. However, one might consider these as simple learning obstacles that can be overcome with training. The regular form of handicaps in games can be found in simply trying to balance out skill by limiting resources. This can be often be found in game difficulty settings, allowing for a smaller or weaker number of opponents.

Of course, the concept of training a skill to gain a gaming advantage has been exploited more recently in the development of “serious games”.[11],[12] Although sounding a bit odd, serious games refer to the concept of training certain skills, making education more fun and also informing about complex processes. An example of such a game is Re-Mission[13], where players are fighting cancer as a nanobot on cellular level, related to infections such as non-Hodgkin’s lymphoma and leukemia. The game was designed to inform children battling cancer in an entertaining way that gives them hope and to have real psychological impact on the success of their treatment.

Of course, in such an environment user experience tests are very important for digital games that have a certain goal (other than general enjoyment or fun). The assessment of fun and other game objectives allow us to leverage powerful game experiences for education, training and strategic communication. However, I believe that all digital games are powerful motivators to engage in a subject and make it easier to process, store and recall information. Norman’s[14] definition of emotion is that it works through neurochemical transmitters, which influence areas of our brain and successively guide our behavior and modify how we perceive information. The ease with which this information is stored is related among other factors to the aesthetical presentation of the information. In this context, emotional and cognitive processing in player’s minds creates game experiences. These experiences result from affective engagement with a game’s presentation or content and the cognitive processing of gameplay to advance in the game. While Norman makes a distinction between affect and cognition, he also constitutes that both are information-processing systems with different functionalities. The emotional connection makes it easier to retrieve information when we need it.

During my dissertation I came to explore various aspects of fun and positive emotion in gameplay and how to measure emotions when playing games[15]. The user experience measurements that I used, usually consisting of a multi-method, qualitative-quantitative approach, were most helpful when the game was designed for a certain purpose. Once you have a hypothesis of what impact a game is supposed to have, you can employ methodology from psychology to validate or cross-reference this impact in an experimental design.

In the context of serious games, affective measurements are especially helpful when exploring information acquisition strategies. Humans strive to maximize their knowledge by accumulating novel but also interpretative information. The processing of novel information activates endorphins in the brain, which guide how we sense pleasure. For example, presenting novel cues in a game will affect player experience and learning. While experiencing novel information and being able to interpret it may be a cause of neurophysiological pleasure, long-term information acquisition is usually done by mastering cognitive or motor skills through repetition. In modern emotion theories, cognition and affect mutually influence each other[16],[17]. Knowledge of affective system mechanics may help us understand and relate to its cognitive impact.

The Soft Drink Machine

As our discussion about the use of handicaps in games had led us to philosophize about the impact of serious games and how to measure user experience with games, time had flown by as we finally encountered the described building. While we managed to prowl around for about half an hour, the building was really only five minutes away from the guards’ place—if you knew how to find it. Through the illuminated hallway we could see a working soft drink machine sparkling through the windows. We fiddled our way into the hallway, the campus doors do have a strange opening mechanism, and finally had the chance to insert a coin into the machine. Ever since the first PONG arcade gaming machines had declared: “avoid missing ball for high score,” inserting a coin into a machine was connected to high expectations on what might happen next.

Crackle! Rattle! Clink! The coin was back, but the drinks remained inside. This cannot be! Joerg tried with a few of his coins. Nothing. We rubbed, polished and grinded our coins using potentially all furniture available in the hallway. Superstition did not help, still no joy. Mad laughter prevailed. Dammit! We went back to the guards’ place and reported our peculiar story. The helpful lady called in the troops and in no time, we were back on our way to the building with the machine. The two lads accompanying us could not believe this. Back in the hallway, four people were now jumping around, fiddling, grinding coins, all trying to get the machine to give us what we wanted. Frustration set in. Too much challenge and no reward.

Nevertheless, we now had help. Similarly modern games provide a help system once they recognize the player is not succeeding as planned. This was made extremely popular by famous game design Shigeru Miyamoto with the “Super Guide” feature created for the game New Super Mario Bros. Wii (Nintendo, 2009): If a player fails a level eight times in a row, a green block appears, which allows a computer-controlled Luigi to show the player a safe path through the level. The player can interrupt this to take control at any time. After Luigi completes it, the player has the option to try the level again, or skip it completely. Thus, it is still possible to advance in the game, even if one part of it is too challenging. In our case, we were glad to have two campus guard super guides. The two lads remembered another building with machines and although on restricted premises, we might be able to sneak in. Like the hobbits in Middle Earth, we all marched further through the darkness on our quest for the one drink—all of us actually being pretty thirsty by now. As we cut through the coppice, we finally reached a building named after some German scientist (whose name we instantly forgot), which featured soft drink machines.

Our two newly-won friends declared that these machines were new and we were likely to be successful here. A final crackling and the machine started to rumble and spit out a soft drink. Quickly we deposited all our coins into the machine and packed some bottles for the night. After thanking the guards for their assistance, we went on our way home and discussed this little adventure and how difficult it can be to achieve what you want. Sometimes life itself is like a great game designer, putting obstacles in your way so that you have to come up with creative solutions. Thus, designing a game can be as creative as playing one and the boundaries between playing and designing tend to blur the more the power is given to the player. Nevertheless, we were certain not to forget our campus quest for a drink, as the experience had settled deep in our brains through the affective experience that accompanied it.

About the Author

Dr. Lennart Nacke received one of Europe’s first Ph.D. degrees in Digital Game Development from Blekinge Institute of Technology, Sweden. He is currently working on affective computing and applying game design methods to create entertaining interfaces as a postdoctoral research fellow in the Human-Computer Interaction Lab of the University of Saskatchewan, Canada. He frequently chairs and organizes workshops and panels with academics and industry experts on topics such as applying game design to user interfaces, affective computing, measurement of fun, joyful interaction design, game usability and UX at venues like CHI, DiGRA, Future Play, and GDC Canada.

As much as an avid gamer, he is a passionate researcher and consultant, whose scientific interests are affective player testing and physiological interaction for example with EEG (i.e., brainwaves) and EMG (i.e., facial muscle contractions) or eye tracking as well as gameplay experience in player-game interaction, technology-driven innovation, and interaction design in digital entertainment technologies.

Web: www.acagamic.com/lennart-nacke

Twitter: acagamic

LinkedIn: www.linkedin.com/in/nacke

[1]. Dale Carnegie (1888 – 1955), American writer and lecturer.

[2]. Rolighetsteorin, see http://www.thefuntheory.com

[3]. Hassenzahl, M. The Thing and I: Understanding the Relationship between User and Product. In Funology: From Usability to Enjoyment. Kluwer Academic Publishers, Norwell, MA, USA, 2004, 31-42.

[4]. Csíkszentmihályi, M. Flow: The Psychology of Optimal Experience. HarperPerennial, New York, 1990.

[5]. Polaine, A. The Flow Principle in Interactivity. In Proceedings of the second Australasian conference on Interactive entertainment (Sydney, Australia). Creativity & Cognition Studios Press, 2005, 151-158.

[6]. Cowley, B., Charles, D., Black, M. and Hickey, R. Toward an Understanding of Flow in Video Games. Computers in Entertainment, 6, 2 (2008), 1-27. DOI= http://doi.acm.org/10.1145/1371216.1371223

[7]. Sweetser, P. and Wyeth, P. Gameflow: A Model for Evaluating Player Enjoyment in Games. Computers in Entertainment (CIE), 3, 3 (2005).

[8]. Kurosu, M. and Kashimura, K. Apparent Usability Vs. Inherent Usability Experimental Analysis on the Determinants of the Apparent Usability. In CHI’95 Conference Proceedings (Short Papers) (Denver, Colorado, USA). ACM, 1995, 292–293.

[9]. Tractinsky, N. Aesthetics and Apparent Usability: Empirically Assessing Cultural and Methodological Issues. In CHI 97 Conference Proceedings (Atlanta, GA, 22–27 March). ACM, 1997, 115–122.

[10]. Tractinsky, N., Katz, A. S. and Ikar, D. What Is Beautiful Is Usable. Interacting with Computers, 13, 2 (2000), 127-145. doi: DOI: 10.1016/S0953-5438(00)00031-X 0953-5438.

[11]. Michael, D. R. and Chen, S. L. Serious Games: Games That Educate, Train, and Inform. Thomson Course Technology, Boston, MA, 2005.

[12]. Zyda, M. From Visual Simulation to Virtual Reality to Games. Computer, 38, 9 (2005), 25-32.

[13]. HopeLab 2006, see http://www.re-mission.net

[14]. Norman, D. A. Emotional Design. Basic Books, New York, NY, 2004.

[15]. Nacke, L. Affective Ludology: Scientific Measurement of User Experience in Interactive Entertainment. Ph.D. Thesis, Blekinge Institute of Technology, Karlskrona, 2009.

[16]. Damasio, A. R. Descartes’ Error. G.P. Putnam, New York, NY, 1994.

[17]. LeDoux, J. The Emotional Brain. Orion Publishing Group, London, UK, 1998.

The Limitations of Good Intentions

Come with me on a journey, as we walk a mile in someone else’s shoes.

Imagine you are a seasoned, professional consultant with over a decade of web experience. You practice information architecture, usability and user-centered design. You are sometimes referred to as a “user experience specialist” by your peers.

You are highly strategic, thinking about the bigger picture while concentrating on the details. You have won awards, and have spoken at a few conferences. You feel pretty confident about what you do, and find your work rewarding.

It is Monday morning, and you are sitting at your desk.

Your desk is located at a high profile marketing agency, located in the heart of the downtown district. This agency produces both digital and traditional work for various clients, and has been in business for over 15 years.

The agency’s offices are spread out over several expansive floors of a refurbished downtown building. Open spaces are the norm, with meeting rooms scattered throughout the far corners of the floor for privacy. Vaulted ceilings and other remnants of the buildings’ history have been preserved, giving an authentic flavour to the inside décor. Outside, the daily ringing of light rail trains at a nearby intersection echo softly throughout the work day.

Early that morning, several members of your project team pay you a visit, paperwork in hand. It is an impromptu meeting in the open for casual group discussion. After a few pleasantries, everyone gets down to business.

The team is currently reviewing and examining your most recent deliverables for a high-profile project, which include use cases, wireframes, sitemaps and interaction models. They ask several questions, attempting to understand your rationale on certain design decisions you’ve made in your work. Particular details are cross-examined and clarified. They want to align your deliverables with the projects’ goals and requirements.

Your immediate boss, an executive director, is sitting fifteen feet away at their desk. She’s listening in on the conversation from a distance, observing the groups’ interactions. She’s aware of the project and the central role you play in it.

What’s happening here would probably be apparent to a casual observer. An early morning discussion amongst interested team members at the workplace. But that’s not the entire story.

Let’s make it interesting and put a few dynamics into the mix.

Imagine that most of them have problems understanding what you do. They are amazed at your ability to turn around work in a short timeframe, and appreciate the quality of the deliverables. Still, there is a fundamental disconnect, and you have not been able to figure it out.

Some of them do not understand what value you provide. They are not sure how you should be utilized. You communicate your work effectively most of the time, but the underlying concepts are largely over their head. Abstractions just do not translate, and the work you do only seems appropriate for certain situations.

You have volunteered to run some small workshops, aimed at showcasing the benefits, advantages and disadvantages of a user-centric strategy towards design projects. You have presented online tools for usability testing and prototyping software to internal business teams. You have e-mailed case studies and best practice examples from authoritative sources and recent UX conferences. There is some clarity with the materials and the purpose they serve, but nothing seems to stick in the long run.

A few of them are fearful or disagreeable, seeing you as a threat to their authority, their job, or both. They periodically ask questions in an attempt to either doubt your knowledge, or your rationale regarding your deliverables.

Your immediate boss is a little nervous. She is starting to see you as a liability, hearing conflicting reports from others on what they have experienced. Despite your best attempts to do your job, be an agent of change and manage your reputation, they have their doubts. It shows when you occasionally ask for their support.

One particular executive, responsible for generating new business leads, does not understand your work or your purpose. He openly questions why a “resource” is going above and beyond their role to try and set direction on projects. You have reached out to him in the past for clarification and resolution, but its an ongoing issue. You are not sure if it is a personality conflict or a political motive. Either way, he seems unconvinced and communicates his doubts to his peers from time to time.

Eventually, the impromptu meeting ends, and everyone heads off to tackle the next thing on their to-do lists, or what their Outlook Calendar reminds them of. You’ve been left with a laundry list of corrections, due at the end of the day.

This cycle repeats itself more or less throughout the week. The challenge inherent with the work keeps you on your toes. But, your work environment makes you a little nervous, and periodically fills you with doubt. You wonder about your job security from time to time.

You are hopeful that things will change for the better, as small victories bring opportunities to improve your situation and showcase your strengths.

But, in time, nothing seems to change.

Your company generally views user experience as an optional commodity. Like accessibility, SEO, and content management, your discipline is considered a “value-add” if clients can afford to pay for it.

Your attempts at impacting your work culture fail to gain traction. Everyone is either too busy to notice, or too self-involved to care beyond their own responsibilities. It is not their fault. It is largely a by-product of the company you work for. Its stability and security are achieved with established processes, ultimately to maintain the status quo.

Your role is reduced to where only a quarter of your abilities are employed, leaving the larger discussions about strategy and user experience to those who directly manage client relationships. Opportunities for direct contact with your clients are minimal. Your strengths with business strategy and user experience are rarely utilized. You seem to produce nothing but supplemental documentation.

Frustrated, you eventually leave, seeking better opportunities elsewhere. You leverage a few colleagues for references, update your resume and brush up your online portfolio.

Epilogue

This story, with some contextual variation, is one I have heard most often from senior user experience practitioners in a number of companies I have had the pleasure of working for over the years.

I wish I could tell a more uplifting and motivational story. I wish that my own body of experience could speak to recognition and promotion, networking with other practitioners, getting ahead and finding inspiration and satisfaction from the craft. The reality is that user experience is, and will remain, a tough sell.

The practice of user experience design is generally one of secondary importance in today’s business world. Outside of companies that “understand” the importance of usability or information architecture deliverables for their projects, UX largely remains a secondary consideration to business-centric roles of accounting, program management and human resources.

In fact, most work cultures have a general unfamiliarity with, or cursory knowledge of, the disciplines of usability and user experience. Sometimes it takes strong leadership, professional consultants or market forces to influence decision makers on their worth. Other times, internal turnover and shrinking market share can become powerful catalysts. Inspiration and direction can also come from new talent, open to different methods and approaches to getting work done.

It certainly does not mean that there are not triumphant stories of companies, teams and individuals currently showing the value of UX.

There are thought leaders, evangelists and highly talented practitioners leading the way every day. It has never been a better time to learn, grow and explore opportunities. My own hope is that UX inspires others to do better work, bridge gaps and ultimately create better design and solutions for everyone concerned.

What we need, ultimately, are better stories to tell.

About the Author

Robert Skrobe resides in Las Colinas, a nice little suburb of Dallas with lots of trees and walking trails. Beyond enjoying the outdoors, he’s consulting clients on user experience strategy, usability and best practices.

Robert is currently the Director of Professional Development for the Usability Professionals Association (UPA).

Web: www.robertskrobe.com

Twitter: robert_skrobe

Facebook: www.facebook.com/robert.skrobe

LinkedIn: www.linkedin.com/pub/robert-skrobe/1/90/862

The Fable of the User-Centred Designer

Preface

Many years ago, I read a book by Kenneth Blanchard and Spencer Johnson called The One Minute Manager. The book is an allegory about good versus bad management. It describes the journey of a young man who wants to learn how to become an effective manager.

Sitting at home one day, I found myself musing on what Blanchard and Johnson would have to say about user-centred design. Like management, user-centred design is ostensibly simple, yet when it comes to great user experiences many people do it incorrectly. And as with management, there are some simple but powerful rules.

This fable is the result of my thinking. I’ve retained the narrative structure of The One Minute Manager and if you know the book there are some other similarities you’ll discover. But above all, it’s a simple description of the secrets of user-centred design. I hope you will enjoy it, apply it and pass it on.

The Search

Once there was a bright young man who was looking for an effective designer. He wasn’t looking for just any designer. He wanted to find a designer who could design complex technology that was easy to use.

He wanted to work with one. He wanted to learn from one. He wanted to become one.

Over the years his search had taken him to the far corners of the world. He had spoken with many designers: with graphic designers and product designers, with software architects and information architects, with interaction designers and visual designers, with business analysts and computer programmers, with men and women—young and old.

He had gone into every kind of design environment: he had visited large companies and small companies, digital design companies and manufacturing companies, web design companies and computer games companies.

He was beginning to see the full spectrum of how people design technology. But he wasn’t always pleased with what he saw. He had seen many designers whose products—software and web sites—were described as attractive. Some of their clients thought they were good designers. Many of the people who tried to use their designs thought otherwise.

As the man interviewed each of these designers, he asked, “What kind of designer would you say you are?” Their answers varied only slightly.

“My designs are visually striking. I design interfaces that people find attractive.” He heard the pride in their voices and their interest in aesthetics.

The man also met designers whose products were described as state-of-the-art. Some of their clients thought they were good designers. Many of the people who tried to use their designs thought otherwise.

As the man sat and listened to these designers answering the same question, he heard: “My designs use the latest technology. I design interfaces that people think are cool.”

He heard the pride in their voices and their interest in state-of-the-art design. But he was disturbed. It was as though most designers in the world were primarily interested either in designing attractive interfaces or in designing cool interfaces. The young man thought each of these designers was only partially effective. “It’s like being part of a designer,” he thought.

He returned home weary and dejected. He might have given up his search long ago but he had one great advantage. He knew exactly what he was looking for.

“Effective designers,” he thought, “create technology that benefits the organisation, its customers and society at large.”

The young man had looked everywhere for an effective designer, but had found only a few. The few he did find would not share their secrets with him. He began to think he would never find out what made an effective designer.

Then he began hearing rumors about a special designer who lived in a nearby town. He heard that clients liked to work with this designer and that the people who used his designs liked them too. The young man wondered if the stories were really true and, if so, whether this designer would be willing to share his secrets with him.

Curious, he emailed the special designer for an appointment. Ten minutes later he had his reply. The special designer was available the next morning.

The User-Centred Designer

The young man travelled to his appointment through a morning fog. It was a cold day in mid-December and he was wrapped up warm against the chill.

When he arrived at the designer’s office, he found him making coffee. The young man coughed and the designer turned and smiled. The designer was a slim man in his early 50s. He invited the young man to sit down and asked, “What can I do for you?”

The young man said nervously, “I’d like to ask you some questions about how you design technology.”

“I’m glad to share my design insights with you,” the designer said. “I will only make one request of you.”

The young man had been expecting this. During his search, he had visited many designers who wanted to keep their ideas secret.

The designer continued, “If I answer your questions, I want you to agree to pass these ideas on to other people.”

“I’ll be delighted to!” exclaimed the young man. This designer certainly seemed a bit of a character.

“In that case,” said the designer, sitting back in his chair, “fire away.”

The young man took out the Moleskine notebook he carried with him and looked at his notes. Tentatively, he asked, “When you design an interface, do you focus on the way it looks?”

“Of course,” said the designer. “Modern technology is complex. People need displays that are free of clutter, otherwise they can’t see what options they have.”

“So you’re a visual designer,” the young man declared.

“Certainly not,” corrected the designer. “Visual design is just one part of the user experience with technology.”

The young man looked at his notebook. “So,” he said, “do your designs use the latest technological innovations?”

“That’s certainly a consideration,” said the designer, “but technology is just part of the solution.”

The young man closed his notebook. “In that case, I’m confused,” he said. “What kind of designer are you?”

“That’s easy,” responded the designer without hesitation. He leaned forward on his chair and whispered, “I’m a User-Centred Designer.”

The young man’s face showed surprise. He had never heard of a User-Centred Designer. “You’re a what?”

The designer laughed. “A User-Centred Designer. I call myself that because I focus on the people who use products and web sites—not on visual design or the latest technology.”

“So what do you do?” asked the young man curiously.

“If you really want to find out, you shouldn’t ask me,” observed the designer. “You should ask my clients.”

The User-Centred Designer picked up a piece of paper from his desk. He wrote down some names and telephone numbers from his address book. “Here is a list of three people I have worked with over the last year. They have all said they are happy to talk about the work I have done for them and they are all available to meet with you today. Why not give each one a call?”

The young man left the building and walked out into the winter chill. A weak sun was beginning to burn off the fog. As he pulled his coat closer, he felt slightly bewildered and a little uncomfortable. He had expected to leave the User-Centred Designer’s office with a manual, or a textbook, or something else to read. He didn’t expect to have to talk with customers.

The young man looked at the first name on his list: Jane Sampson. He gave her a call.

The First Secret of the User-Centred Designer

The young man arrived at Jane Sampson’s office later that morning. The receptionist asked him to sign the visitor’s book while she made a telephone call. The young man took off his coat and hung it on a hallstand in the reception area. “You have a visitor to see you,” he heard the receptionist say.

A slender woman with auburn hair soon arrived at reception. She held out her hand in greeting. “I’m Jane,” she said warmly, as she shook the young man’s hand. “So you’ve been to see the special designer. He’s quite a character, isn’t he?”

“I think he is,” acknowledged the young man, smiling.

“Did he tell you about being a User-Centred Designer?” asked Jane.

“Yes,” said the young man. “But he didn’t tell me much more. He suggested I see you and two of his other clients.”

Jane opened the door to a meeting room and invited the young man to take a seat. “Well, that’s certainly the way he thinks,” said Jane. “When he worked on our software redesign it got me puzzled at first.”

The young man asked, “Is that because he didn’t talk about visual design or the latest technology?”

“Precisely,” said Jane. “He talked about our customers.”

“How did that help?”

“Well,” answered Jane, “We design software to help businesses manage their finances. With the User-Centred Designer’s help, we soon realised that we didn’t really know how people used our system.”

As Jane spoke, the young man took out his Moleskine and uncapped his pen. Jane continued, “Some people on our design team thought that one or two people in a company would use our software frequently, so they wanted a design that supported expert use. Other people thought that our product would be used by several people less frequently, so they wanted a design to support novices.”

“Why was that a problem?” asked the young man.

“Because the software was trying to do both things at once, and failing badly. It wasn’t suiting anyone’s needs.”

“What did the User-Centred Designer do to help?” inquired the young man.

“His first step was to identify the users of our system and what they wanted to do with it,” replied Jane. “He watched people in offices to see how they managed a company’s finances and interviewed some of them. He sat in on calls to our support desk and listened to customers’ problems.”

“What did he discover?”

“He helped us realise that we have very different groups of users with very different needs. We had been designing our software for an ‘average’ user that didn’t exist.”

“So now you know who you are designing for and what people want to do with it?” concluded the young man.

“Exactly,” said Jane. “We created user profiles—pen portraits of each type of customer—and made sure the design team understood who they are designing for.”

The young man nodded thoughtfully. “It sounds like you develop personas,” he said. “I’ve come across those before.”

“So had we,” returned Jane. “But the User-Centred Designer’s approach was different. He made us base our personas on research findings—not on the assumptions we had about customers. Nowadays, we have a saying around here: ‘Supposing is good, but finding out is better’.”

The young man liked the saying. He wrote it in his notebook. “What did the User-Centred Designer do next?” asked the young man.

“He helped us set up a program of regular site visits to our customers. This helps us achieve three important goals.”

The young man leaned forward. “What goals are these?” he asked with rising interest.

“First,” said Jane, “we begin to understand what motivates our customers, so we can create personas. Secondly, we understand the environment in which people use our products, such as the company culture. And thirdly, we develop red routes.”

The young man looked quizzically at Jane. “Red routes?” he asked. “What are red routes?”

“You must have seen roads with yellow lines painted on them?” asked Jane.

“Of course,” said the young man. “It means you can’t park on those roads.”

“Well, in some cities they put red lines on certain routes,” continued Jane. “By keeping these roads free of obstacles like parked cars, journeys on these routes are completed smoothly and quickly. Motorists aren’t allowed to stop on a red route, even for a minute. Make the mistake of stopping your car on a red route to buy your daily paper and traffic wardens converge on you from nowhere!”

“How do red routes apply to your software?” asked the young man, who was still a bit confused.

“Software has red routes too,” explained Jane. “These are the critical tasks that people want to carry out—tasks that need to be completed as smoothly and quickly as possible.”

The young man thought for a second and said, “So red routes are critical user journeys with a product?”

“That’s correct. For example, creating an invoice for a customer is an example of a red route with our software,” said Jane.

“But there must be dozens of things you can do with your software. Are they all red routes?”

“No,” corrected Jane, “Some tasks are much more important than others. That’s where the red route idea helps us. By focusing on the red routes, we can make sure that less important functions don’t clutter the interface. Those functions are still there, but to use them people may need to go to a dialog box or another part of the interface.”

The young man paused for a moment and then said, “I can see how focusing on red routes makes some tasks easier. But won’t this make other tasks harder to complete, because you’ve relegated some functions to dialogue boxes?”

“Yes it will,” said Jane. “But good design is about making decisions and trade-offs. It’s impossible to make every task easy. You need to prioritise what’s important. That’s why we need to do research with our customers: to make sure we’re focusing on the right goals.”

The young man looked at his notes. He said, “So your site visits to customers help you understand who you are designing for, what people want to do with the software and the environment in which the software will be used.”

“You’re a quick learner,” said Jane. “That’s the first of three secrets of user-centred design. Here, take a look at this poster.” Jane gestured to the wall behind the young man. He had not noticed this poster until now. The poster showed a mosaic of people’s faces: there were hundreds of faces in the poster. In bold lettering at the bottom of the poster he read:

The First Secret of User-Centred Design: Early and Continual Focus on Users and their Tasks.

“Thank you,” said the young man. “Let me jot that down, I want to remember that.” Jane watched the young man write in his notebook. She saw him pause, and frown. He leaned forward and asked, “Doesn’t this take a lot of time?”

“Of course it takes time,” said Jane.

“So that must mean your projects take a lot longer these days.”

“Certainly not,” said Jane.

“I don’t understand,” said the young man with a puzzled expression.

“We develop our software using a process called Agile,” explained Jane. “This helps us quickly develop new and improved versions of our software. But this process only works if we know what we need to improve upon. By focusing on users and their tasks, everyone on the team knows where to concentrate their efforts.”

“So it actually saves you time!” exclaimed the young man.

“It does,” agreed Jane.

The young man had another question. “If ‘early and continual focus on users and their tasks’ is the first secret, what are the other two?” Jane smiled and looked at her watch. “I think it’s time for you to visit the next person on your list,” she said.

The Second Secret of the User-Centred Designer

After leaving Jane Sampson’s office, the young man stopped at a café for lunch. Although the sun was getting brighter, there was a persistent patchy fog and it was still cold; so he was pleased to get a seat near a radiator. Over a coffee, he reflected on what he had heard. “It certainly makes sense,” he thought to himself. “After all, how can you be an effective designer if you don’t know who you’re designing for or what people want to do with the product you’re creating?”

The young man wondered about the two other secrets he still had to learn. He was excited, and he soon left the café for his next engagement with Peter Levy.

He arrived at his appointment a little early. After a short wait, he was met in the reception by a cheerful, thickset man with dark hair and a short beard. “I’m Peter,” said the man. “So you’ve seen the special designer. He’s quite a character, isn’t he?”

He was already getting used to the User-Centred Designer being called ‘quite a character.’

“I reckon he is,” responded the young man.

“And he’s sent you out to speak to people like me to find out about user-centred design,” said Peter, smiling. “That sounds just like him—a very user-centred approach.” He showed the young man into a meeting room.

“Yes, I already know about focusing on users and their tasks,” agreed the young man, removing his coat. “What do you do next?”

“You need to make sure that your designs work the way people expect.”

“That must be easy,” said the young man enthusiastically. “Don’t you just ask people what they think?” Peter didn’t answer the question but took a mobile phone from his pocket. He handed it to the young man. “What do you think of this handset?” he asked.

The young man turned it over in his hands. “Well, it looks OK to me,” he said. “Did the User-Centred Designer help you design this? It’s nice and small, and I like the rounded edges.”

“Now try typing in your telephone number,” said Peter. The young man began to type and quickly made a mistake. “The buttons are a bit close together,” he said. “I keep pressing two buttons at once.”

“That’s the point,” said Peter. “You need to be wary of people’s initial opinions. If you want to find out what the problems are with your product, you need to get people to use it. We’ve had thousands of these handsets returned by customers as ‘fault not found’.”

“What does ‘fault not found’ mean?” asked the young man.

Peter sighed. “It’s when the customer reports the handset as broken but in fact there’s nothing wrong. It’s really because the customer has problems using it. And it’s not just the buttons on this thing—it’s the software too.”

The young man placed the mobile phone on the table. “That handset must have cost you a lot of money.”

“It did,” said Peter. That’s why we called in the User-Centred Designer to help fix it.” The young man took out his Moleskine notebook and said, “So what did he do?”

“He set up a usability test. He asked our customers to use the phone and we watched them as they worked. We noticed where they got stuck and experienced problems,” said Peter.

“And did your customers tell you what to change?” asked the young man.

“With products like ours, people don’t always know what’s achievable, so they don’t know what to ask for. There’s a saying from Henry Ford that I like to quote: ‘If I had asked my customers what they wanted, they would have asked for a faster horse’.”

The young man smiled and wrote the quotation in his notebook. “So how do you get feedback on the good and bad parts of your design?” he asked.

“We ask people to carry out specific tasks with our designs. Have you heard of red routes?” inquired Peter.

“Yes, I’ve heard of red routes. They are the critical tasks that people want to complete with a product.”

“That’s right,” said Peter. “We hand people our product and ask them to carry out those tasks. People think aloud as they work so we know what parts of the interface are confusing them.”

“So you get a running commentary on the usability of your product.”

“Yes,” replied Peter. “But that’s not all. In our tests, we also measure the usability of the product.”

The young man stopped taking notes for a second and looked up at Peter. “You measure usability?” he asked, surprised. “How do you do that?”

“In three ways,” explained Peter. “First, we measure effectiveness: how many people manage to complete the red route successfully?”

The young man thought and then said, “Because if the design is easy to use, more people can achieve their goals.”

“Exactly,” agreed Peter. “Then, we measure efficiency: how long people take to complete the tasks.”

“Because if the design is easy to use, people will be able to achieve their goals quickly,” pointed out the young man.

“Correct. And finally, we measure satisfaction: how people feel about the design.”

“Because there’s no point having a design that people can use effectively and efficiently if they don’t like it,” said the young man.

“You’re a quick learner,” said Peter. “Now you know the second secret of the User-Centred Designer.” As he spoke, he pointed to a poster on the wall. The poster showed a woman looking at a computer screen. She was watching a video of a usability test and taking notes. In bold lettering at the bottom of the poster, the young man read:

The Second Secret of User-Centred Design: Empirical Measurement of User Behaviour.

“Let me write that down,” said the young man. After he finished taking notes, the young man paused. Something was clearly bothering him.

“What is it?” asked Peter.

“After you have run your tests, you obviously find problems with your product?” asked the young man.

“Always,” said Peter.

“And after you fix the problems, you need to test the system again?” asked the young man.

“That’s right,” said Peter.

“But doesn’t that take a lot of time?”

“I think you’re ready to find out about the third secret of the User-Centred Designer,” said Peter.

The Third Secret of the User-Centred Designer

Back in the street, the young man noticed that the fog had lifted. He turned up the collar of his coat against the wind and thought about what he had just learned. “Usability testing certainly makes sense,” he thought to himself. “After all, how can you be an effective designer if you don’t watch how people use your design?”

His third appointment was with Sofie Brown at a web design company. A very smartly dressed woman in her 30s met him in the reception. “I’m Sofie,” she said with a smile. “So the special designer sent you over. He’s—”

“—quite a character!” interrupted the young man, and they both chuckled.

Sofie took the young man into a meeting room and gestured to him to sit down. The young man said, “I’ve just been hearing about usability testing. It seems to make a lot of sense but I’m worried that it will be too time consuming.”

“Why do you think that?” asked Sofie, sitting back in her chair.

“Because when you fix one problem, you need to re-test the system,” replied the young man.

“You’re absolutely right,” agreed Sofie. “That’s why we put off writing code for our web site for as long as possible.”

“But how can you test a web site if you don’t code it?” asked the young man.

“The User-Centred Designer introduced us to a technique that allows us to test our new designs very quickly. It’s called paper prototyping.”

“How do you test paper prototypes?” asked the young man.

“We show users a paper interface and then ask them to complete tasks with it. Users press buttons”—Sofie made a quotation mark gesture around the word ‘buttons’ with her index fingers—“and choose options as if it’s a real system.”

“So you run usability tests on paper prototypes!” exclaimed the young man.

“Exactly,” agreed Sofie. “We test again and again. The User-Centred Designer taught me that the secret of good design is to sketch out lots of different designs and test them. Then you take the best from each one and create a new set of designs.”

“A bit like evolution by natural selection,” said the young man.

“You’re a quick learner,” said Sofie. “In fact, you might be interested in a saying we have around here. ‘You can’t get the design right until you’ve got the right design’. This reminds me that the first step in design is to generate lots of different ideas. You then pick the best elements of each design by running usability tests. This is what is meant by ‘getting the right design.’ The next step is to refine the design: to ‘get the design right.’”

“That sounds fantastic!” remarked the young man as he wrote in his notebook. “Do you create all of your prototypes with paper?”

Sofie said, “Paper prototyping helps us ensure we get the correct information architecture—so that people can navigate the site and understand the terminology. Then we move to electronic prototypes, which look a lot more realistic but are still simulations. This helps us get the correct visual design of web pages.”

“And you use electronic prototypes to ‘get the design right,’” said the young man.

“That’s right,” said Sofie. “You’ve just discovered the third secret of the User-Centred Designer.”

The young man smiled and searched the walls for a poster. “I don’t suppose you have this written down anywhere, do you?” he asked.

“As it happens,” said Sofie, “I do.” She stood up and invited the young man to follow her. In the corridor outside the room was a poster on the wall. It showed a number of arrows arranged in a circle. At the top of the poster were the following words:

The Third Secret of User-Centred Design: Iterative Design.

“Let me write that down,” said the young man, turning the page of his Moleskine. As the young man glanced over the notes he had made, a thought occurred to him. “Can I ask you a question?” he asked.

“Fire away,” said Sofie.

“As I look over these three secrets of user-centred design, they seem very sensible.”

“I agree with that,” said Sofie.

“So why do so few companies design this way?” asked the young man.

Sofie smiled. “I’ll let you ask the User-Centred Designer that question,” she said.

The User-Centred Designer Explains

As the young man left Sofie Brown’s office, the low afternoon sun was disappearing behind the office buildings. The sun cast long shadows and the sky promised a fine sunset.

The young man walked back towards the User Centred Designer’s office. “Iterative design certainly seems a very simple and powerful method,” he thought to himself. “After all, how can you be an effective designer if you just come up with one or two designs?”

He was looking forward to meeting the User-Centred Designer again. The three secrets seemed so obvious to him that he wondered why so few companies followed this approach. He hoped that the User-Centred Designer might be able to tell him.

When the young man arrived at the designer’s office, he found him in conversation with a colleague.

The designer saw the young man and finished his conversation. He walked over and shook the young man’s hand. “What did you find out on your travels?” asked the designer.

“A lot!” said the young man enthusiastically, shaking off his coat.

“Tell me what you learned,” said the designer, as they walked to a meeting room.

“I found out that the first secret to being a user-centred designer is to have an early and continual focus on users and their tasks,” said the young man. “You need to visit your users, observe them as they work and interview them. You then use the data you have collected to create personas and red routes and you share these with the design team.”

“So what do you think about all that?” asked the designer.

“I’m amazed at how simple it is,” said the young man. “And I’m surprised that many companies don’t do it.”

“Most companies think they are customer-centred,” explained the designer, “but when you ask their customers, very few of them agree. The first secret of user-centred design has four ingredients. You need to focus on users. You need to understand the users’ tasks. You need to do this early. And you need to do the research continuously. Few companies invest the effort in each of these components.”

“You mean they just make it up?” asked the young man.

“I’m not sure they think of it that way,” said the designer. “They probably think they know their users because someone on the design team used to work with customers in the past. That’s a start, but it isn’t research. The data will be biased by the perceptions of one or two people.”

The young man said, “So companies don’t do the research because people in the organisation simply assume that they know what’s best for customers?”

“That’s been my experience,” agreed the designer. “And when they do research, it’s often not the kind of research that’s needed to create better designs. The research often focuses on uncovering demographic factors rather than truly understanding people’s goals and motivations.”

“And so companies don’t get to understand users and their tasks,” said the young man.

“That’s correct. And even when a company does carry out research, they often don’t do it early enough or they do it only at the beginning or end of a project.”

“You mean they don’t do it continuously,” said the young man.

“Precisely,” said the designer, with a nod of his head. “So what else did you learn?”

The young man turned a page of his notebook. “I learnt that the second secret to being a user-centred designer is empirical measurement of user behaviour. Why don’t more companies do this?”

“Most companies do carry out some kind of research on their products, and they will often ask customers for their opinion in focus groups,” said the designer. “But that’s not enough. With interactive products like software, web sites and handheld gadgets, it’s not what people say that matters. It’s what they do. So activities like focus groups won’t help you find the problems with your product.”

“That’s why you need to carry out usability tests,” said the young man.

“And it’s also why you need to measure usability,” added the designer. “By taking measurements of your product’s usability, you know if you are improving or falling behind compared with earlier designs or compared with the competition. You can set key performance indicators for usability and see how the design stacks up.”

“So the problem is that few companies run usability tests and even fewer collect usability metrics,” said the young man.

“That’s right,” said the designer. “What else did you discover?”

The young man flipped through his notebook. “I learnt that the third secret to being a user-centred designer is to design iteratively. That means creating lots of paper and electronic prototypes, testing them out and then changing the design based on feedback.”

“So there’s a distinct design phase before any code is written,” added the designer. “How does that sound to you?”

“It sounds sensible, but don’t most design teams already create two or three versions of an interface?”

“It’s true that design teams will come up with multiple designs for a system. But then the decision on which one to develop tends to be swayed by the HIPPO.”

“The hippo?” asked the young man.

The designer smiled. “The Highest Paid Person’s Opinion,” said the designer.

The young man burst out laughing. “So the designs aren’t tested with users?”

“Not often,” said the designer.

“But if every iteration is tested with users, companies won’t meet their deadlines,” said the young man.

“You don’t need to get user feedback on every iteration. It’s about risk management: you involve users whenever important design decisions are going to be made. There are other techniques you can use alongside usability testing, such as an expert review. But these will never entirely take the place of usability testing.”

“What’s the difference between an expert review and a usability test?” asked the young man.

The designer explained, “With an expert review, a usability expert examines the design and compares it against a set of recognised design principles. The reviewer doesn’t ask users to evaluate the system but instead tries to get into the mind of the user.”

“What I hear you saying is that it’s a valuable technique but it’s never a replacement for user testing,” said the young man.

The designer looked at the young man and said, “I’m impressed with you, young man. You’re a quick learner.” The designer paused, and then said: “How would you like to work here?”

The young man put down his notebook and caught his breath. This was, of course, what he had been hoping for all along.

“I’d love to work here,” he gasped. And so he did—for some time. The time the special designer had invested in him paid off. Because eventually, the inevitable happened. He too became a User-Centred Designer.

When he started a new design project, he made sure that the design team had an early and continual focus on users and their tasks. He made sure that the design team carried out empirical measurements of user behaviour. And he made sure that the design team designed iteratively.

He remembered his promise to the User-Centred Designer to share his knowledge. He created a diagram to make it easier for people around him to become user-centred designers and he gave it as a gift to everyone he worked with.

The New User-Centred Designer

Some years later, the man looked back on the time when he first heard of the principles of user-centred design. It seemed like a long time ago. He was glad he had written down what he learned from the User-Centred Designer. He had put his notes into a book, and had given copies to many people.

Suddenly, his telephone rang. “Excuse me for calling you”, he heard a woman’s voice say timidly, “but I would like to learn how to become a better designer.”

And soon he found himself talking to a bright young person. “I’m glad to share my design approach with you”, the new User-Centred Designer said, as he showed the visitor to a seat. “I will only make one request of you.”

“What’s that?” the visitor asked.

“Simply,” the designer began, “that you share it with others..”

Adapted from Travis, D.S. (2002). e-Commerce Usability: Tools and Techniques to Perfect the On-line Experience. London: Taylor & Francis.

About the Author

David Travis is the Managing Director of Userfocus (www.userfocus.co.uk), an independent consultancy specialising in usability training and usability consultancy. David holds a BSc (Hons) degree and a PhD in Psychology. David’s professional affiliations include membership of the British Psychological Society, the Experimental Psychology Society and the Usability Professionals Association. He is a Chartered Psychologist and has worked in the areas of psychology and user interface design for over 20 years. He has published over 30 scientific papers, including three books, and led seminars and tutorials at international symposia. His most recent book, E-commerce Usability, was published in 2003.

David specialises in the design and evaluation of hardware and software systems aimed at non-technical users and he has logged over four hundred hours in usability labs. You can connect with David on Twitter by following @userfocus.

Anything Can Be Interactive Media If You Know What You Are Doing

“Today, I realized that the closest thing I have to love is a relationship with my Blackberry. But don’t worry. It vibrates. FML”—by anonymous on FMylife[1].

At Christmas two years ago, I went to visit my family in Bangkok, Thailand. While I had the chance to do a lot of catching up with my mom, I found myself having a hard time explaining to her what I do for a living. “I’m an interactive designer, Mom.” I said. “So what is that exactly?” Mom still wondered. “Well, you know. We design innovations and things that help to improve people’s lives in the future,” I tried to explain, but at the same time, I realized I was just making things worse. “Like computer stuff?” Mom tried to clarify. “Well, sometimes,” I replied, without realizing that from now on, I would be answering my neighbors’ computer virus problems, as soon as my mother had relayed to the community that I work on “computer stuff” in the US.

Later, I recognized why it’s so hard to explain to people what Interactive Designers do. It’s because we not only make “things”, we actually design “experiences” alongside our innovations. It doesn’t matter which media are used. If you know what you are doing, you can use anything to create an interactive experience. It’s abstract, yet very powerful.

Think about Amazon.com, for example. The core challenges that Amazon’s designers aimed to tackle were not only what the web pages should look like, but also how to convey what a shopping experience at Amazon.com feels like. Solving this challenge included: designing the search mechanism, guessing the search keywords that people type, product categories, recommendations, promotions, listings, inventories, commenting on the product, how to help buyers make a decision without seeing the product, how they are going to pay, how to ship the products, and how a customer returns a product.

Amazon.com’s experience also extends beyond the site. It actually reaches out to your doorstep through the UPS guy who delivers the product to you. Amazon’s marketplace even lets you play the role of the seller, letting you reach out to other people to sell your stuff. Amazon.com is not just a website, it’s an experience.

Two

Being a designer is about picking, mixing, and using design ingredients to construct design works. This is no different for Interactive Designers or Experience Designers. At a higher level, elements of interactive experiences can boil down to three things that go hand in hand: story, media, and context.

Story is what you try to communicate. It’s essentially what experience design is all about: communication. The message can be anything from branding, a narrative story, information, an educational message or simply the proposition to “buy me.” Steven Spielberg once talked about how important it is to know clearly what you are trying to say: “Getting what you want is easy, but knowing what you want is hard.” Designers have to understand clearly what they are trying to convey, because that is the goal of the design. Once you get your core message clear, it’s time to pick the right media to deliver it.

Today’s media concept expands beyond 20th century massmedia. Anything, a piece of paper, a web page, color, imagery, video, sound, typography, or even an empty space can be a medium, as long as it’s the right vehicle to carry your message to your audience. Y+ Yoga Center in Shanghai uses simple bendable plastic drinking straws as their interactive advertising tool. They cleverly printed a picture of a yoga instructor on the part of the straw that you bend to face your mouth.

Image credits: Client: Y+ Yoga Center, Advertising Agency: Leo Burnett, Shanghai, China

The yoga instructor’s waist is printed exactly on the flexible joint between the mouthpiece end and the rest of the straw, thus every time the user bends a Yoga Center straw to drink, the yoga instructor changes her position between the Back Bend and Downward Facing Dog positions. This advertising campaign takes advantage of a flexible object to animate a still image and turnss a mere straw into an interactive medium. Each medium has its own characteristics and parameters. Look into them carefully and make sure every element of the medium serves your storytelling. Keep in mind that to tell a single story, you can use more than a single medium.

Lastly, one must consider the context of the story. Design in the 21st century has reached a point at which we realize that an object has more than one function, and on top of that, more than one meaning, depending on the context. Take, for example, the iPhone. If you use it for voice calls, the iPhone is just a phone. However, when you launch other apps on the device, its function and meaning change. An iPhone can be a GPS navigation tool, a music player, a social device, a camera, an organizer, etc. Designers today need to understand this dynamic context and utilize it wisely.

The following is a collection of various interactive experience design case studies that demonstrate good utilization of story + media + context.

Three

BBC World’s Now In America campaign was an interactive billboard installed in New York City in 2007, by BBDO, New York. The goal of the campaign was to try to break into the US news market. The story is the BBC branding itself as an honest source for world news that offers unbiased reporting. This interactive billboard series, in the heart of New York City, addressed political or social issues as a theme. Each theme was visualized by a journalistic photograph that represented a controversial news topic. For example, one of the themes in the series used an image of Chinese flags and the Chinese army marching in the streets of Beijing. The left and the right side of the image displayed two opposing opinions about the issue. For instance, the same billboard showed “Befriend” on the left and “Beware” on the right. Viewers could interact with the billboard by texting either “01” to vote “Befriend” or “02” to vote “Beware” to a dedicated phone number. The billboard had two LED screens to display vote results in real time. The concept of the series included many themes such as bird flu and war in the Middle East. This billboard series merged different media, cell phone and billboard, within the context of social issues, in order to interactively communicate BBC’s brand essence as a fast, honest, neutral, world news source.

Image credits: Client: BBC World, USA; Advertising Agency: BBDO New York, USA; Chief Creative Officers: David Lubars, Bill Bruce; Executive Creative Director: Eric Silver; Creative Directors: Jerome Marucci, Ari Weiss; Copywriters: Adam Kanzer, Ari Weiss; Art Directors: Jamie Overkamp, Jerome Marucci

Believe it or not, a homeless man can become an interactive medium if you know how to design your campaign well. Fifty Fifty magazine launched a special issue about homeless people. The campaign by Euro RSCG Duesseldorf, Germany, ingeniously brought together a homeless man, a video camera, and an LCD projector, creating a live ‘invisible man’ to convey the message “Don’t act like homeless people are invisible.” How did they do this? They used the video camera to capture images behind the homeless man and projected them back onto him. This created the illusion that the man had disappeared, as bystanders could see “through” him.

Image credits: Client: Fifty Fifty Magazine; Advertising Agency: Euro RSCG Duesseldorf, Germany; Creative Directors: Florian Meimberg, Torsten Pollmann, Felix Glauner; Art Director: Jean-Pierre Gregor; Copywriter: Till Koester; Production Company: CONGAZ Visual Media Company

Shiner Bock, Texas-born beer, used guerrilla marketing tactics by McGarrah Jessee, Austin, USA, and beer can sleeves to grab the main sponsor impression from Heineken at the Austin City Limits music festival. While Heineken was the main sponsor of this major music event, allowing only Heineken beer to be sold during the event, Shiner Bock gave away free beer can holders. It turned out that everyone who drank beer during the show was apparently holding Shiner Bock. This campaign successfully utilized the brand character in the right context. Austin is known for its rebellious and bold character and Shiner shares the same image. This cutting-edge campaign articulated Shiner’s brand character and allowed people to show “How we Austinites roll.”

Image credits: Client: Shiner Bock; Advertising Agency: McGarrah Jessee, Austin, USA; Creative Directors: James Mikus, Cameron Day; Art Director: Beau Hanson; Writer: Tannen Campbell

Complete experience design helps enhance fictional worlds, as well. Lost, a famous TV show about a group of airplane passengers who get stranded on a mysterious island after a plane crash, also extended the experience beyond the show’s TV time. The show’s official website provides a lot of side stories, back-stories, recaps and sneak peeks for fans who can’t get enough of the Lost experience on TV. Lost has its own magazine which provides clues and theories about the show’s endless mysteries. The most far-reaching experience Lost has to offer seems to be Oceanic Airline, a fictional airline’s official website where users can read news about the airline crash, advertisements, promotions or even try to book a flight. This extended experience is a design piece that blurs the boundary between fiction and reality.

In 2009, many TV shows pushed reality further by using real-world references in the shows. For example, Dexter, The Office, and Heroes all included the Thanksgiving holiday as the background for the episodes shown during Thanksgiving week. The famous comedy, The Office, even created a parody of one of the most popular videos on YouTube, “JK Wedding Entrance Dance”, as part of an episode’s climax. Michael Scott, the leading character, also mentions the video directly, “Have you seen this? It’s on YouTube.” With the new experience design, not only are the boundaries between media fading, but fiction and non-fiction worlds are also moving closer together.

Four

It might be easier to demonstrate how to create an interactive communication campaign by picking a potential project and analyzing how to push the design further. Here is an example: Cleo magazine, an Australian based magazine in Asia targeted at women, promoted its annual Bachelor of the Year party by tying Ken dolls to balloons and releasing them into the sky over Sydney. Once the helium gas in the balloons had escaped, the Ken dolls fell from the sky. The message written on the balloon was: “It’s raining men. Vote for your Bachelor of the Year at Cleo magazine.” The campaign was received very well by readers and the media alike. That’s as far as the real story goes.

However, I believe that this campaign had a lot of potential and that experience design would push the campaign up a notch. Let’s try to enhance this campaign in a thought experiment. Imagine that each Ken doll, in addition to the original message, has one of fifty unique phone numbers, corresponding to fifty Bachelor of the Year contestants. A woman who finds a doll can call the number and listen to a recording of the bachelor’s voice asking her to vote for him: “Hi, I’m Umy, bachelor number 13. I am a very good-looking designer. Please vote for me at www.cleomagazine.com so we can have a chance to date.”

After that, the user or the reader can go to the website to look at the contestants’ profiles and decide to vote for the men they like. Users also can upload their pictures and profiles to enter a competition to win a date with the contestants they feel for. Once the winners get to go out on a date with the contestants, we can feature their dating experience in the magazine. They will also be asked to blog about the dating experience with the bachelors they voted for.

As a result, everyone who engages in this experience design campaign is likely to get deeply involved with the campaign. They would also collect the magazines, show the articles to their friends, and recommend the blogs to their pals. The campaign would reach out to more and more people, as followers get their friends involved.

Five

There is no obvious formula for designing a good interactive experience, but there are some basic principles for designers to keep in mind.

First of all, experience design is about people. Not only do you want to engage a target audience, but also the people around them, the media that might help you project your message, and your competitors who are observing your actions.

Secondly, experience grows and develops. Design experience is not designing for a single state, it’s about the lifecycle of design. Good design is a process not a product. It can never be finished. Apple Computer distilled the company name and logo down to “Apple”, reflecting its growth as a brand that embraces a variety of products, rather than just that of a computer manufacturer. Apple products such as the iPod and iPhone were to emerge and change the face of the music and mobile phone industries forever.

Thirdly, prepare for feedback and be flexible enough to adjust to it. Keep in mind that whatever you put out there, other people will respond to. Audi once put up a billboard ad for their new, flashy sports car with copy that read, “Your move, BMW.” A week later, in response to the Audi billboard, BMW bought a billboard across the street to advertise their beautiful—if not better than Audi—sports car, with a single word: “Checkmate.” In this case, BMW was clever enough to turn an aggressive move by its competitor into an advantage by making a smart retort.

Fourthly, don’t forget to follow through. Keep your experience design focused and plan to enhance the experience over time. The whole Lost experience, mentioned earlier, was not planned in one day. After the show’s ratings picked up, the design team started to put in ideas and kicked off Lost’s convergence experience.

Fifthly, always have a plan B, C, and D. Think about alternatives if your first attempt simply doesn’t work as intended. Also consider what you will do if it’s more successful than you ever dreamed of. How will you sustain it?

And lastly, our lives today are spent both online and offline, and the boundary between them has almost disappeared. The other day, I had this conversation with a colleague whom I hadn’t met in person in weeks. If someone had overheard us, they wouldn’t have understood us.

N.:“Hey, Umy. I decided to go with your suggestion.”

Umy: “Cool. I’m glad you did that since you decided to get rid of all the physicals.”

N.: “Yeah, and thanks for the link as well. It came in very handy.”

Umy: “Sure. I knew you would like it.”

The conversation doesn’t make any sense at all to a third person of course, because it continued from the previous conversation I had had with him on Facebook. This is the first half of the conversation.

N’s Facebook status: “Re-ripping all the CDs into mp3 (256kbps)”

Umy’s comment: “Been there. I did mine in Lossless.”

N’s comment: “I wanted to do it too, but I use iTunes, which doesn’t play Lossless.”

Umy’s comment: “Yes, it does. You just need to rip your CDs in Apple Lossless instead of Flac. Here is the link to the Audio Decoder I use.”[2]

The two-part conversation shows how modern social interaction flows seamlessly between online and offline environments. We can start our communication with others online and continue or develop it offline or vice versa. While you are reading this article, you might be streaming music from Pandora.com. You might have posted on your Facebook profile or Twitter about this story. When your friends read about it, you may perhaps talk about it over dinner. That said, keep in mind that you are not designing for either an online or an offline experience. You have to consider how to bridge the two worlds of experience seamlessly.

Our real world and online lifestyle have merged, triggering endless possibilities for communicating through design. The boundaries of experience design are not defined by media, but only by the designer’s creativity.

About the Author

Umyot Boonmarlart (aka—Umy) is an interactive designer and New Media Artist. He focuses on combining various media from prints, video, radio to interactive media to achieve marketing purposes based on wide range of experiences in marketing and media.

Umy’s interactive work not only has the quality of newness but also embed Eastern philosophy to make them meaningful.

Umy’s currently a Designer at one of the top global innovation firms, frog design Inc.

Web: www.umyot.com

Facebook: www.facebook.com/umyot

Twitter: umyot

LinkedIn: www.linkedin.com/in/umyotb

[1]. www.fml.com (a famous comedy feed website)

[2]. Lossless Decoder, http://tmkk.hp.infoseek.co.jp/xld/index_e.html

A Woman in UX: I’ve Come a Long Way, Baby

“You don’t have the ‘presence’ that we’re looking for,” said an employer I wanted to please.

When I asked why, the employer could not explain. Did I need to wear suits? No. Was I acting unprofessionally? No. Finally, the employer pointed out to me some examples which happened to be masculine. To this day I believe the desired presence was a tall, dynamic male with a deep voice, the classic CEO presence, as Blink points out[1]. Being a short female with a squeaky voice, I clearly did not have that appearance.

While companies in the United States and other industrialized nations might not blatantly discriminate against women, the subtle slights run rampant even from the most well-intentioned people. My employer in question was not purposely unfair to women and I genuinely liked the company. The company also had clear policies for equal opportunity of men and women. But good intentions and a company policy do not and cannot root out all our human biases.

As a woman in UX, I have found dealing with these snubs while advocating for user experience a challenge. I’d like to share some specific situations from my more than 13 years as a UX professional in the southeastern United States and how I overcame them.

Machismo

“Macho doesn’t prove mucho.” (Zsa Zsa Gabor)

Machismo is an “exaggerated masculinity” that is “often coupled with a minimal sense of responsibility and disregard of consequences.”[2],[3] Over the years, I’ve run into Mr. Machismo in a few forms. Developers, executives, researchers, consultants and even designers each deliver their own flavor of machismo. A prominent design example is the series of tirades and “flops” by Peter Arnell, who was recently voted one of New York’s worst bosses. And the quintessential executive example is Ken Lay of the Enron scandal, which brought the financial world and economies around the globe to their knees.

For me, what marks someone with workplace machismo is an aggressively staunch single-mindedness. For instance, a machismo-ridden developer wants to be seen as delivering the best or quickest development solution ever and could not give a damn about anything else. Because most interactive solutions need to consider much more than what Mr. Machismo thinks about, he will derail a project. What is the problem? Mr. Machismo acts really certain about his narrow-mindedness. Unfortunately, aggressive certainty is extremely convincing, regardless of whether the person is right or wrong.[4] Even more unfortunately, this persuasive certainty often lands people with machismo in top leadership roles, so you will more than likely have to work with one.[5]

Early in my career, I thought I simply did not have enough experience to question someone who seemed so very certain of himself. After many years, I’ve watched such a person flop so often that, now, I almost immediately doubt anyone who is extremely sure and completely unwilling to listen to others.

Can women suffer from machismo? It seems possible to me. However, I personally have not experienced it, so I can’t speak to that situation.

How to Deal

I’ve found these techniques handy:

1. Communicate firmly and intelligently.

People with machismo are not the people with whom you can brainstorm. You have to know exactly what you’re going to say and how to say it. You have to demonstrate certainty back. If you need to do more research to answer a question, simply say that. Be certain that you can get an answer to a question, even if you don’t have the answer right then. And, though Mr. Machismo likely will be rude to you, you cannot be rude back if you hope to make progress on changing this person’s mind. Lower your expectations of this person’s communication skills, but don’t lower your own skills in the process.

2. Be persistent, consistent, and calm.

Sometimes, you don’t have to convince the person with machismo, but you have to compete with that person to convince someone else of a decision or approach. In a meeting, Mr. Machismo will talk (or shout) over you, and his extreme certainty might carry the day. But use time to your advantage. Calmly bring the topic up again. Provide new arguments or more supporting research. Point out the many considerations that Mr. Machismo is excluding. Follow up in a variety of communications. The person with machismo will not have the patience to compete.

3. Refuse the “secretary” or other stereotypically female roles.

I once worked on a project where a particularly machismo researcher consistently asked women to take notes for his meetings, as if they were his secretaries. When he asked me, I politely declined and am glad I did. As the project progressed, he asked women to do other administrative tasks but did not even approach me. Don’t do what Mr. Machismo thinks you should do, and he will get the picture quickly.

4. Limit your time with Mr. Machismo—and be prepared to leave, if necessary. If I find this person to be pretty toxic I limit my exposure. Regular meetings are fine. Co-working over many weeks of a project is not fine. Dealing with him well requires effort and preparation; constant exposure will exhaust you quickly. Plan your schedule accordingly. And, if the situation gets too toxic, be prepared to leave it, even if it means finding another job.

Women Who Hold Women Back, Way Back

“There is a special place in hell for women who don’t help other women.” (Madeleine Albright)

Another difficult situation I’ve experienced is the woman who undermines other women. This phenomenon is so illogical to me that I don’t fully understand why it happens. I think it is partly a response to feeling threatened by other capable women. Regardless of the reason, I know it happens. I’ve experienced surface slights, snide comments or veiled insults as well as deeper backstabbing. Even more disturbing, I have heard stories from several women UX colleagues about female bosses not acknowledging their contribution to high profile work; socially engineering them for intellectual property and publishing or selling it as their own; or literally preventing their advancement in a company. The result of this undermining behavior is a complete erosion of trust—trust that is critical to exploring and refining user experience ideas.

Do I think women should favor other women over men? Absolutely not. Women just need to give other women a fair shake. After a couple of rough experiences, I’ve learned how to cope with Ms. Way Back.

How to Deal

1. Do your research before working with her.

In my experience, Ms. Way Back undercuts most women with whom she works, but it might not be obvious. So, a little research can go a long way toward uncovering whether a prospective colleague or boss is a Ms. Way Back. If so, then you need to decide whether the benefits you might get out of the work or position outweigh the costs. One time, I unknowingly took a position with such a boss and it caused me many months of profound frustration. Don’t make the same mistake.

2. Confront significant or repeated snarky comments.

“You need to eat more,” said one portly boss to me in a meeting as she shoved a plate of cookies in my face. Yes, other people were present. At the time I was flabbergasted and didn’t know how to respond. Now, I do. “Thanks, but I’m not hungry now. If my weight is a concern to you, let’s chat about it after this meeting.”

3. Persist about a decision that seems unfair.

Don’t take Ms. Way Back’s unfair “no” for an answer. Ask for reasons behind an undeserved decision and, if the decision still seems unfair, calmly ask for the decision to change and explain why. If you have a reasonable alternative to suggest, suggest it. As you persist, it is crucial to stay respectful of Ms. Way Back. Do not give her any reason to dismiss your concern as questioning her authority. If her behavior is a defensive reaction, attacking or criticising her will just make her more defensive.

4. If persisting doesn’t work, go around Ms. Way Back.

If you give a good effort at persisting and the decision is important, such as whether to promote you, then bypass her and go to her boss. If you are conscientious then you probably hate this idea. But you owe it to yourself to do what is best for your career. If an unfair decision from Ms. Way Back is delaying your career, do everything you can to change it. The key, again, is respect. Convey respect for Ms. Way Back to her boss. Do not criticise her personally but criticise the decision. Explain why you deserve a different decision and support your reasons with solid facts and arguments.

Negotiating

“You get in life what you have the courage to ask for.” (Oprah Winfrey)

The previous two sections hint at the need to negotiate. I learned it mostly on the fly, especially because user experience often involves negotiating between user, technology, and business needs. Over time, I discovered the importance of negotiating not only for my UX project but also for myself. I recently found two fascinating books that encourage women to negotiate, books I wish I had had early in my career. Women Don’t Ask shares the insights from a wealth of research that proves women negotiate less and, systematically, are not taught how.[6] Ask for It offers approaches and tips specifically for women as they negotiate in the workplace.[7] Below are a few techniques that have helped me and my UX projects.

How to Deal

1. Do negotiate. Always.

Very early in my career, I skipped negotiation because I trusted that the person hiring me was making me the best possible offer. I eventually learned my salary was not up to industry standards and asked for it to change. Ever since then, I have negotiated job offers, proposals and just about anything possible to negotiate. “Ask for It” notes that the reality is that the person hiring you, or making you an offer, anticipates that you will negotiate. In fact, you could argue it would be strange not to negotiate. Consider it a convention.

2. Know and show what you’re worth, politely.

How do you convey your value without coming across like a bombastic jerk? The authors of “Ask for It” have found, fair or not, that women are most successful in negotiating when they do so pleasantly. I find the best way to “sell” myself is not to sell but to simply explain the achievements or benefits. I think of it as communicating clearly and persuasively, not selling, and the negotiation flows easily from there. I find this explanatory approach also helps with promoting my UX projects. Executives cannot appreciate a UX project if no one gives them a glimpse into the work behind it, I simply provide a glimpse.

3. Practice.

Practicing negotiation might feel silly, but it’s really smart. I’m striving to practice it more often. Anticipate questions or objections and prepare answers. Recite your comments or possible answers. You will feel much more comfortable then with the real negotiation.

We Have a Long Way to Go

“How wonderful it is that nobody need wait a single moment before starting to improve the world.” (Anne Frank)

UX women in the workplace have come a long way. Marissa Meyer, Google’s VP of Search and User Experience, was named one of Glamour’s 2009 Women of the Year. Fast Company has an annual spotlight on influential women in technology. But I feel we have work left to do. Like a good UX professional, we can start that work with a top-down and bottom-up approach.

Looking Top-Down: More Women UX Heroes and Speakers

We’re lucky to have some outspoken women in UX. We need these heroes to inspire women considering or entering a career in user experience. Just as importantly we need these heroes to be memorable examples to executives. By serving as examples that easily come to mind, these heroes fight the cognitive bias of availability.[8] The more easily executives can imagine women in prominent UX roles, the more likely it is that executives will make it happen.

Looking Bottom-Up: Day-to-Day Accountability

At the same time, we need to be conscious of the decisions and comments all of us make each day. It’s easy to go with the flow when we have so much work to do. But every slight we make and every bias we ignore accumulates into an unintended “glass ceiling” culture. The only fix I know is to watch what we say and do so vigilantly until we form a culture that naturally gives anyone good at UX an equal chance at advancing. We might not change the culture of a large organization or entire industry overnight. But, we can influence the culture of the projects we lead, the teams we manage, or the companies we own and, in that way, serve as successful models.

Some of my experiences sound discouraging. Despite them, I have high hopes for change. I never gave that employer the “presence” it wanted. But, through my user experience leadership, I gave results, including improved customer satisfaction and fewer angry customer calls. The employer recognized the effort, giving me an award that only four out of 250 people earned and a promotion. It’s hard to argue with results. I believe women in UX bring them in spades. And, I believe that results will prevail.

About the Author

Colleen is the principal of Content Science, a boutique interactive consultancy in Atlanta, GA. As a pioneer of user experience and content strategy for 13 years, she has guided or supported strategic initiatives for InterContinental Hotels Group, Philips, Cingular Wireless (now AT&T), and Centers for Disease Control and Prevention.

Colleen loves helping clients get results online by studying how content influences people’s decisions. Colleen is turning all that study into a book called CLOUT: The Art and Science of Influential Web Content. Look for it from New Riders in December 2010.

Find Colleen online here:

Web: www.leenjones.com

Twitter: leenjones

Company: www.content-science.com

[1]. Gladwell, Malcom. blink: The Power of Thinking without Thinking. Back Bay Books, 2005

[2]. Machismo. (2010). In Merriam-Webster Online Dictionary. Retrieved January 17, 2010, from http://www.merriam-webster.com/dictionary/MACHISMO

[3]. Machismo. (2010). In Encyclopedia Britannica. Retrieved January 17, 2010, from Encyclopedia Britannica Online: http://www.britannica.com/EBchecked/topic/1381820/machismo

[4]. Burton, R. (2008). On Being Certain: Believing You Are Right Even When You Are Not. St. Martin’s Press: New York.

[5]. Board, B. & Fritzon, K. (2005). Disordered personalities at work. Psychology, Crime & Law, 11(1), 17-32.

[6]. Babcock, L. & Laschever, S. (2007). Women Don’t Ask: The High Cost of Avoiding Negotiation--and Positive Strategies for Change. Princeton: Princeton University Press.

[7]. Babcock, L. & Laschever, S. (2009). Ask For It: How Women Can Use the Power of Negotiation to Get What They Really Want. Princeton: Princeton University Press.

[8]. Schwarz, N. et al. (1991) Ease of retrieval as information: Another look at the availability heuristic. Journal of Personality and Social Psychology. 61 (2)195-202.

Out of Focus

Here’s a question for you: Would you give up your seat on a crowded bus for an Armenian woman?

I’d like to think that you—and, indeed, everybody else reading this book—would respond to this question with a hearty “Yes, of course I would!” But can I trust your answer? I’m not sure. Okay, so race might not play a part in your decision. But, as Ricky Gervais might say, what if she was talking to the driver while the vehicle was in motion? What if she didn’t have the correct change ready when she got on? What if she had previously been sitting in one of those seats that are reserved for disabled people?

Stanford psychologist Richard LaPiere didn’t trust the answers he received to this question back in the early 1930s either, so he took it upon himself to find out the truth. Unfortunately, he had made a bit of an oversight; he didn’t know any Armenian women and therefore had no opportunity to observe their treatment on public transport at first hand. Luckily, however, a Plan B was about to land in his lap.

One day, LaPiere answered the door to find a rather anxious-looking student standing on his doorstep. The student explained that he and his young wife had arrived fresh from China that morning, only to find that the university’s halls of residence were full to capacity. As a result, the couple were in desperate need of a place to stay. LaPiere therefore offered to drive them to the main hotel in town.

This was an offer that LaPiere made with some trepidation, however, because Chinese people were something of a rarity in 1930s America and, as such, were frequently subjected to terrible (and overt) racial prejudice. The hotel, LaPiere recalled, was especially “noted for its narrow and bigoted attitudes towards Orientals”.

Upon arriving at the hotel, LaPiere nervously enquired as to the availability of a room for his new friends. To his great surprise, however, far from displaying the prejudice for which the hotel had gained a reputation, the clerk was polite and attentive, and quickly found the couple a suitable room.

Puzzled by the disparity between the hotel’s reputation and the clerk’s treatment of his new friends, LaPiere later telephoned the hotel and asked whether they had a room available for “an important Chinese gentleman”. “No”, he was told, in no uncertain terms—the hotel would not accommodate a person of Chinese race.

LaPiere was shocked by the discrepancy between how the hotel said it would behave and how it actually behaved in practice, but was wise enough to realise that his experience might have been atypical. To investigate further, he would need to repeat the same “experiment” with a far larger number of hotels. So he picked up the phone again and invited his new Chinese friends to accompany him on a driving tour of the West Coast of America.

This was an offer that the Chinese couple readily and gratefully accepted. To them, LaPiere appeared to be the most kindly of professors—a man who, out of the goodness of his heart, had found the time in his busy schedule to show them around his homeland. They did not, for a moment, suspect that they were about to become the guinea pigs in one of his experiments.

The experiment ended up encompassing 10,000 miles, 66 hotels and 184 restaurants. Upon arriving at each of these establishments, LaPiere let his travelling companions enquire about the possibility of accommodation or food and then secretly noted whether their request was successful or not. The results matched his earlier experience. The Chinese couple received courteous and helpful service almost everywhere they went—service that was no better or worse than that received by the establishments’ white patrons—leading LaPiere to conclude that:

“... the ‘attitude’ of the American people, as reflected in the behaviour of those who are for pecuniary reasons presumably most sensitive to the antipathies of their white clientele, is anything but negative towards the Chinese.”

Six months after returning from the trip, LaPiere conducted a follow-up study, sending a questionnaire to each of the hotels and restaurants he had visited. This questionnaire asked their owners about the types of people they were prepared to accept patronage from and included the question: “Will you accept members of the Chinese race as guests in your establishment?” The answers LaPiere received to this question made for uncomfortable reading. Over 90 percent of respondents ticked the “No, Chinese people are not welcome here” box, with almost all of the remaining 10 percent ticking the “Uncertain” option. LaPiere received only a single “Yes” to this question, to which the owner had attached a short note saying that the reason she would welcome people from China was because she had recently enjoyed a nice visit from a Chinese man and his sweet wife!

What LaPiere’s research reveals—and that countless other studies have since corroborated—is that people cannot be trusted to accurately report or predict their behaviour. What they say they do and what they actually do are often two completely different things.

Focused on Failure

As far as most organisations are concerned, the phrases “customer research” and “focus groups” are interchangeable. Whenever they need to make an important decision about a particular product or service, they will corral a group of customers, solicit their opinion and then fix a strategy based upon their response. Yet focus groups are, in fact, absolutely useless. There, I said it. In your face marketers. Want to argue the point? I’ll take you all on!

Before I explain why this is the case, let me first define the term “focus group”, since it is employed to describe all manner of different sins. A focus group is a bunch of people who have been gathered together for an in-depth discussion about a particular product or service. They usually consist of eight to ten participants who have been selected because they possess a set of characteristics (or “demographics”) that are deemed representative of a certain target group of customers or users. For example, if your product is aimed at lawyers, you might want to recruit people who have the relevant legal qualifications, earn a lot of money and possess no moral or ethical backbone. (Just joking legal eagles. Please don’t sue me—I’ve already gotten myself into a fight with the marketers.) Focus groups generally last between one to two hours, and are often held in the evening so participants can attend after work.

A moderator leads the group, drawing out the participants’ collective peeves, passions and prejudices while they discuss the product or service. Typically, several focus groups are conducted in total (each comprising a different set of participants), to determine whether key themes uncovered in one are repeated in others and are therefore likely to be common to the target group of customers as a whole. The exact number of groups usually depends on the time and budgetary constraints of the commissioning organisation, and the type of product or service under investigation.

Representatives of the commissioning organisation usually watch the focus groups as they unfold from an adjacent room via a one-way mirror, and often feed new questions to the moderator on the fly or at the end of each session.

Sounds reasonable, doesn’t it? Yet, focus groups have been responsible for some of the biggest marketing disasters of all time. For example, in the early 1990s, in an attempt to convey “purity”, Proctor and Gamble had redesigned its famous Ivory soap to make it clear instead of milky, and in so doing, had seen a massive boost in sales. As a result, practically every company with a product that was supposed to be perceived as “pure” began hurriedly developing a transparent version of it. One of these companies was PepsiCo, who had come up with Crystal Pepsi—a product that they wanted to market as a caffeine-free “clear alternative” to normal cola, equating its transparency with purity and health. In 1992, the product was tested, by way of focus groups, in a number of regional markets and met with an almost universally positive response. Excited by these results, PepsiCo launched the product later that year and threw its weight behind it with a massive marketing campaign, including a ridiculously expensive Super Bowl ad.

Initial results were excellent, with the product capturing one percent of the US soft drinks market in its first year—a figure that doesn’t sound like much, but that equated to $474 million in sales, and provoked Coca-Cola to enter the market by launching a rival in the form of Tab Clear. Thereafter, however, sales of Crystal Pepsi fell away rapidly; so rapidly, in fact, that during the following year, PepsiCo was forced to pull it from the market. The product’s failure was later attributed to the fact that its target audience, the health-conscious, did not see it as offering anything that they were not already getting from Diet Pepsi and, once the novelty of its transparency had worn off, saw little reason to keep on buying it.

You would have thought that PepsiCo would have learnt its lesson from this mistake, but, in 2004, it repeated it with the launch of Pepsi Edge—a product that tasted similar to original Pepsi, but contained half the calories. Focus groups once again endorsed the concept, leading the company to roll out the product across the globe. The globe, however, rejected it en masse, thanks to what Business Week called its “murky positioning”. Pepsi Edge was neither zero-calorie Diet Pepsi nor mega-calorie regular Pepsi, but something in-between. The effect? Consumers who were watching their weight bought Diet Pepsi instead of Pepsi Edge because Diet Pepsi was the healthier option; while consumers who weren’t watching their weight bought regular Pepsi instead of Pepsi Edge because regular Pepsi was the tastier option. Ergo: No one bought Pepsi Edge and the product was quickly withdrawn from the market.

Why do focus groups produce such wildly misleading results? There are many reasons.

Let’s start with the setting. You would be hard-pressed to find a worse environment for the exchange of frank and honest opinion than your average focus group laboratory. Most are sterile, boring, beige places, with a whacking great one-way mirror at one end that cannot help but lead you to wonder, “Who the hell is watching me?” Drop into this setting a group of strangers, led in discussion by another stranger, and you have the perfect recipe for stilted, guarded, unnatural conversation.

Then there’s the moderator. Since the moderator is steering the discussion, and, as such, is not a detached observer, she has a direct influence on the results. It’s one of those “If a tree falls in the woods, and there is nobody there to hear it, does it still make a sound?” type situations. If people discuss a product in a focus group and there is no moderator there to guide them, do they still say the same things? It is impossible to know for certain. However, even if the moderator takes pains not to ask leading questions or otherwise impress her own beliefs upon the group, the introduction of some degree of bias is still very likely.

In their book, Qualitative Interviewing, Herbert and Irene Rubin note that bias also arises as a result of focus group moderators not having enough time to gain participants’ trust, a necessary precondition for eliciting their true feelings. Therefore, if the discussion turns to a controversial or sensitive issue (like race, sexuality or gender) participants are likely to feel a powerful impulse to self-censor or to give the politically correct answer, as opposed to the honest one.

Imagine if I turned up on your doorstep and asked you to tell me all about your sexual proclivities. Would you give me a frank and honest answer? I doubt it.

Finally, there are the participants themselves. The motivations of those who attend focus groups are varied; however, it is probably safe to say that most turn up for the money, and not because they have a burning desire to express their heartfelt feelings about products and services they might never have seen or used. Others come to enjoy the free food and beverages on offer (most focus group organisers offer free pizza and beer, or coffee and cake, as an additional incentive to attend) or merely just to interact with other human beings (sad, but true), while some are simply curious as to what a focus group entails.

I do not believe for a second that participants arrive at focus groups with the intention of deliberately misleading the moderator and, by proxy, the commissioning organisation (why would they bother? There’s nothing in it for them. They get paid the same amount whatever they say). Yet, for a variety of reasons, misleading the moderator is precisely what they end up doing. Many participants are too eager to please, for example. The heady cocktail of food, drink, payment and the constant validation of their opinions leads them to tell the moderator what they think he or she wants to hear, rather than what they actually think (some lonely souls even develop a crush on the moderator!). It can also be difficult for moderators to keep participants on track, prevent one know-it-all participant from dominating the conversation and to extract comments from shy and otherwise disengaged participants.

To be honest though, all of the aforementioned problems are flaws in qualitative forms of research in general and are not confined only to focus groups per se. Furthermore, any research company worth its salt will put in place a number of measures to mitigate these issues. For example, they will ditch the one-way mirror and fit-out their lab with home furnishings and decorations to make participants feel more at ease, (they will also refrain from use of the word “lab” so as not to make participants feel like they are taking part in some sort of bizarre scientific experiment) and they will employ highly-experienced moderators who are used to coaxing and cajoling comments out of the most introverted participants and ensuring that extroverted participants do not monopolise the conversation.

There is one problem that cannot be mitigated however, and that problem is the very one that Richard LaPiere and his Chinese companions discovered back in the 1930s: What people say and what they do are two completely different things. People will tell you that they hate a product, but then go out and buy it the very next day. Not because they are liars, but because when you ask people questions about how they are likely to behave in a hypothetical situation (like whether they would allow a Chinese person to stay at their hotel, or whether they would buy Pepsi Edge), they can only ever give you a hypothetical answer. This answer will usually have no bearing on what they would do in reality since, as neuroscientists have recently discovered, most of the thoughts and feelings that influence our behaviour occur in the unconscious mind, not the conscious mind, which means that, no matter how hard we try, we cannot accurately predict or report our behaviour!

These issues are intensified in focus groups that invite participants to comment on products and services that they have not previously seen or used (i.e. most focus groups). In these cases, participants are forced to make a snap judgement, an abstract opinion divorced from the reality of actual usage of these products and services.

It was this that led focus groups to reject Herman Miller’s Aeron Chair. Participants who attended these focus groups just didn’t “get it”, which in hindsight makes perfect sense, the chair was like nothing they had ever seen (or sat on) before, so how were they supposed to assess its value? They couldn’t, so they wrote off a product that later went on to generate millions of dollars in sales (and continues to do so to this day). The participants said they hated it, when what they really meant was that they were not used to it. They said it was “ugly”, when what they really meant was that it was “different”.

Focus Pocus

Given these serious flaws you might wonder why focus groups remain so popular. There are several reasons:

Firstly, focus groups have been around for years (they were first used over 60 years ago, in fact, by US government sociologists investigating the effectiveness of World War II army training and military propaganda movies) and are therefore clearly-defined in terms of process, outputs, cost and timeframes. They are also quick to design and conduct. These factors make organisations feel comfortable in commissioning them.

Secondly, there is ignorance, many organisations conduct focus groups to evaluate their products and services for no other reason than because they have always conducted focus groups to evaluate their products and services. These organisations usually are not aware that better alternatives exist.

Thirdly, focus groups are widely used, which gives them legitimacy in the form of “social proof.” (“Everyone else is using focus groups, so we should use focus groups too.”)

Fourthly—and, in my opinion, most importantly of all—you can make a focus group deliver any conclusion you want. Don’t believe me? Then ask an advertising agency and they will put you straight! Quantitative research methods, like opinion polls, deliver cold hard statistics that are extremely difficult to “re-frame”. Qualitative methods like focus groups, however, deliver a heap of often confusing and contradictory sound bytes, from which analysts can cherry-pick those that support whatever hypothesis they choose. (I call this type of conjuring “focus pocus”.) This usually results in them choosing a group of quotes that underplay bad news and overplay good news, in an attempt to please the commissioning organisation. Why? Well, because it is human nature; nobody wants to upset the people who pay their wages.

Unfortunately, such behaviour often leads to disaster. When General Motors focus-grouped its Pontiac Aztek, for example, many participants were critical of the vehicle’s “boxy” design. However, the internal team, responsible for running the focus groups, apparently decided not to report this to GM’s executive management team, in the belief that it would be career suicide to do so. The company had invested so much time, money and effort into developing the vehicle, that the analysts felt that they had no choice but to give it the green light.

This was a good move for the analysts (at least, it was in the short-term as it no doubt ensured their preservation); but a very bad move for GM as a whole. Prior to launch, GM forecast sales of 75,000 Azteks per year, determining that it needed to sell just 30,000 units a year to break even. Unfortunately, only 27,322 were sold in year one—with more than 50 percent of those purchased by captive audiences like car rental companies (whose pre-existing agreements with GM meant that they were contractually obliged to purchase a fleet) and GM executives (who were forced to purchase the vehicle so as to be seen to be flying the company flag). At the tail end of that year, Kay Polit, principal analyst at management consultancy A.T. Kearney, suggested that warehousing the excess supply, plus the cost of the incentives necessary to convince customers to overlook the vehicle’s “ugly” design, meant that selling the Aztek was already costing GM more than it had cost to design and build the vehicle. Four years later, sales of the Aztek had fallen to just 5,020, forcing GM to discontinue the model.

The irony: Styling aside, the vehicle was pretty darned good. The Aztek had one of the highest Customer Satisfaction Index (CSI) scores in its class and was named “Most Appealing Entry Sport Utility Vehicle” in 2001 by J.D. Power and Associates, who noted: “The Aztek scores highest or second highest in every [customer satisfaction] measure except exterior styling.” Had the focus group results not been censored, GM might therefore have swapped a few pieces of sheet metal around and delivered a world-beater.

In the case of GM, its executive team had no idea that the results of its focus groups had been manipulated. In many other cases, however, executives are complicit in this crime. The classic example is that described by MIT Professor, Justine Cassell, in a thought-provoking article entitled “What Women Want”. Authored by Ruth Shalit, the article reports Cassell’s experience of working with a company that was developing technology targeted at teenage girls. Following a series of focus groups, the organisation concluded that what teenage girls desperately wanted was technologically-enhanced nail polish. Which was great, because it just so happened that technologically-enhanced nail polish was precisely what the organisation had just invented!

It probably won’t shock you to learn, however, that when Cassell conducted her own (independent) research with more than 1,800 teenage girls in 139 countries, in which they were asked to describe what they would like to use technology for, not a single one of them articulated a need or desire for technologically-enhanced nail polish.

As these case studies demonstrate, the primary function of focus groups is usually not to validate the product or service itself but to validate the commissioning organisation’s pre-existing beliefs about the product or service. Thus, while focus groups purport to explore the needs of consumers, they really only fulfil the needs of vendors.

So if we can‘t rely on focus groups to provide an accurate evaluation of our products and services what can we rely on instead? The answer to this question is simple: we need to ignore what people say and, instead, pay attention to what they do. In other words, we need to follow Richard LaPiere’s lead and get out into the field. LaPiere knew that people could not be trusted to report their attitudes towards those of a different race accurately, so he drove across America to observe their attitudes towards those of a different race in person. We must do similar.

Thus, if you want to evaluate your website, forget focus groups and commission a user testing study instead. You’ll be shocked by the discrepancy between what users say and what they do. In a study I facilitated recently, I watched a user repeatedly commend a retail website for its simplicity and “well thought out” design, while failing to complete seven of the eight tasks I asked her to perform on it! Why did she continue to commend it? She blamed the problems she experienced on her own ineptitude, rather than on that of the site’s designers. Such behaviour is commonplace.

If you are still planning your website, watch people using your competitors’ offerings or get out of your office and observe users in the offline world attempting the types of tasks that you will eventually facilitate in the online world. This will help you identify aspects of their behaviour that you can better support via your site, and prevent you from becoming side-tracked by the phantom issues that users might otherwise report in focus groups.

These are precisely the techniques that we employ at Etre, although, having read this far, I wouldn’t blame you if you were no longer prepared to just take my word for it!

And Now for a Confession …

… but before I get to that confession … pop quiz hotshot! Ponder each of the following questions for a moment or two and, if you have a pen and paper handy, scribble down your answers as you go:

1. Do you intend to buy a car in the next six months?

2. How likely are you to give blood in the next six months?

3. How likely are you to floss your teeth in the next two weeks?

Finished?

Great!

Now, imagine me sitting in a revolving chair, wearing a grey Nehru Jacket, stroking a Persian cat and unleashing my most evilest laugh. Mwha-ha-ha-ha-haaaaaaaaaaaaaaaaa!

Because by asking you these questions, “all ur brains are belong to me!” Or put another way, I have just made you far more likely to buy a car, give blood and to floss your teeth in the next few weeks than you otherwise might have been.

How have I achieved this astonishing feat? Priming.

Priming is a recently-discovered method of exploiting the Automatic System of the brain that involves using subtle cues, or “primes”, to increase the ease with which certain information comes to mind or to trigger associations that stimulate a desired action.

Priming was first observed in the field of social science, where the use of the survey (or questionnaire) as a research tool is commonplace. Social scientists employ surveys to find out how likely people are to engage in certain types of behaviour; how likely they are to vote, commit crime, purchase a particular product, and so on. This method of research has been used for years, since it is pretty much the only way of getting inside people’s heads and examining their intentions, without using a scalpel. But, as scientists have recently discovered, this method of research is fundamentally flawed. Because when you use a survey to measure people’s intentions, you ultimately affect their conduct. More specifically, when you ask people what they intend to do, they become much more likely to actually go ahead and do it. Like a ticking time bomb, they are “primed” to blow.

Interestingly, while this phenomenon is commonly known as “priming”, social scientists tend to refer to it as “the mere-measurement effect” (as it is an effect that is achieved merely by measuring something). They also consider it a pain in the “ruddy” neck, because, when they conduct a survey, they want to catalogue people’s behaviour, not alter it.

This negative perception is not shared by everyone, however. Marketers, campaigners and evil geniuses, for example, positively adore the mere-measurement effect, as altering people’s behaviour is their primary objective. Prior to the discovery of the mere-measurement effect, those who wanted to, say, encourage supporters of a particular political party to vote at the next election had few options. They could run a media campaign to emphasise the stakes; or they could find ways of reducing the barriers that traditionally prevent people from voting (they could bus their supporters to the polls free-of-charge on election day, thereby eliminating the cost and inconvenience of voting, for example). Yet, while such ploys typically yield positive results, they are also extremely costly (and time-consuming) to plan, execute and manage. Which is precisely why campaigners like the mere-measurement effect. Because it turns out that by merely asking people, on the day before the election, whether they intend to vote, you can increase the probability of their actually voting by as much as 25 percent!

Similar success stories can be found in a multitude of different arenas. Let’s return to the three questions I asked you a moment ago, the first of which was: Do you intend to buy a car in the next six months? When Morwitz, Johnson and Schmittlein put this question to a nationally representative sample of more than 40,000 Americans back in 1993, they found that it increased automobile purchase rates by more than 35 percent!

The second question I asked was: How likely are you to give blood in the next six months? When Godin, Sheeran, Conner and Germain put this question to 4,672 people who had donated blood in the past (as part of a questionnaire that enquired as to their intentions to donate blood again in the future), they found that it increased blood donations over the course of the following six months by 8.6 percent!

The third, and final, question I asked was: How likely are you to floss your teeth in the next two weeks? When Levav and Fitzsimons put this question to 50 MBA students in 2006, they found that it increased their flossing by a factor of 52 percent.

Pretty impressive, eh?

But we aren’t done yet, as it turns out that the mere-measurement effect can be amplified by supplementing questions about what people intend to do, with questions about when and how they plan to do it. This was first demonstrated in 1965, when Leventhal, Singer and Jones delivered a lecture to a group of senior students at Yale University on the risk of tetanus and the importance of visiting the on-campus health centre for an inoculation. At the end of the lecture, the three researchers asked the students how likely they were to go and get the shot. Most said they planned to do so. But when the researchers questioned the students again a few weeks later, it transpired that only three percent had actually made good on their intentions.

Disappointed by this result, Levanthal and co. corralled a new group of seniors and delivered their lecture again. This time however, they gave them a copy of the campus map, upon which the location of the health centre was circled, and asked them to plan the route that they would take to get there. They also told the students to take a look at their weekly schedules and pick a time and date upon which they would be free to go and get the jab. The result? Over the next few weeks, 28 percent of the students visited the health centre and received the shot.

As Richard Thaler and Cass Sunstein point out in their influential book Nudge, notice the subtlety of these additional “primes”. Since the students were all seniors, and the Yale campus is relatively small, they did not need a map to tell them where the health centre was located; and since they were only told to plan a visit to the health centre, as opposed to being forced to make an appointment, they were under absolutely no obligation to get the inoculation. Yet, nine times as many students wound up getting the shot this time around.

Surprisingly, social scientists have found that they can prime people to perform certain types of behaviour by offering even subtler cues. For example, a 2003 study by Aarts and Dijksterhuis found that showing people a picture of a library, telling them they were about to visit a library, and asking them to pick out words like “silence” and “whisper” from a collection of nonsense words, primed them to speak more softly; a 2005 study by Holland, Hendriks and Aarts found that the faint odour of cleaning fluid made people more likely to tidy up after themselves when eating a crumbly cookie; a 2004 study by Kay, Wheeler, Bargh and Ross found that game-players were more competitive, less cooperative and less generous when a briefcase was placed by the door of the games room (priming them to think of “work”); while a 2008 study by Williams and Bargh found that participants’ judgments about strangers were affected by whether they had been given a cup of iced coffee or hot coffee beforehand. (Those given iced coffee perceived strangers as being “colder” than those who were given a hot cup of Joe.)

Which brings me to my confession; while I have devoted this chapter to bashing focus groups, surveys and other research methods that concentrate on what people say they do, as opposed to on what they actually do, the mere-measurement effect provides a great reason to go ahead and employ these methods. Because, if you can increase the usage of your website by doing nothing more than asking people whether they are likely to visit it at some point in the future, then that is all the reason you need.

So employ focus groups and surveys to ask people about the likelihood of their using your website (ask them how and when they plan to use it too, if you can). Just don’t waste your time analysing their answers, as they’ll almost certainly “prime” your site for implosion.

Well, that is about it from me. But before I sign off, let me leave you to ponder one final question: how likely are you to recommend this book to your friends in the next six months?

About the Author

Simon Griffin is co-founder and Director of User Experience Design at Etre Ltd—a London-based digital communications agency that specialises in results-driven user experience strategy and design.

Simon studied at Liverpool Art School, The Lansdown Centre for Electronic Arts at Middlesex University, and London’s prestigious Royal College of Art, obtaining a first class BA College graduate degree in Graphic Arts and an MA in Design for Interactive Media. In 1999, he won The Guardian newspaper’s Student Publication Designer of the Year award and was runner-up in The Independent’s Best Student Designer competition. Since then, he has helped deliver award-winning websites and applications for Hershey’s, MCI, HP Shopping, and Vodafone; and worked with many other global brands, including HSBC, Deutsche Bank, Bear Stearns, Deloitte, Rolex, American Express, Eurostar and MSN. In addition to assisting clients, Simon writes Etre’s monthly newsletter (www.etre.com/subscribe/) and is a major contributor to the company’s blog, Reaction (www.etre.com/blog/).

A massive soccer fan, Simon co-wrote and sings the theme tune that is played whenever the world’s oldest professional football club—Notts County FC—takes to the field. As you might have guessed, Simon is an ardent supporter of the mighty Magpies!

Twitter: sigriffin

LinkedIn: http://uk.linkedin.com/in/simongriffin

Web: www.etre.com

Sources and References

1. Schuman, H., “Method and Meaning in Polls and Surveys”, Harvard University Press, 2008.

2. Wiseman, R., “Quirkology: The Curious Science of Everyday Life”, Macmillan, 2007.

3. Gross, D., “Lies, Damn Lies, and Focus Groups: Why Don’t Consumers Tell the Truth About What They Want?” Slate Magazine, 10 October 2003. http://slate.msn.com/id/2089677/

4. Rubin, H. and Rubin, I., “Qualitative Interviewing: The Art of Hearing Data”, Sage Publications, 2004.

5. Hodgson, P., “Is Consumer Research Losing Its Focus?” Userfocus, 01 June 2004.

http://www.userfocus.co.uk/articles/focuspocus.html

6. Gladwell, M., “Blink: The Power of Thinking Without Thinking”, Back Bay Books, 2007.

7. Unknown, “Shoot the Focus Group: Advertisers are Inventing New Ways into the Consumer’s Head”, BusinessWeek, 14 November 2005.

http://www.businessweek.com/magazine/content/05_46/b3959145.htm

8. Kobe, G. “How Focus Groups Failed Aztek, PT Cruiser”, FindArticles.com, Accessed 25 July 2009.

http://findarticles.com/p/articles/mi_m3012/is_2_181/ai_70935205/

9. Shalit, R., “What Women Want: Professor Justine Cassell on Underdetermined Technology, Social Norms, and the Gender Politics of Mobility”, mpulse, May 2003.

http://www.soc.northwestern.edu/justine/PressClippings/whatwomenwant.pdf

10. Leventhal, H., Singer, R. and Jones, S., “Effects of Fear and Specificity of Recommendations upon Attitudes and Behaviour”, Journal of Personality and Social Psychology 2, 1965.

11. Thaler, R. H. and Sunstein, C. R., “Nudge: Improving Decisions About Health, Wealth and Happiness”, Yale University Press, 15 June 2008.

12. Morwitz, V. G., Johnson, E. and Schmittlein, D., “Does Measuring Intent Change Behavior?”, Journal of Consumer Research 20, 1993.

13. Godin, G., Sheeran, P., Conner, M. and Germain, M., “Asking Questions Changes Behavior: Mere Measurement Effects on Frequency of Blood Donation”, Health Psychology/Official Journal of the Division of Health Psychology, American Psychological Association, 2008.

14. Levav, J. and Fitzsimons, G. J., “When Questions Change Behaviour: The Role of Ease of Representation”, Psychological Science, Volume 17 Issue 3, 23 February 2006.

15. Kay, A. C., Wheeler, S. C., Bargh, J. A. and Ross, L., “Material Priming: The Influence of Mundane Physical Objects on Situational Construal and Competitive Behavioral Choice”, Organizational Behavior and Human Decision Processes 95, 2004.

16. Williams, L. E. and Bargh, J. A., “Experiencing Physical Warmth Promotes Interpersonal Warmth”, Science, 24 October 2008.

Seeing Things the Way They Are

The Student

Xun is a university student from China, living in Australia while he completes his studies at a local university. He is in the second year of a double degree in IT and Economics.

The university computer systems are not easy for students to use, especially for those who do not have English as a first language. It’s not strictly his competency in English that makes it difficult for Xun, but rather the cultural references or specific context of use.

“Sometimes I can read and understand the word, but how it is used in Australia is different to how I know the word. You need to think of what a word means in Australia, as well as what it means in English.”

Yet it’s not just international students like Xun who have difficulties with language. Even the local students have to come to terms with the academic and bureaucratic terminology used, which can be very confusing. For instance, there are the names of departments, initiatives, programmes, policies, facilities and, of course, the names of the computer systems. The problem is made worse by having multiple terms for the same thing, depending on who you ask or the age of the documentation you read. Often, the issue is exacerbated by conflicting or inconsistent use by staff.

If there were only a few computer systems, the meaningless (to students) names could be excused, but unfortunately there are a great number of such systems that Xun and his fellow students are exposed to, including the university website, faculty websites, course websites, student email, student portal, student accounts, virtual teaching environment, student union portal and the multitude of library systems.

There is little clarity, consistency or integration between these systems. Separate logins for many of them means that getting ‘muddled up’ with logins and passwords is a frequent problem for students. A strict security policy exists for many of the systems, insisting on certain combinations of alphanumeric and other characters to make passwords ‘stronger’. This makes passwords difficult to remember, thus Xun does what many other students do, and writes his usernames and passwords down in his diary. He also tries to make them all the same (if he can work out how to do so and if the inconsistent security policies for each system allow him to). Thus, the strict security policies do in fact lower security, rather than raise it.

Last but not least, there is the issue of usability. Xun considered himself expert at using computers back home, but quickly found he had difficulty using the software and systems at the university, particularly in the library.

“They’re all really different and most are very hard to use by us students.”

The library itself is another part of the university that doesn’t seem to be geared towards meeting Xun’s needs. He doesn’t use the library for much other than a desk to sit at; his courses are more about facts and figures, not reading and research.

“The library is too old fashioned, who needs books? I can just use the internet!”

Sometimes Xun will find a book to read in the library if he doesn’t have his textbook. But usually they don’t have it or are a few editions behind. When Xun does need to look something up for an assignment, he’ll ask his friends and see what they found. It’s not worth spending time looking too far; he’ll just take the first thing that looks ok.

“Staff in the library often get rather cross with us, saying we shouldn’t be just using Google, we should take time to learn the library systems and do research their way. Too hard, too long ... we don’t need to, it’s not important for us.”

There is a growing chasm between this educational institution and the student body that populates it.

On one side are the expectations and expertise of the staff, as well as the IT systems created largely by and for them. On the other side are the relatively inexperienced students who are struggling to consume, process and make use of the vast amounts of information they now have access to, and doing so in their own way. An understanding of the width of the chasm, and difficulties facing students, would allow systems to be designed in such a way as to make this scholarly path a little less bumpy.

The Small Business Owner

Ahmed is an electrician who runs his own small business. He is a relatively unsophisticated user of technology. He has a five year old computer in his home office, which is connected to the internet via moderate speed broadband. He has a mobile phone, and whilst it’s with him constantly and he makes many calls, he doesn’t use its other capabilities such as email or web browsing. His diary is paper-based, containing all his appointments and jobs and the contact details for each customer.

But Ahmed does use the web for research, from looking up directions to a customer site, to finding a new supplier for certain parts. He also looks for information to help him run his business. Like most small business owners, he tends to get caught up in the day-to-day rather than strategic planning and thinking about growth and maturity.

Generic business websites are of no use to Ahmed, he’s not interested in big business news, economics or shares and stocks.

“I run a business, I’m not interested in business. People send me stuff about what’s happening to some big company or tell me about the ASX200 or whatever ... that’s not me, I just want what I need to get through each day.”

The information he needs is very practical in nature; “what can help me right now?” This practical information includes ‘how to’ guides, expert tips and probably most important of all: case studies. He finds stories and lessons learnt from experience to be the most useful form of information—case studies from “real people”. He talks to other tradesmen and people he knows who have run a small business, even if it’s a completely different type of business. And he looks for the same thing on the web.

“A good small business site is like something you’d ask a friend about and would provide you with answers.”

So he prefers quite targeted information. He will use Google to search for the thing he needs, whether it’s a price for a part or information he can apply to solve a specific problem. He has taken note of a few websites that cater specifically for small businesses, and whilst he might not go to them directly, he recognizes them and knows which ones he thinks are good.

Ahmed tends not to browse through a site, and doesn’t often read news articles.

“I don’t have time for news; if you read a story you feel like you’ve wasted 10 minutes. When you go to a small business site, you are working; being on a news site is more like browsing.”

At the same time, Ahmed expects a good source of information to look reputable, professional and business-like. Generalist websites, for instance, often try to appeal to less sophisticated users by adopting a magazine style, but this can backfire because those same users don’t feel they can rely on the information, particularly if they are going to use that information for their business.

Being in business is not the same as “big business”, and the needs of most small businesses have nothing to do with the corporate high flyers who make the news. By understanding the needs and priorities of small business owners, and not confusing them with generic business people, websites and other information systems can be better designed for them.

The Parent

Stacey is a mother of three who has just returned to work after the birth of her son, James, aged four months. Stacey works for a large company, in their main office building in the city.

Recently, the company announced new initiatives for new parents. Stacey had to return to work when James was just three months old.

“We couldn’t afford to live on just one income, with three kids and all.”

So the announcement of anything to help her and other parents was a welcome relief. One of the actions taken by the company was to turn a meeting room into a breastfeeding room. In theory, this sounds like a good idea, but in practice it isn’t.

The room is not well-equipped, and is in a very conspicuous part of the office, so mothers who use the room feel uncomfortable. Stacey has used the room only once, before she had returned to work, on a day she came in to meet with her boss.

“I felt like people were looking at me, thinking ‘why isn’t she working?’ I fed him as quickly as I could and left, although I would really like to have spent a bit more time with him ... I didn’t feel as comfortable as I would like; it’s not private.”

Other mothers have told Stacey that sometimes staff use the room for a meeting or to eat their lunch. If there are no mothers in there at the time, the room is treated like it’s just another meeting room.

“They move things around and leave paper and rubbish, like it’s their lounge room. Even the change rooms you find at most shopping centres are better than this ‘dedicated facility’”.

But the biggest problem concerns the practical value of a breastfeeding room when there are no childminding or crèche facilities available. Stacey’s employer has made it clear there are no plans to provide such facilities and that third-party services “nearby” will need to be used.

“What am I supposed to do, put the baby in day-care, then every few hours go get him, bring him to work to feed him, then take him back to day-care? That’s stupid.”

The way in which the facility would need to be used is impractical and counterproductive. It reveals a lack of understanding of the needs of parents.

“They don’t know anything about what it’s like to raise children. Like my husband says, it’s a ‘half-arsed attempt at looking like they care!”

When Stacey doesn’t have James with her during the day, for example on the days she goes to work, she has to express her breast milk into bottles. His minder, either a relative who is babysitting, or the staff at a day-care centre, then feed him from the bottle. The only way in which the breastfeeding room could improve upon this would be if it was located close to James’ day-care, as well as close to Stacey’s work. Preferably, all in the same building.

“It upsets me because, for a mum, it’s useless. It does nothing for me, but if I were to complain or ask for something that is useful, I am made to feel bad; ‘we’ve already done this and that for you, what more do you want?’”

As a parent, Stacey sees it as her duty to do the right thing for her children and deeply resents her colleagues’ suggestions that she change her mind or do things differently. It’s an emotive subject, not merely an issue of facilities and policies.

Instead of making life easier for Stacey, and welcoming her back to work as a valued team member, the actions of her employer have done just the opposite. She now feels uncomfortable, pressured and unappreciated.

“If the new initiatives had not been introduced at all, I’d be in the same situation, not being able to breastfeed my baby on my days at work, only I wouldn’t have all this mental stress on top.”

By simply consulting with parents who have recently returned to work, or who will be returning soon, Stacey’s employer could have ensured the new initiatives would be effective and welcomed. An understanding of parents’ real-world needs, priorities and desires would have produced a much better outcome than taking a guess at what to do.

The Common Thread

“We do not see things the way they are, but as we are”. So says an ancient Jewish proverb, or an Indian Jesuit priest, or a French author of erotica, depending on who you believe. Either way, it’s a particularly poignant quote for those of us working in the field of user experience. For the single biggest threat to the user experience is the failure to understand how our intended audience sees the world—including any product or service we might design for them—and instead, basing our decisions on our own view of the world.

The phenomenon that the above quote speaks of is plainly evident for anyone who has conducted usability testing or user research. However, it often isn’t that obvious to our clients and colleagues who haven’t had such contact with actual audience members (aka “users”). They haven’t seen the frustration caused by products that are irrelevant, needlessly complicated or just difficult to use. We see things as we are, until we receive some information that gives us reason to think otherwise, to see things from the perspective of the audience.

It is for this reason that we need to understand who our audience is and how they see the world in general, but more specifically, how they think about the subject area in which we might be designing a product or service, whether it be a website, a physical facility or an entire institution. We need to hear the users’ stories, such as those of Xun, Ahmed and Stacey. Their stories illustrate the issue of designing a product based not on the views, attitudes, behaviours and needs of the audience, but rather those of the designer.

By ‘designer’ we mean the person or group who has influence over decisions regarding what to design and deliver. At Xun’s university, it is the academics and the IT vendors who actually sell their products to academics, who design and implement systems, and do so without a good understanding of the needs of their audience. In Ahmed’s case, it is the publishers of business content and the advertisers who want to reach a “business” audience. And for Stacey, it is the corporate HR department who want to be seen to be engaging with employees, rather than actually understanding their problems and solving them.

In each case, seeing and hearing their users’ story would have gone a long way towards ensuring these influencers had a realistic understanding of the audience whom they were trying to serve.

About the Author

Patrick Kennedy is a user research specialist, focussed on understanding audiences and their needs in order to inform strategy and the design of online experiences. In his role as Design Research Lead at News Digital Media, in Sydney Australia, he manages the research activities that help improve create and evolve some of Australia’s biggest websites.

Patrick has over ten years experience in web design, information architecture and user experience design, and has worked with many different types of organisations in a variety of industries, both in Australia and the UK, assisting them with enhancing their websites and other information systems.

Patrick appears regularly at industry conferences, including Oz-IA, OZCHI and UX Australia, and has published many articles on user research and related topics.

Web: www.gurtle.com/ppov

Twitter: PatrickKennedy

Coevolution

Part 1: Memories from the Past

Maps, plans and submarines. It was Paris, 1974 on grey rainy afternoon. My little brother and I would sit hunched over big sheets of white Canson paper with pencils strewn about the dining room table. We would spend hours here together, designing all sorts of hot rods, turbo jets, hypersonic spaceships and deep-ocean submarines, tending to every minute function, creating powerful, never-before-seen features. We would add shielding, automatic doors, air-compressed piping with every drawing more detailed than the last. Back then, more was definitely better. I remember the pleasure of drawing up plans of imaginary houses and visualizing the logic of the whole structure. I almost felt like I was inside the plan, walking through the rooms, to the patio, the terraces, passing by the planetarium and the rocket launch pad. For hours, we could escape these rainy, boring afternoons, passionately building intergalactic residences at the foothills of the mountains of Mars.

The Press: My Big Fat Family

No matter how hard you try or how far you wander, there will still be a little part of yourself hooked by it. The big, fat social entity called The Press. People who have been fortunate (or unfortunate) enough to work in the press know it’s like family. You can never really get away from it and here I was, fifteen years after perfecting my submarine blueprints, working as a graphic designer in the press. There is—there was—something special about it, an undefined feeling of (almost) total freedom and a feeling that anything could happen that day. Enchanted by an unexpected opportunity for me to join the design team of Rolling Stone Magazine in Paris, I stepped into one of the most valuable practices of my career, designing news information. Nothing like we do today in the glorious field of Information Design or in Information Architecture. A heavy metallic ruler, a sharp X-acto knife, a sturdy plastic cutting board, blue-millimetre graph paper and glue were my tools and full-length articles printed on bromide paper were my reference material. I was spending my days calibrating and arranging long strips of printed text, cutting and gluing tiny pieces of typographic composition in the most possible precise way, scratching spelling mistakes with a blade on photogravure films. For years, the practice of structuring information was an actual physical activity for me.

Graphic Design? Sorry to Say, But We Broke Up

We were never told enough that everything comes to an end. My breaking up with graphic design happened right on time, although it was a bit hard on my pride. My final gig as a freelance graphic designer had been a minor catastrophe. I had rush-delivered an admittedly bad proposal for a painkiller ad to the account manager of a small Parisian ad agency. He was brief with me, either hash out a better idea or accept a pitiful sum in cash and move on. Was he joking? In his hand was 1000 Francs (barely the equivalent for 2 days of work). Without a second thought, I took the cash and walked out the door, leaving the guy standing there with his mouth wide open. I promised myself I would never work as a graphic designer again, and I never did. Because, fortunately, I had recently met a new friend who was so much more innovative than graphic design and way more exciting—the Internet.

Tonight, the Web Saved My Life

In the risky practice of rock climbing, a climber must sometimes let go of all the grips he’s holding in order to advance to a higher grip. It’s a moment solely dedicated to decision. If he decides to jump for it, he will feel a moment of suspension in space and time, a short tenth of a second where he is defying gravity, suspended in the air, between the grip he just released and the one he has not reached yet. At this very instant, he has no choice but to have faith in the solidity of the next grip. I dedicated five years to the study of graphic design at an expensive design school (moreover paid by my gracious parents), yet when I left graphic design in 1997, I had nothing but a deep inner feeling that the web was something I could trust. Not only was this grip solid, it was vibrant, alive. I felt like someone was asking me, “Hey, they’re going to launch a spaceship to Mars soon and they’re looking for guys like you. Are you in?”

Part 2: Here and Now

Creativity Is Not About Me.

It is often stated that designers have to be creative, which begs the question: What is creativity, really? Inspiration? Something floating in the sky? A remarkable function of the brain? On Wikipedia, you read that “creativity is a mental and social process involving the discovery of new ideas or concepts”. The famous chemist and Nobel Peace Prize, Linus Pauling[1], used to say that “the best way to have a good idea is to have lots of ideas.” What is “a lot” then? Ten, twenty, a hundred ideas? Let’s imagine you decide to organize a 30 minute creative workshop with four colleagues. If each participant generates one idea per minute during 30 minutes, you end up with a total of 150 ideas. Not bad for a start, but being able to produce one idea per minute during 30 minutes can be exhausting for someone untrained. Creativity is a process in which participants have to leave behind certain assumptions, likes and dislikes, who they have been told they are (creative director, information architect, content strategist, project or account manager etc.) and even who they have been told they are not. Therefore, creativity is a practice in itself and this practice demands that the practitioner be in a flexible mental and physical state.

The Standard Revolution

If you were educated as a designer, you were likely trained to think that originality is the gateway to excellence. You must create something in a way that has never been done before. If you find yourself designing an object that must respect technical standards (a lamp, a book, a website etc.), you’ll probably feel the irrepressible need to tweak it, even just a little bit in order to leave your mark. Now, if you have been educated as an engineer, you are probably trained to think that excellence comes from the strict respect of established standards and rules along with the organizational aspect of team work. You will follow these rules and your team process even if you end up creating an over-complex solution for a simple object (a DVD player, a mobile phone, a database etc.)

Great designers succeed in bringing originality with their collaborative use of technological standards. Their knowledge of technology makes them comfortable enough to play with standards and innovate, just as gymnasts or dancers play within the strict discipline of their team. When the World Wide Web Consortium first proposed technical recommendations, the field of web design was at last permitted to enter the age of a maturing industry. Designing for the web became a revolution, but only for the designers who understood that the acceptance of technological standards and collaboration are the fundamental material of their creativity.

The Product Is the Process

What are the great design success stories today? The iPhone, the XO laptop (OLPC), a Porsche (my opinion), the Segway, the MacBook, nytimes.com and many more. How did these products come into being? Certainly not in one day, neither by one person, nor from one single idea. Having a vision, a dream, inspiration, the will to change something in the world, or to just make something more user-friendly is usually what guides the best design stories. What follows is a matter of process. Yes, process. If one finds a process boring and fastidious, it’s probably more “procedures” than “process”. A process is a wonderfully organized set of actions that can transform a vision into something real, tangible, usable and useful. And to do so, a process needs to be designed as if it was the final packaged product itself. But then again, isn’t that what User Experience Design is all about? Designing a great process in order to generate great products.

The Problem With France

Back to where I grew up in Paris, France. I love Paris, and I love Paris for the very same reasons tourists love it: the ambiance, the architecture, the food, the romantic spots, the cafés and the lights. Now, when we talk about Design, we don’t think of Paris or France, unless we refer to glamour, luxury, perfume, fashion and interior design. This is why tourists love visiting France; it’s not about function, it’s about feelings. In fact, France has never developed a philosophy and practice of functional Design, as Germany, the United States, and Japan respectively did with Bauhaus, Product Design and Technological Design. Historically, Arts and Design in France are mostly about how things look and feel, not how they work. In addition, the French language is more appropriate for expressing nuances and variations within interpretations, while English is effective for describing functions. In short, the French mindset is not at all functionally oriented.

Part 3: Tomorrow and Beyond

Social Redesign

France is just one place among many in the process of adapting to this new paradigm. Old cultures, old behaviours, old industries are all struggling to adjust. The entire world continues to evolve under the influence of the Internet. And what will the world look like twenty years from now? Nobody knows for sure. Adaptive Path has brilliantly summarized the issue in its recent book, Subject to Change: Creating Great Products and Services for an Uncertain World.[2] There are few Design firms who see, understand and master the importance of design process. As the web becomes the main stream for corporate and business communication, it becomes clear that Internet designers have an increasing role and prominent positions in helping companies adapt to the new informational space. Under the mundane question asked by our clients “How can I redesign my website?” there is often an underlying concern of “How can I redesign my business model?”

The Power of the UXD

It strikes me every time I read blogs or attend lectures on User Experience, Interaction Design, Information Architecture, or Content Strategy, Design is being redesigned and practically redefined. A worldwide community of designers is working on what is about to become a mature discipline—Digital Design. A design where technology is deeply integrated to create content, objects and services dedicated to users with respect for our natural and social environment. The community of User Experience designers already plays a major role in this redefinition. UX Design brings new ways of conducting research, generating ideas, defining strategy, structuring information, designing and understanding usage, improving production and generating new types of business. The impact of UXD on the web business is simply huge. 2010 is the year for User Experience designers to take power, not by force, but with persuasion, inspiration and style.

“Think Different”[3]

Every other month, I teach some UX Design courses for professionals at Paris’ “Ecole de l’Image” (and by the way, promoting UXD to students is a wonderfully rich experience). Last week, one of my students asked me about clients’ general perception and acceptance of UX Design and whether there was any reluctance in changing methodology. In fact, clients are definitely not the problem. They always welcome the UXD process because they can see it brings clarity and solidity to a project. Resistance to change occurs much more inside the classic communication agencies themselves. Like I said, old cultures, old behaviours. UX Design moves the lines about and creates new spaces to design differently and to think differently. In Fast Company Magazine, Tim Brown, CEO of the innovative design firm IDEO, said that “in order to do a better job of developing, communicating, and pursuing a strategy, you need to learn to think like a designer”[4]. Indeed the fields of application are large; in strategy, business, services, even in politics, UX Design, as a radical change of thinking, can transform the way we see and build our world.

Co-Evolution

In one of his most inspiring lectures at Stanford University[5], Steve Jobs stated that “you cannot connect the dots looking forward; you can only connect them looking backward”. Today, it is very difficult to predict what will be User Experience Design tomorrow, but looking back over the past ten years, we can see that something happened, something that makes a lot of sense; web designers of all kinds have been evolving along with the development of the web. The web changed the way we design projects, the way we work together and even simply the way we communicate with each other. By designing for an evolving world, we learnt how to be flexible in our methods, how to not take anything for granted, to co-evolve with the Internet ecosystem.

About the Author

Matthieu Mingasson is Head of User Experience Design at Ogilvy Interactive in Paris and speaker at the school “Gobelins, Ecole de l’Image”. In the late eighties, he started his career as a graphic designer for Rolling Stone Magazine in Paris and for other mainstream information magazines (Le Nouvel Observateur, Challenges), as he was building his interest and skills for content organization and information design. In the Nineties, he worked as an Art Director at Textuel (/TBWA), designing corporate magazines. In the mid-nineties, he moved from print design to the new practice of Web Design, developing his passion for technical aspects of internet projects.

In the late nineties, he was in charge for several web information architecture project in Europe (France, Greece, Luxembourg, the Netherlands and the UK).

He joined, Ogilvy One in 2007 to create a team dedicated to Information Architecture. He’s presently managing the User Experience Design departement at Ogilvy Interactive in Paris.

Web: www.activeside.net

Public profile: www.linkedin.com/in/mingasson

[1]. Linus Pauling, http://en.wikipedia.org/wiki/Linus_Pauling

[2]. Subject to Change: Creating Great Products and Services for an Uncertain World, Adaptive Path - O’Reilly Media (March 26, 2008)

[3]. “Think Different”: Apple slogan (1997). Interestingly, this slogan was advertised the same year the Internet started to be massively adopted. 1997 is also the year Steve Jobs returned Apple Board as “iCEO”. Not a coincidence.

[4]. Tim Brown: Strategy by Design http://www.fastcompany.com/magazine/95/design-strategy.html

[5]. Steve Jobs: How to live before you die (2005) http://www.ted.com/talks/steve_jobs_how_to_live_before_you_die.html

The Wet Cat

1984: Inventing

I always felt sorry for Beertje’s desperate attempts to make us aware of him being outside in the cold on the window sill. Winters in the Netherlands are cold and wet, and cats are not especially keen on cold and wet. I must have been ten years old and had been pondering on how to solve this problem using the technology at hand.

My Philips EE2050 Electro Experiment Set had taught me how transistors could be used as a switch depending on the number of volts you gave it through the base. The technology is still used today, but now millions of these transistors are packed tightly together in a microchip. The abstract problem I was trying to solve was simple: When Beertje sat outside the window, a change in physical conditions should cause a change in resistance, so that the transistor would switch on an alarm. This would notify us at the other side of the house that our beloved cat was waiting for us to open the window. I remember contemplating a physical switch using Beertje´s weight, heat (he always felt quite warm), noise (meowing) or conduction. The last solution I had found was with a rain sensor, simply putting the ends of two copper wires in a litter tray. Water conducts just enough to lower the resistance from infinite (copper wires not connected) to a little bit. This would make the transistor switch from 0 to 1. It also works through skin, when holding the ends of the two wires in your hands. However, cats are hairy, so that would not work. Hoping that he would pee on the two wires was not a great starting point for a good solution either!

A physical switch using the cat’s weight was a reasonable solution but my Mum did not approve this, as I would have needed to drill a hole in the window’s wooden frame to push the wires through. The whole device needed to be on the inside of the window.

These are moments of frustration for a designer, when constraints seem to kill all the possibilities. These are also the moments that plant a seed in the designer’s mind, waiting for the answer to come. A designer (inventor, engineer, creator) is always looking for answers, but specifically for answers to questions he has asked himself at earlier stages. I believe that this is what makes a creative mind. You have identified a problem, annoyance or something that you would like to change, but cannot find the answer immediately. In fact, the brain puts the problem onto a subconscious track, continuously scanning for clues that might solve the problem. Information that might not seem related to the initial problem is then analyzed in the context of the “parked” problem and when there is a fit, that is the eureka moment. Where others wonder how such an unrelated clue could lead to solving the problem, the designer knows when it makes sense and grabs it with both hands.

My moment of enlightenment came, quite literally, by discovering the existence of the LDR. An LDR is a Light Dependant Resistor. Put simply, it is a resistor that conducts electricity depending on the intensity of light that shines on it. The more light, the lower the resistance. With the problem as defined earlier, understanding the available technology, and with a bit of research in the field, it should not come as a surprise that this was my eureka moment: Cat in window casts shadow on window sill on the other side of the window. Shadow means less light, less light means higher resistance, changing resistance can make transistors switch something on. That something became my electronic bicycle horn, which I connected to my device. It didn’t take long to build the Cat Sensor (always give your ideas catchy and solution-related names so it can be talked about and understood). The electrical circuit consisted of a couple of transistors, resistors, and of course the LDR. Before I soldered the whole thing together, I had tested it for different light intensities, but since it’s hard to make a cat do what you want, I decided to add a variable resistor (similar to the volume control on a radio) to be able to fine tune it at all times. The intensity of light also varies from bright daylight to the light of the outdoor lantern.

I used some transparent plastic to build the housing around the printed circuit board. This way, the LDR could stay safely inside, so my mom would not break it while watering the plants. I remember the LDR cost the equivalent of 2 Euros, probably a week’s pocket money.

From that moment on, every time our furry friend jumped on the window sill, a loud alarm would alert us. The family members took turns to run to the other side of the house to let Beertje in the moment the Cat Sensor sounded. No more wet cat in our house.

When you are ten years old, you do not think about a design process, but looking back now, I can’t help but smile to see that the steps I took then actually followed some sort of structure that is not so far from what I use nowadays to design an application or site:

Problem definition: We don’t hear Beertje meowing when he is sitting outside the window and wants to get in. The poor thing will get hungry, cold and wet.

Requirements and constraints: Must use existing technology, low budget, no drilling holes in the window frame.

Idea phase: Look at all kinds of solutions using heat, conduction, noise, light and weight. It is during this phase that the eureka moment normally occurs; sometimes it comes later when you are already in the next phase, building on the wrong idea. Then you need to go back.

Concept phase: Choosing the best idea and detailing it.

Getting investment partners: I remember I convinced my parents to pay half of the costs for the components, and I made my Dad build the final housing.

Building: make a prototype and test it on the users. I only had one user and I think he liked it. He also happened to be the beneficiary.

I always believe that what you liked most in your youth is what you should be doing as a profession when you grow up. After the enormous success of the Cat Sensor, I decided to become an electrical engineer—that is, until I got my Commodore 64 home computer.

1989: Programming

The Commodore 64 was a home computer with 64 KB of RAM memory. In fact, that was a big lie, because 16 KB was taken by the operating system, so there was only 48 KB left. Either way, it is amazing what you can do with such a limited amount of memory. The notebook computer I am using to write this has almost 22,000 times more RAM, and the simple calculator application I just used for the maths to calculate this needs 5 times as much using Windows XP. I started programming in BASIC, which is a language that is in fact still quite similar to more modern programming languages. Nowadays, when I look over the shoulder of my developer colleagues, I sometimes like to believe I still understand bits of what they are doing. The problem with languages that can easily be understood is that they are slow, because they are converted into machine code at run-time. Compilers can do the conversion upfront, but I believe my Commodore didn’t do that really. So after some months of writing silly applications that could calculate what day your birthday will be in ten years, I started to teach myself ‘assembler’. This wasn’t for sissies; it essentially meant you had to put values (poke) in certain registers in the computer’s memory, only to read them out (peek) later on. Tedious programming, but very fast execution. I needed speed, because I wanted to program my own arcade computer game. The idea was to let the user navigate a UFO in a rocky maze from A to B without touching the sides. Different mazes for different levels were needed. However, since copy and paste did not exist at that time, I decided against building more than three levels and decided to make the levels extremely difficult to play instead. This was to make sure my friends wouldn’t reach the finishing line within five minutes. I found an apt name for the game: “Stress”. So here is how I started the initial design of the game.

First, I created my first ever storyboard by sketching different mazes for the different levels on a piece of paper. Storyboards visually capture the different steps in a user experience and are similar to how film directors sketch key frames of scenes. Second, I designed the behaviour, such as the crash effect or the finishing line celebration visuals. Finally, it all had to be programmed. “Stress” never became a success, as one day after the launch (handing out cassette tapes to my school buddies), my best friend Willy betrayed me by disabling the sprite collision detection via a dirty hack. The UFO now could be flown to the finishing line without having to bother about not touching the sides. This was not going to stop me. I decided to become a computer programmer—until I met Hans.

1991: Studying

Hans was a great windsurfer a couple of years older than I was. I met him on the beach at my windsurf club in Hoek van Holland, a windy town near Rotterdam. He was studying industrial design[1] and was designing three-dimensional products. He was also designing and building his own surfboards. How cool was that? I had been windsurfing since I could walk, but had never given industrial design much thought. In my understanding, design was something for artists, whereas real engineers wrote computer games and built pet-sensing devices. I started to observe products around me and tried to figure out the reasons why they had been designed the way they were. It struck me that many products were not designed very intelligently, and some were even designed downright illogically. Why use a cylindrical door knob on a bathroom door so that wet, slippery hands cannot operate it? Why was it so difficult to program our video recorder? Why did they use such a tiny button for the snooze function on my alarm clock, when the last thing you want to do is search for it when half asleep? After reading the book “The Design of Everyday Things”[2] with many more great examples of dumb design, I was even more convinced that the world was indeed in need of great industrial design.

It did not take long for me to get excited about this engineering domain I had so ignorantly overlooked. I was destined to design fast surfboards, humane alarm clocks and sexy cars. I was going to become an Industrial Design Engineer. The only problem was that I had not told my parents yet about my latest passion. When you are 18, parents are not only your biggest stakeholders, but also your sponsors, and they needed converting. There were only two weeks to go before the first semester started and I was already signed up at university for computer science. I told my parents about my plan and they looked at me as if I was proposing to study ballet. The industrial design curriculum involved drawing, clay modelling and woodwork, activities that my parents associated with unemployment, poverty and free love. They had lived through the sixties and knew the dangers of all that. To be honest, I wasn’t so sure either. My choice was based purely on intuition. For a designer, intuition is neither a luxury nor a distraction; it is a critical skill that needs listening to. I was going to benefit many more times from intuitive choices in my life, although I did not realize it at the time. My parents succumbed, and just before the deadline, I signed up for a master’s degree in industrial design engineering.

Without any preparation and with unrealistic expectations, I made my way to the picturesque town of Delft in the Netherlands, where I started attending the introductory courses at the Technical University. The first week, we got fully submerged in the design process, or merely the lack of it. We were asked to work together in a team and design a barbecue. That did not seem all that difficult, but it turned out to be very much so, especially when you don’t know who you are designing for. Sounds familiar, doesn’t it? Many products are designed without having an end-user in mind. The design staff made us go through this process to realize what it takes to design good products. Because higher secondary education in the Netherlands—and I think everywhere else in the world—was (and still is) strongly focused on analysis, deduction and reproduction of facts, being asked to design from scratch turned out to be much tougher than one could imagine. Yes, design needs analysis and deduction and also a bit of intuition. You also need to listen to users, know about manufacturing and understand marketing and sales. For this, you need to learn a design process where all those aspects are taken into consideration. Following a thorough design process does not guarantee a great final product, but doing without will almost always result in failure. That is also where design and art differ. In art, the aesthetic properties of a product determine the user experience, whereas in product design there are many more dimensions that determine the overall user experience. A well-designed product is not only nice to look at, it is also nice to handle, interact with, understand, learn, teach, sell, buy and recycle. A painting is a thing that you just look at. A sculpture you can look at and touch, but that’s all you can really do with it. A typical industrial product, such as a car, has hundreds of interactions, demands a high cognitive load to operate it, moves, purrs and can even be a lethal weapon. Back then, interaction design did not exist yet as a profession, but this domain adds even more dimensions.

Now imagine combining industrial design with interaction design. This is where things get really complicated, and without a design process you will not succeed. I find it interesting to see that the design process I learnt can be applied to almost every design task. I have designed a wide variety of artefacts, from car dashboards to intranets, from coffee machines to web shops, from accounting software to marketing material, and I always managed to compensate for a lack of domain knowledge by carefully applying a design process. Designing is solving a problem and problem-solving can be trained. A few years ago, the term Design Thinking was coined by IDEO[3], and its definition hits the nail on the head. Designers realized that the way they approach problems is very powerful, that it differs from the way engineers or economists approach a problem. The user experience design profession benefited dramatically by applying design thinking. In recent years, there has been a great improvement in the quality of digital products, because a new generation of designers stood up and dared to approach problems using design methodology.

In the next part of my story, I am going to share my experiences in the world of prototyping, wire-framing and modelling; terms that every user experience designer uses on an almost daily basis. The difference for me though, was that I wasn’t prototyping user experience, I was prototyping three-dimensional products. The truth is, this is not very different from prototyping software or a web site.

1993: Designing With Computers

Going to England for an Erasmus exchange at the University of Wolverhampton for a semester sounded great. I was supposed to sink my teeth into drawing in three dimensions using parametric modelling software[4] and learn how to use it in industrial design. In the first year of industrial design in the Netherlands, we all had to go through the excruciating experience of creating technical drawings by hand, using fine ink pens, rulers, drawing boards, and a lot of patience. This was all about two dimensions, which is obviously very unnatural for designing three-dimensional products. When I discovered Pro/ENGINEER[5], I was hooked. Pro/E was a very advanced piece of software that lets you design and manipulate products in 3D. At that time, Pro/E was superior to its competition, because it allowed parametric modelling, meaning you could build shapes by adding or subtracting other shapes (also known as Boolean operations), and worry about the exact dimensions later. So you would build a cube and then subtract a cylinder, resulting in a cube with a hole in it. Then you could change the dimensions later on. This was Valhalla for the industrial designer, in comparison with hand drawing, or drawing with 2D software such as AutoCAD, where you were forced to decide upfront about dimensions. Pro/E allowed you to play with shapes as if they were clay.

I became skilled at designing in Pro/E, but more importantly, I learned that modelling and prototyping is an exercise that does not need to strive for perfection. A designer needs to visualize ideas as soon as possible, and should be able to change these ideas with ease. If your software does not allow you to change things easily, or even worse, does not let you create what you had in mind, you should return to pen and paper.

Excited about the possibilities of 3D modelling, I took an internship at PTC, the company behind Pro/E. Here, I further specialized in 3D modelling, although most of the projects were in the mechanical engineering scene. Most users modelled in Pro/E to prepare their designs for manufacturing, not to iterate design ideas. I thought this was a waste, but was given the chance to prove its merits for industrial design at Philips Design and Philips Medical Systems. They took me on board to let me do my graduation project. My goal was to design a product using 3D modelling software, from the earliest stage of the design process all the way through the end. It was quite a challenge to convince my design peers of my new approach. It was the era of slick renderings using marker pens, charcoal and paint on special paper, in order to produce an attractive, but unrealistic visualization of the final product. I had never been a star in drawing glossy product renderings myself; perhaps that explained my excitement about 3D modelling software.

1996: Graduating in Design With Computers

At Philips Design, I was given carte blanche to work on a redesign of an MRI neck coil for scanning the lower part of the brain and the upper part of the cervical spine. I distributed my time between the Philips Design studio and the Philips Medical Systems engineering department, as my subject touched various domains, such as electrical engineering, mechanical engineering, software design and industrial design. The end-users were doctors, radiologists and, perhaps most importantly, the patients. My internal clients were my Philips Medical supervisor, my Philips Design supervisor, my university professor and the sales department. Even PTC was still heavily involved, as they were sponsoring me with hardware and software to show off at Philips, to get them to buy the software. It could not get more challenging than this. As a designer, you are always in the middle of opposing forces; a great place to be, but frustrating at times, especially because everyone around you knows more about their topic than you do. A designer seeks to oversee all domains and tries to understand just enough of it all to be able to make design decisions. In my first few months, I talked to engineers who explained algorithms to me, signal-to-noise ratios, radio frequency, composite plastics, data processing and more. I also spent time in hospitals, talking to doctors, nurses and patients—a completely different angle. Then, back at Philips Design, I was discussing form, colour and emotions with my design peers. I spoke to so many stakeholders that at a certain stage my head was spinning. They all wanted something different. These are situations that designers face all the time. I have found that the following rules of thumb are most effective in dealing with your stakeholders:

Do not let anyone intimidate you. You are the designer and you were asked to solve the problem. If someone else in the company were better suited for this, they would have been asked instead. Stay neutral and carefully weigh the opposing forces. Most people think they know what the best solution is, but they don’t, because they don’t see the full picture. Abraham Maslow, once commented “If the only tool you have is a hammer, you will see every problem as a nail”.

You cannot make everyone happy, so don’t bother trying. In fact, you don’t want everyone to be happy, as this means your product is most likely so watered down that it cannot possibly be good. It is better to make 80% of the people very happy, rather than 99% a little bit happy. Very happy users spread the word and buy again, but only slightly happy people don’t care and are as loyal as an alley cat.

Use data as your sword, otherwise you will be defeated on the spot. Unlike many other practices, design is vulnerable, as it is corruptible by subjective opinions. Everyone has something to say about design, but only a few are good designers. Find out what the most important factors are for each stakeholder and get the data that provides improvement over the current or the competitor’s product. I proved that my design had a better signal-to-noise ratio than the current model. That convinced almost all of my stakeholders. Softer attributes such as aesthetics and ergonomics, for which it is harder to get data, can then be discussed in much smaller focused groups where softer arguments are respected.

Record all opinions, decisions and outcomes. It will save you a lot of time, as it will avoid people reopening closed discussions.

The project grew bigger and bigger, but I enjoyed it the whole time. After one year, I was finally able to present my patient-friendly neck coil with a higher signal-to-noise ratio than its predecessor. In addition, I had documented my experiences using CAD software for industrial design. I was happy with the results and so were my stakeholders. I was rewarded with a cum laude degree and a bottle of champagne in a bucket and I think I saw tears in my father’s eyes when Professor Roberts handed me my diploma.

After graduation, I felt like I had fallen into a black hole, a sort of cold turkey. This is an interesting phenomenon, the feeling of having accomplished a mission, and instead of feeling satisfaction, you only feel the lack of challenging work. This has been a recurring feeling during my career, and whenever it occurred, I always wanted to move on in search of new design challenges. That moment came again two years later.

1997: Designing Products With Computers

Although PTC offered me an overpaid job as an application engineer helping to sell the software by demonstrating its value to the customers, I chose to settle for a much smaller monetary reward, working at a small design agency. You should not choose your first job for financial reasons, and after all, I was trained to design, not to sell software to please shareholders. After a year, I moved on to a bigger industrial design agency, N|P|K, the quintessential agency in the Netherlands, famous for its no-frills, functional Dutch design work. The two most important products I worked on that year were a coffee machine and a line of soap, towel and toilet roll dispensers for a large American company. I still see them in many pub and hotel restrooms around the world. One night in a pub, I got a bit tipsy and told a stranger in the restroom that I was part of the design team responsible for the design of the sanitary dispensers he had just used—he gave me a very funny look!

However, doubts blurred my thoughts, even though industrial design is a beautiful profession. The guys that work at Pininfarina designed Ferraris, the girls at Philips Medical designed life-saving devices, Gaudi designed the Sagrada Familia church in Barcelona. And I was designing toilet roll dispensers. Maybe I was on the wrong track in my career? It was time for another change and fate was going to help me find it.

1999: Travelling

My contract at the agency ended unexpectedly and I was free. I bought a backpack and sturdy boots and took off for a year of travelling in Latin America. Travelling is about connecting to people of other cultures, exchanging information and making this world a little smaller, moving towards the Global Village. I found it very refreshing to have this year off and to use other parts of my brain (and body). For most of us, working means sitting in an office chair, staring at a computer screen. Travelling is intellectually less demanding, but mentally much more so. Apart from trying not to get ill, most of the day was spent trying to figure out bus timetables, finding a place to sleep and drinking Cuba Libres with locals and other travellers. Information was hard to obtain. On the Android smart phone that I use nowadays, I can find travel information in ten seconds that took me half a day to figure out in Nicaragua on the road.

This lack of information initially made me feel uncomfortable, but after a while, I started to embrace it. It made me live more in the present, it made me feel more and think less. Did you know that your IQ drops by 20% or so after a few months of backpacking? I got slower as well; if nobody expects you to be fast, why would you want to be fast? Rushing is passed on from one person to another. I am not sure whether I started this adventure to find out what I wanted to be doing or just because it was fun. It should have been the latter, because the last thing you do when you travel is think about the future. This is a myth; travelling is a great way to spend your time, it feeds all the senses and makes you a more tolerant, open-minded and independent person, but the last thing you get out of it is a sense of destiny. You simply are too busy enjoying life to think about anything other than the present. Perhaps that is the best thing travel can give you.

At the end of my trip, I ended up for a couple of months in Quito, Ecuador, and I liked it there so much that I briefly thought about staying. I really enjoyed doing stuff without too much planning, enjoying moments as they came and not worrying too much about the future. There, I just walked over to a friend’s place and we would hang out all day because none of us had planned anything. However, I realized soon enough that trying to find a job in my field was not that easy. Only very few companies employed designers; perhaps back then, design was still a first-world “luxury” profession. Nowadays, this has changed and Luke Wroblewski wrote a great article about the shifting role of design in his blog[6].

Eventually, my money ran out and I noticed I was close to becoming a hippie. Unemployment, poverty and free love; my parents had warned me before. It was time to go home, another black-hole experience, and I needed to find a new challenge fast.

However, I had no intention of going back to industrial design. My trip taught me at least one thing, and that was that the world needed something bigger. The Global Village term was coined—it wasn’t me who had coined it, but I wanted it badly, mainly because I had experienced it firsthand. Together we are strong, cross-border and cross-culture, and above all we did not need more injection-molded plastic products on Pacha Mama, Mother Earth. So I said “yo quito” (Spanish for “I quit”) to my friends in Quito and returned to the Netherlands.

2000: Consulting

I liked the “e” in e-business, however I did not like the “we are the dot in the dot com” that Sun used in their commercials. IBM’s marketing people had invented e-business with the quirky red e. IBM has always been good at marketing obvious technology using fantastic names, and years later, they would introduce On-Demand business. Did I choose this company for their brand identity? Perhaps I did, but once again, trust your intuition and choose what feels right, interesting or just because it makes you feel something. If everyone thought too much about decisions and listened to ‘sensible’ people, we would all end up as accountants at Deloitte.

It was a chilly autumn morning, and I was about to go on a week-long survival tour in Belgium in little groups of young and eager trainees in the IBM Foundation, which was another catchy term that meant traineeship. They made us walk the wrong way in the rain and gave us just too few wooden sticks to make a decent tent, so we had to be inventive, work together and learn about roles, leadership and more of those delights derived from modern management and psychology literature. Of course, we were all clueless, drank too much and became great buddies. This is exactly what I needed, to start from scratch in a new environment and in a new domain with a lot to learn. I can strongly recommend traineeships to young people; they make you learn stuff that will help you for the rest of your career. Really, not everyone wants to become a manager, but learning about working in teams effectively, understanding your strengths and especially weaknesses, and knowing how to convince a customer of your great ideas are fantastic skills. Most companies want their people to be productive from day one, but forget that teaching them the softer skills will pay off in the long run. Later on, they even let me do a Zen meditation course at their expense. Kudos to IBM.

IBM or not, it was clear from day one that I was here to design Global Villages and not to program or sell software. I did not really think it through, but sometimes you just need to be lucky, and I learned that the same month I joined, a new department had come to life; IBM’s Digital Marketing & Interactive Branding or was it Digital Branding & Interactive Marketing? I couldn’t care less about the naming this time, but knew I needed to become part of this team. They had hired a dozen agency web designers. This was the league of Macs, black turtlenecks and flashy trainers. Here, the first distinction between the pure creatives (Mac G4 computers) and the analytical folks (IBM ThinkPad laptops) was made. I hated being tied to a desk, so I stuck with my ThinkPad. Well, to be honest, they probably would not have given me the Mac G4 anyway, as I wasn’t hired as a creative and I didn’t wear black turtleneck jumpers. It is very hard to lose a label and I have always walked on the border between creative and geeky; in either world I was seen as belonging to “the other side”. I have always enjoyed this, as it makes people more open to share, less inclined to compete, and more respectful. I love technology, software, design and psychology, and in all those domains, I can point out lots of people who do a better job than I do. But I love to sit in the middle; after all, to design well you need to be in the middle with an open mind and a humble attitude.

It was to be expected that an in-house design agency in a mammoth such as IBM, which isn’t particularly well known for web design work, was not going to be a success. Money needed to be made and we didn’t. The Macs were sold and the turtlenecks left and the ThinkPads, along with their “usability consultants”, remained. Consulting is lucrative, as customers pay your company for you to do stuff they cannot or do not want to do. In the case of usability, most of our customers did not know how to do it, and in those times, consciousness about the importance of well-designed and usable digital products had grown to a new high. IBM has always been great at delivering back-to-back solutions, and almost all of them, apart from hardware sales, were about applications and sites. IBM was, or maybe even still is, the largest producer of software. In the years to follow, I was dragged into a plethora of different projects, ranging from intranets, webshops and in-house applications to e-learning. Here, I was able once again to confirm that, in the design domain, knowledge is inferior to knowing how to apply a design process and understanding the mechanics of political forces in client projects. For the latter, I could tap into dozens of examples, but I will try instead to sum up the most common political factors that a designer needs to be aware of:

It is not always about creating the best-designed product. Not all customers are alike; some want you to come up with a solution that is not necessarily good for the user but satisfies other requirements. Some projects are not even meant to succeed, and sooner or later, you will be asked to work on one; the trouble is, these projects are not going to do you any good. You will be forced to deliver design work that does not meet your standards, meaning that it will be essentially useless for your portfolio. You will even be held responsible for bad design at a later stage, when the evil forces have disappeared and nobody remembers anymore why decisions were taken. The best thing to do is to stay out of these kinds of projects. If you cannot, then make sure that you bring forward the right solution at least once. It is the responsibility of a designer to always fight for the user’s rights. If that battle cannot be won, make sure both client and project executives know that you have tried to save the project and then get out as soon as possible!

User experience is mentioned in the project plan only in order to tick the box. The symptoms are easy to spot; project executives talk more about “usability” than design or the allotted time frame for the actual design work is very short or placed in the wrong phase of the project. This last symptom is a leftover of the old-school usability practice where usability meant usability testing and it normally was planned after most of the coding was done. Usability testing is as important as it ever was, but as our domain broadened, sufficient time should be reserved in early stages of projects for thorough UX design. If you find yourself in a tick-the-box-for-UX situation, then you are in trouble. Chances are that you really want to do the project, and probably estimate that if you work really hard, you can pull off half-way decent design work. In fact, you cannot really score here because you should not be doing half-way decent design work. You should be doing kick-ass design work. This is the conundrum, if you say no to the project, the final solution will be even worse, because they need you badly. Well dear readers, this is the life of being a user experience consultant. In fact, there is no conundrum, as you should take responsibility and still try to save the project. However, after having tried, get out as soon as possible.

The worst-run companies normally use the most consulting hours. This means you can stretch these assignments, because badly-run companies are normally also bad at managing projects. The public sector is a great example. I was asked to join a vast, prestigious project for the British government somewhere in the North-West of England for a couple of months. These kinds of assignments are always great fun, as large teams of international consultants are flown in to a place far away from home. Normally there are way too many consultants, which makes it easy to relax and enjoy life outside office hours. A bit of summer camp or student life, only now someone is paying for your drinks (the English taxpayer in our case). To cut a long story short, this project had all the symptoms mentioned above. The user experience of our e-learning solution was terrible and I was brought into the project too late. The users were hardly involved and there was no time to take a step back. I tried to convince the people in charge by doing a heuristic evaluation and creating a strategy for a redesign, but the customer had signed off on the first phase already, so it was all too late. So I ended up producing terribly unusable e-learning material in Flash for almost a year. The reason why I did not get out as soon as possible was that we were working in a great team with common goals. Sometimes as a designer you should put your selfish portfolio focus aside and work for the team. I even believe that in the end, although wildly exceeding time and budget, the project was a success for everyone. It is not always about creating the best-designed product, but you should at least try!

After this project, I decided that this had been my last project in business consulting. It was time to move back into serious, pure design work. It was time to sink my teeth into some highly complex, important and geeky products that needed deep thinking. No more web design, no more B2C and no more consulting. Everybody is a web designer, consultant and works in B2C. I was going to design B2B, Java, boxed software.

2004: Designing Software

It was a mystery to me why they had hidden Europe’s biggest IBM Lab in a town called Böblingen, close to Stuttgart in southern Germany, in a region that wasn’t known for its cheap labour. Hang on; did I just say cheap labour? Why would that be important? Well, the funny thing is that nowadays, software design is almost instantaneously associated with cheap labour. We think about Asia or Eastern Europe, where hordes of bright young graduates are eager to work for half the money earned in southern Germany. Employing 1800 people in one of the most expensive regions in Europe sounds insane, but it wasn’t. The Stuttgart region has a very high level of education and its people are hard working, disciplined and inventive. It is no wonder that it is also the home of Mercedes Benz, Porsche, Bosch and Hugo Boss. According to the numbers, the IBM Labs in Böblingen had been the most productive lab worldwide and there were no plans for off-shoring its projects, in spite of the costs. This is an interesting fact, as it clearly shows that costs for certain types of activities are not so important. Software design is something that is extremely complex and it is very hard to get right from the outset, to maintain it in such a way that it stays right, and to be able to extend it, keeping it right during its lifetime. The cost of the initial design and development work is very small compared to what can be won (or lost) during the product lifecycle. Good engineers and designers can determine a company’s success and are therefore worth every Euro. If ten engineers work on a product for a year, and each of them costs 100,000 EUR (including all overheads), it means that you can launch a new piece of software for 1 million EUR. That sounds like an awful lot, but is it really? Software mass production basically means burning a CD or hosting an FTP site—reproduction costs are close to nothing.

It is interesting to compare this with consultancies or most agencies. Knowledge is sold by the hour, so the margin is the gap between the designer’s salary and what is charged to the customer. Here, keeping the salary as low as possible is crucial for the profitability of the company. The most money is made by deploying many lower level consultants and only few higher level ones, as their salaries get closer to or exceed the charged fee.

As a user experience architect, I worked in the IBM DB2[7] Information Management team on a piece of software that monitors the performance of databases and alerts the user when things are not running as they should. Database performance monitoring is crucial in almost all large e-businesses, and the performance of a database has a huge impact on the end-user’s user experience; monitoring and fine tuning its performance is necessary to avoid user dissatisfaction.

The Lab was a great place to work; it was all very different to the environments I had worked in before. Both in geographical and organizational terms, we were working in the sort of isolation that you would not find in many other product organizations. Tucked away in the forests of southern Germany, where squirrels hopped around in the garden, I could tinker all day and ponder the best solution without too much involvement of customers, sales and marketing folks. This may sound unnatural, as user experience is all about involvement of stakeholders and working in cross-departmental teams, but here is where I learned that for great ideas in research and development, you need to withdraw into isolation sometimes. Too much involvement of the external world at times is a distraction. Obviously, I had to reach out to our user base to verify our assumptions, but first and foremost, our ideas were developed internally by our own engineers and designers, and everyone else had to take a back seat. Most enterprises that design and build products have separate R&D organizations for the sole reason of maximizing the productivity of their smartest product people. Dispersing them throughout an organization would only result in mediocre and watered-down products. Having said that, the risk of product development in labs is that the focus can easily become too internal. Building something just because technology allows it should never be a reason to build it. Now this is where user experience people can add tremendous value. With their natural external focus, ability to understand users and fight for the users’ needs, they can help development teams deliver products that not only showcase technical excellence but also delight users and satisfy market needs. We are talking about successful products.

My tenure lasted almost three years and we managed to greatly improve the user experience of our product. The most notable improvement was that we shifted from a report style to an interactive, dashboard style user interface. Users do not need to know when things are going well; they need to know when things go wrong or—perhaps even more important—need to know when things will go wrong in the future, if no measures are taken now. This is about trends that humans cannot detect, but computers can. Going down that route, I conceived an idea that I thought was very obvious, but had not been thought of before. The idea was about how to determine which problems of badly performing databases should be fixed now, later or never, and how to prioritize them. You should be fixing the important problems before they do their damage and leaving irrelevant or non-urgent ones as they are. Sometimes, they may even just go away after a while. Colleagues at IBM Research in India were very excited and offered to elaborate the mathematics behind the idea, and together we eventually turned this idea into a patent. When I read the final patent document, I have to admit that I did not understand much of it anymore. For me, this is a great example of how designers and engineers need each other and how design thinking and scientific thinking can be very powerful when combined.

Life in Stuttgart was very comfortable and so was life in the Lab. This made me decide to leave both, because when things are getting too comfortable, you risk becoming too soft. I also think that as a user experience designer, or designer in general, you need to change focus once in a while. This can be another product, organization, market or medium. I believe that a designer’s speciality is design and nothing else. You can become an expert on a subject if you work for years on the same product or in the same market, but it will be hard to reach the same level of domain expertise of your colleagues in, for example, product management. If you feel that you enjoy having domain expertise and that you want to influence product design on a more strategic level, then a career move from UX to product management is not all that strange. I have seen this a couple of times and UX professionals can become excellent product managers. This is a career path that should be encouraged, because there is a need for product managers with design and user research skills. If you want to stay loyal to the art and science of design, you should not worry too much about domain knowledge, but instead focus on improving your design skills by taking as many different design assignments as you can possibly get. The best user experience designers I know have worked in a plethora of different fields and even jobs. Many were architects, industrial designers or even developers at a certain stage of their career. Working for an agency or consulting firm can also be a great opportunity to sink your teeth into a lot of different assignments.

My last year in Stuttgart was great. I had built up a great circle of friends, learned the local language and enjoyed Sauerkraut, Weisswurst and lazy Sunday afternoons in the beer garden. On top of that, Germany was hosting the football World Cup. People from all over the world came to watch their favourite teams play in our city and we partied like it was 1999. Once again, I was not entirely sure, but something was calling to me for change. The Monday after a leisurely weekend in Prague, I stumbled upon a job ad for a user experience design position in that same city. Was it coincidence or destiny once again? I think it was just me being on the lookout for something new.

2007: Designing for the Web

On New Year’s Day, my girlfriend and I drove with all our belongings in a chock-full car through a snow storm, to the Czech Republic where my new challenge was awaiting me. I had been away from the consumer and from website user experience for too long, so I decided to return. This was also because I had worked nearly three years in a Java client application environment, not known for its bleeding-edge GUI technology. AJAX technology had become mainstream, and I had the feeling I was missing out there. Hence my move to Prague, to work for Monster Worldwide in the newly started product management and design team, on the user experience for European job seekers and employers.

Let me tell you a bit about user experience and its place in the organization. User experience is a relatively new discipline, so many organizations are not sure where to put it on the org chart. I have seen it sitting in product management, marketing, engineering or even in a separate cost centre services team. I believe UX is most effective in a product management team. Product management and UX have a lot in common, as both strive to come up with solutions for existing or emerging needs. The main difference is that product management analyzes the market, the competitors and the opportunities therein, whereas UX analyzes usage and is responsible for the concrete design of the solution. On a timeline, product management is normally at the beginning. Product managers outline a high level solution, sometimes resulting in nothing more than a textual report and reasons why this solution would generate a 150% increase in revenue, or why it would grab global world domination. UX designers take it from there. The high level solution serves as input for their design work. The phasing should not be strict and both roles should be involved in each other’s stages. A UX consultant must be involved in the high level solution outline to make sure the user is represented, and to start sketching solutions as soon as the problem is known. In return, the product manager must be involved in UX design to verify whether the strategic goals are (still) being met. By no means should product management and UX compete or have their own agenda. It does not work when a UX team works on something vague, such as “usability” or “user experience”, as if these were separate projects.

Another good place for UX folks to hang out is the engineering team. Especially for more complex products (mostly applications), this can be a better place than in product management because technical feasibility and design objectives will need to be negotiated continuously, and quick iterations, prototyping and agile development require the UX designer to be close to the engineering team.

I was mainly involved in the redesign of the e-commerce site of Monster Europe. This was as big as a project can get, involving 16 countries, 12 languages, legacy systems, no (real) content management system, non-aligned regional sales strategies for different markets, and a sales force that could earn more by selling offline than online. Plus transatlantic troubles and politics.

This is what I discovered. Many documents are written by analysts and product managers stating the obvious. These documents can take on a life of their own, and without early sketching and scenario writing, they soon become monsters that obstruct any form of creativity. People have the tendency to describe solutions in terms they know. They also tend to reuse existing solutions, for example, by looking at an innovative competitor. It is not hard to understand why many projects fail to deliver what has been hoped for by doing this. Real ground-breaking innovation needs creative thinking—let’s call it design thinking. For this, problems, requirements and solution directions need to be captured in an abstract way. The next step is then to diverge and create as many ideas as possible, and at the end of this stage, the best ideas (in regard to the initial requirements) are then selected to be detailed in the next stage. I have seen too many product definition documents that stated the need for a configuration wizard, or a product catalogue, where essentially, these two things are concrete solutions for the more abstract problems of tailoring a product to a user’s needs and finding the right product. There are other ways to solve these problems.

Normally, when you present a design, you capture the feedback and try to find consensus during the meeting. If there are too many requirements and topics to discuss, it is simply impossible to find consensus on the spot. The project had so many stakeholders and so many conflicting requirements that I chose to make my life easier by designing a requirements management tool to support the decision making. Every week, a day or two before the design review meeting, I sent out the design work with a spreadsheet in which the stakeholders could rate requirements, ideas or features, using a limited number of credits. The three variables were user value, technical ease and business value. This really sped up the decision-making process, because the reasons why certain ideas were chosen or abandoned were now transparent and democratic. I simply eliminated the risk of getting “design by committee” by always applying hypothetical designing. Simply put, the designer creates the initial ideas based on incomplete requirements or information. The committee gives their feedback and the designer iterates that feedback into an improved or totally different design. This way, you keep the committee from designing and you avoid ending up as a spreadsheet manager. Don’t ask what they want, but come up with ideas and ask them what they think of them.

Unfortunately, the European product and design centre was short lived, and after 18 months, most of it was moved back to the United States and the European team was laid off. I found myself forced to look for yet another challenge. The Czech Republic isn’t the best place in the world for user experience work so I looked abroad.

Good old England—Bristol it was this time. I was hired as a contractor to work on the future user experience of Nokia’s music download service for both web and mobile platforms. The design team at Nokia Music is highly creative, and is efficient at working together with product management and engineering. Nokia has a strong track record in producing desirable, usable products and Nokia Music is no exception. I found it a delight that at Nokia, design drives product innovation and the focus is relentlessly on the user and his experience. I had the opportunity to spend a day with the people at IDEO working on ideas for the Nokia Music experience. Their out-of-the-box thinking and way of working are truly refreshing. Everything they do is visualized, and their main deliverables are quick sketches and post-it memos on the wall. At first, I wondered when the “design document” would be delivered, but eventually I realized that their strength is in the early stages. IDEO delivers raw ideas, leaving lengthy document writing to others.

In spite of a great team, an attractive product and interesting design work, I decided I could not stay in Bristol. The rain, the rain, this is England and not Spain. One night in July, after some freezing hours of after-work drinks in the back garden of our local pub, I got back home and a higher power drove me to the career site of my previous employer. I entered the magic keywords User Experience Spain in monster.co.uk and 6 weeks later, I landed in sunny Barcelona.

2009: Starting Up

Not obstructed by any prior knowledge, I made my way into ERP[8] land and started at Openbravo. I had heard the term Enterprise Resource Planning before, through the commercials of a company called SAP. I associated SAP with complex, expensive software that allows consultants in blue suits to overcharge their clients for customizing a standard offering during lengthy assignments, only to do the same thing all over again with the next upgrade. That smelt like customers and users in need, and I felt responsible for saving them from all the evils of ERP. Openbravo was open source, web based and focused on small-to-medium businesses, and the company wanted to avoid becoming yet another ERP monster. Brave as I sound, I have to admit that the location of the company, in sunny Spain, also played an important role in my enthusiasm.

Quite a shock after Monster and Nokia Music, I was back in the geek zone of highly complicated Java business applications. Powerful software and a user experience with lot of room for improvement, this sounded like a great challenge! This, combined with the fact that Openbravo ERP is open source, makes it such an interesting product to work on. I had never worked in open source and quickly learnt that it is heaven for user feedback. In open source development, you work with a community of business partners, end-users and developers and everything you do is shared with the community; user feedback had never been so easy. At the proprietary software companies I had worked for before, obtaining user feedback always required non-disclosure agreements to be signed by the participants, closed doors and secrecy. After all, the competition is always watching! In an open source project, you can just share all your ideas, design work and lines of code with the external world and ask them for feedback. It feels like working in a fish tank, as everything you do is visible.

The biggest difference between applications such as Openbravo ERP and websites is very important for user experience designers to understand. Although many applications nowadays run in a browser, there is still an essential difference between sites and business applications. Sites are visited because users like to visit them, as there is something there that pleases them. Business applications do not offer that choice. Users will use it, whether they like it or not. The company’s management decides to deploy certain software and its users are essentially forced to use it. Many users spend up to 100% of their working day using one business application. The focus of the user experience should therefore be on efficiency, effectiveness, trust and productivity. All these factors are directly linked to usability. You don’t have to tease your users, you should please them!

Openbravo is still a start-up, but has grown quite big already. This is also where The Innovator’s Dilemma becomes relevant. As a company grows bigger and the product more mature, sooner or later the question comes up as to whether you should please existing customers or focus on getting new ones. Especially in the world of ERP software, existing customers are very important because ERP software can easily become software for life, due to its high investment in implementation and customization. We are now at the stage where we realize that you cannot please everyone and that the focus should be on the core features and getting them right. Forget about the rest. Take things out and downsize. Has this not been the determining success factor of many Apple products? During the introduction of iTunes, Steve Jobs was bombarded with questions from the audience asking him whether iTunes had this and that feature. He admitted that most of these features were not there, but he also added that this was all intentional. If they had built in all these features, iTunes would have become unusable. My 1984 Cat Sensor had one on-and-off switch. The light sensor was positioned behind a transparent part of the housing, and all other parts were obscured. This was so my Mum always knew which side to position against the window. Less Is More, Form Follows Function and Mums Without Manuals—keep these three things in mind and our cats won’t get wet.

2010: Contemplating the Future

When I made the switch nine years ago from product design to user experience design, I never expected that our discipline would grow so enormously. But it is not difficult to see why this has happened. Technology evolves at a startling pace, much faster than human beings evolve and has become increasingly complex. Technology has become more and more dominant in our lives and most of the people in more developed countries spend a ridiculous number of hours every day interacting with it. Almost everybody I know interacts with software nearly the entire working day, only to switch to playing with their mobile phone, driving their car or socializing on Facebook at home. All these activities are user experiences, and someone needs to design them. Unless we see a retro trend appearing, moving us back to more slow-living lifestyles with less technology, I can only see technology becoming more and more important in our lives. We, as user experience designers, will play a key role in shaping how people will interact with that technology. We can make people’s lives easier, safer and more enjoyable. This is a responsible job but it is also a privilege. I enjoy what I am doing. Once I read “If you enjoy what you do, you never have to work a day in your life”, and I can fully agree with that.

About the Author

Rob Goris is User Experience Architect at Openbravo (Barcelona, Spain) dedicated to designing a world class open source business application that will improve the quality of life of thousands of users and possibly will also stop global heating. When he is not doing this, he spends his time mostly windsurfing, snowboarding, hiking and playing beach volley ball.

Web: http://openbravouxlab.blogspot.com

Twitter: robbie_g

LinkedIn: http://es.linkedin.com/in/robgoris

[1]. Definition of industrial design according to deNoblet, J., Industrial Design, Paris: A.F.A.A. (1993) is a combination of applied art and applied science, whereby the aesthetics and usability of mass-produced products may be improved for marketability and production. The role of an industrial designer is to create and execute design solutions towards problems of form, usability, user ergonomics, engineering, marketing, brand development and sales.

[2]. Norman, Donald, The Design of Everyday Things (1990)

[3]. Design Thinking according to IDEO: http://www.ideo.com/thinking/approach

[4]. Definition of: parametric modelling according to PC Magazine encyclopaedia: Using the computer to design objects by modelling their components with real-world behaviours and attributes. Typically specialized for either mechanical design or building design, a parametric modeller is aware of the characteristics of components and the interactions between them. It maintains consistent relationships between elements as the model is manipulated. For example, in a parametric building modeller, if the pitch of the roof is changed, the walls automatically follow the revised roof line. A parametric mechanical modeller would ensure that two holes are always one inch apart or that one hole is always offset two inches from the edge or that one element is always half the size of another.

[5]. Pro/ENGINEER is a parametric, integrated 3D CAD/CAM/CAE solution created by Parametric Technology Corporation (PTC)

[6]. “The Shifting Role of Design”, Luke Wroblewski (2006), http://www.lukew.com/ff/entry.asp?415

[7]. DB2 is one of the families of relational database management system (RDBMS) software products within IBM’s broader Information Management Software. http://en.wikipedia.org/wiki/IBM_DB2

[8]. Enterprise resource planning (ERP) is an integrated computer-based system used to manage internal and external resources including tangible assets, financial resources, materials, and human resources. http://en.wikipedia.org/wiki/Enterprise_resource_planning

UX Storytellers

http://uxstorytellers.blogspot.com

Table of Contents

UX Storytellers

Acknowledgments

Foreword

Chapter 1

Learning Information Architecture (By Paul Kahn. Paris, France)

Learning Information Architecture

First Get a Job

Then Get Lost

Listen to the Code Talkers

Listen to Your Fare

About the Author

Sex, Drugs and UX (By Jason Hobbs. Johannesburg, South Africa)

Sex, Drugs and UX

About the Author

All Who Wander Are Not Lost (Marianne Sweeny. Seattle, USA)

All Who Wander Are Not Lost

Hollywood

Introduction to Software

Inside the Borg

Agency Life

Evolution of Search

Search and IA

About the Author

Watchmakers (By Thomas Memmel. Zuerich, Switzerland)

Watchmakers

Schweinfurt

The Usability Drummer

The Usability Enlightenment

Munich—Beer, Pretzels and User-Centred Design

Usability Turbo Boost

Singapore

Who Turned Back the Clock?

Expatriate

Record Deal

Self-winding Automatic Clockwork

About the Author

UX Goes Viral (By Jiri Mzourek. Prague, Czech Republic)

UX Goes Viral

Warning—UX May Be Contagious

Beware Of the Symptoms

How I contracted UX

Starting a Pandemic

Join the Mission?

About the Author

What I Know and Don’t Know (By Sylvie Daumal. Paris, France)

What I Know and Don’t Know

When Digital Was Called Multimedia

Dynamic Brochure-like Internet

Discovering User-Centered Design

Springtime in London

Pioneer IA

European Community and Ambassador

From IA to UX

About the Author

Journey into Information Architecture (By Thom Haller. Washington, USA)

Journey into Information Architecture

An Information Architect

An User’s Advocate

A Teacher

About the Author

Building Arcs with Wall-Hung Urinals (By Jan Jursa. Berlin, Germany)

Building Arcs with Wall-Hung Urinals

Frankfurt With Attitude

Flash

Berlin

Usability

Information Architecture

About the Author

From Consultancy to Teaching (By Olga Revilla. Madrid, Spain)

From Consultancy to Teaching

Courses and More Courses

Jobs and More Jobs

Product Selling

Design

100% UX

Breaking the Fourth Wall For the First Time

So, What Do I Teach Now?

It’s Your Life, It’s Your Decision

Open Your Horizon

You Are a Communicator

Design Is a Profession

About the Author

A Journey from Machine Design to Software Design (By Sameer Chavan. Seoul, South Korea)

A Journey from Machine Design to Software Design

How It Began

Automobiles: Field of Glamour

Adapt Engineering Design For Human Use: Industrial Design!

Designing Bikes in Italy

My First Website

From Industrial- to Interaction Design

User-Centered Design: What’s the Fuss?

Evangelizing Usability

No One Pays For Usability

Everyone Knows Usability

Enterprise Web Applications

Internet—the Age of E-Commerce

HCI Conferences in India

Mobile Design in Seoul

Concluding Notes

About the Author

UX the Long Way Round (By Ken Beatson. Christchurch, New Zealand)

UX the Long Way Round, Ken Beatson

Love at First Sight

Roller Coaster Online

Getting Paid and Everything

Career Choices—Still at Uni

Moving Back “Home”

The Belated “OE”

IA in London

Starting London IA

About the Author

Wine, Women and Song (By James Kalbach. Hamburg, Germany)

Wine, Women and Song

Hello, Deutschland

Searching For an ID

A Bigger Fish to Fry

The Missing Nexus

A Broader Field Vision

About the Author

Chapter 2

Almost Dead on Arrival: a Tale of Police, Danger, and UX Development (By Aaron Marcus. Berkeley, USA)

Almost Dead on Arrival: a Tale of Police, Danger, and UX Development

How We Got Started

Late, But Better Late Than Never

These Were Not Happy Users

So, How Does the Story End?

About the Author

Moving into Non-Linear Iteration and Managing People Who Haven’t Arrived There Yet (By Dave Malouf. Savannah, USA)

Moving into Non-Linear Iteration and Managing People Who Haven’t Arrived There Yet. Dave Malouf

HTML: The Gateway “Drug” to Design

Vizooal: Entering the Design Studio

Fast Forward to 2003

The True Essence of Design

Rewind a Little

Life in the Trenches as a User Experience Manager

Emerging From Darkness, User Experience Success

Even Success Has its Failures to Learn From

About the Author

One Thing, Many Paths (By David St. John. Seattle, USA)

One Thing, Many Paths. David St. John

Of The Book

Deconstructing UIs

Intranet Design

Look Outward

About the Author

Accepting Star Wars at Work (By Henning Brau. Ulm, Germany)

Accepting Star Wars at Work

Parts Lists in the Automotive Industry

Inhouse Usability Engineering

Our User-Centered Design Process

About the Author

A Day at Acme Corp (By Mark Hurst. New York, USA)

A Day at Acme Corp

About the Author

UX Professional Goes Car Shopping (By Timothy Keirnan. Michigan, USA)

UX Professional Goes Car Shopping

Transportation, Lifestyle, and Selection Criteria

MINI Cooper

Website Experience

MINI Dealership Experience 1

UX Takeaways

Honda Civic Si

Website Experience

Civic Si Dealership Experience 1

UX Takeaways

Mazda 3

Website Experience

Test Drive Experience

UX Takeaways

MINI Cooper (Revisited)

Dealership Experience 2

UX Takeaways

The Inevitability of Compromise

In Conclusion: The Miracle of Adapting

About the Author

Design is Problem Solving—In More Ways than One (By Sudhindra V. Murthy. Bangalore, India)

Design is Problem Solving—In More Ways than One

A Quick Intro

At Singapore

In Dubai

Back at Singapore

My Weekend Out

MetroBangalore

Back at the Client’s Offices

Finally ... December 2006

About the Author

I Am Feeling Lucky Strike Today (By Gennady Osipenko. Kiev, Ukraine)

I Am Feeling Lucky Strike Today

Here Comes Evolution

The Genesis of a Community

About the Author

The Stamp (By Cennydd Bowles. Brighton, UK)

The Stamp

About the Author

Cutting Through the Opinions (By Eirik Hafver Rønjum. Oslo, Norway)

Cutting Through the Opinions

Oslo

The Long Neck

A Huge Website

Cutting Through the Opinions

Spring

About the Author

Culture Shock (By James Kelway. Copenhagen, Denmark)

Culture Shock

Welcome to Denmark

Hello Hello

Introducing Fritz Hansen

Shifting Gears and the Configurator

TP’s Design Engineering

New Arrival

Recession Bites and the Site Launches

Cultural Integrity

Design Is Everyday

The English Patient

About the Author

Shaping Spaces (By Andrea Rosenbusch. Zurich, Switzerland)

Shaping Spaces

From Archivist to Information Architect

Digitising Finding Aids

Thinking About Users

First Steps as an Information Architect

What is Information Architecture About?

The Metaphor of Architecture

Information Space

Real Users

Collaborating on Information Architecture

The Need for Co-operation

Obstacles

Creating a Common Cause

About the Author

How to Love and Understand Your Audience by Probing Them (By Chris Khalil. Sydney, Australia)

How to Love and Understand Your Audience by Probing Them

Introduction

An Interesting New Project

Opportunity to Experiment

Enter the ‘Cultural Probe’.

The Problem With Traditional Probes

A New Digital Approach

Lifestreams

The Research

Recruiting

Tips on Creating a Screener

Selecting the Probe Tool

Useful Plugins

Running the Probe

Pre-probe Interview

The Probe Itself

Post Probe Interview

Analysis

Conclusion

About the Author

Using the Right Tool for the Job—Three Methods of Testing the Redesign of Guardian Jobs (By Martin Belam. London, UK)

Using the Right Tool for the Job—Three Methods of Testing the Redesign of Guardian Jobs

Guerrilla User Testing

Online Taxonomy Research

Progressing the Information Architecture

Lab-User Testing With Madgex

Visual Design Process

Lessons Learnt

About the Author

How to Avoid Wasting Millions on Your Product Development (By Jay Eskenazi. Seattle, USA)

How to Avoid Wasting Millions on Your Product Development

Drama in the Usability Lab

What Is the Moral Of the Story?

About the Author

Style of Change (By Clemens Lutsch. Unterschleißheim, Germany)

Style of Change

About the Author

Escaping the Waterfall (By Harri Kiljander. Helsinki, Finland)

Escaping the Waterfall

Heyday

Design Delivery in the Early Days

Agile Software Development

The Good, the Bad and the Waterfall

UX Design Manifesto

The Best of Both Worlds

Epilogue

About the Author

UX Then and Now (By Deborah J. Mayhew. West Tisbury, USA)

UX Then and Now

College—1969-1974

Master’s Degree—1974-1977

Doctoral Degree and First Job—1977-1981

UX Career, Corporate Jobs—1981-1984

UX Career, Academia—1984-1986

UX Career, Consulting—1986-Present

Reflections

About the Author

The Story is the Thing (By Andrew Hinton, Charlotte, USA)

The Story is the Thing

An Origin Story

An Architecture Story

A Survival Story

The Moral of the Story

About the Author

Chapter 3

Three Stories (By Daniel Szuc, Hong Kong, China)

Three Stories

One

Two

Three

About the Author

Hundred and Ten (By Andrea Resmini, Jönköping, Sweden)

Hundred and Ten

One

Two

Three

Four

Five

Six

Seven

Eight

Nine

Ten

About the Author

Technical Capability is Only Half the Story (By Abhay Rautela, New Delhi, India)

Technical Capability is Only Half the Story

A Story

Takeaway

Example 1—The Key Keepers

Takeaway

Example 2—Stakeholder Goals Over User Goals

Takeaway

About the Author

Broken Soft Drink Machines (By Lennart Nacke, Saskatchewan, Canada)

Broken Soft Drink Machines

Scientists vs. Rock Stars

The Joy of Interaction

The Quest For a Drink

Strolling Around

The Soft Drink Machine

About the Author

The Limitations of Good Intentions (By Robert Skrobe, Las Colinas, USA)

The Limitations of Good Intentions

Epilogue

About the Author

The Fable of the User-Centred Designer (By David Travis, London, UK)

The Fable of the User-Centred Designer

Preface

The Search

The User-Centred Designer

The First Secret of the User-Centred Designer

The Second Secret of the User-Centred Designer

The Third Secret of the User-Centred Designer

The User-Centred Designer Explains

The New User-Centred Designer

About the Author

Anything Can Be Interactive Media If You Know What You Are Doing

Two

Three

Four

Five

About the Author

A Woman in UX: I’ve Come a Long Way, Baby (By Colleen Jones, Atlanta, USA)

A Woman in UX: I’ve Come a Long Way, Baby

Machismo

How to Deal

Women Who Hold Women Back, Way Back

How to Deal

Negotiating

How to Deal

We Have a Long Way to Go

Looking Top-Down: More Women UX Heroes and Speakers

Looking Bottom-Up: Day-to-Day Accountability

About the Author

Out of Focus (By Simon Griffin, London, UK)

Out of Focus

Focused on Failure

Focus Pocus

And Now for a Confession …

About the Author

Sources and References

Seeing Things the Way They Are (By Patrick Kennedy, Sydney, Australia)

Seeing Things the Way They Are

The Student

The Small Business Owner

The Parent

The Common Thread

About the Author

Coevolution (By Matthieu Mingasson, Paris, France)

Coevolution

Part 1: Memories from the Past

The Press: My Big Fat Family

Graphic Design? Sorry to Say, But We Broke Up

Tonight, the Web Saved My Life

Part 2: Here and Now

Creativity Is Not About Me.

The Standard Revolution

The Product Is the Process

The Problem With France

Part 3: Tomorrow and Beyond

Social Redesign

The Power of the UXD

“Think Different”[3]

Co-Evolution

About the Author

The Wet Cat (By Rob Goris, Barcelona, Spain)

The Wet Cat

1984: Inventing

1989: Programming

1991: Studying

1993: Designing With Computers

1996: Graduating in Design With Computers

1997: Designing Products With Computers

1999: Travelling

2000: Consulting

2004: Designing Software

2007: Designing for the Web

2009: Starting Up

2010: Contemplating the Future

About the Author

UX Storytellers