Case Study: Sony Trans Com s Pssport

Case Study: Sony Trans Com's P@ssport

In 1997, Sony Trans Com approached us with a remarkable design problem. Sony Trans Com is Sony Corporation's Irvine, California, division, responsible for the design and manufacture of in-flight entertainment (IFE) systems. In-flight entertainment movies, TV shows, and video games in commercial aircraft is a large and lucrative business. Sony Trans Com had developed a new generation of technology that brought a new level of capability to airline passengers. The most impressive capability of the new system, called P@ssport, was true video-on-demand (VOD). VOD lets Tricia in seat 23A begin watching When Harry Met Sally 10 minutes after takeoff, and it lets Anna in seat 16C start the same movie 45 minutes later and either passenger can pause or rewind the show without affecting the other.

P@ssport pushed the envelope of IFE well beyond the current technical state of the art. Each seat back contained a video screen and a Pentium computer running Windows 95. In the front of the plane was a powerful array of computers with copious memory for content. A fiber-optic cable connected each seat to the array, with connector boxes placed every few rows throughout the plane, making the system blindingly fast and breathtakingly powerful.

Sony had worked on this system for months before it asked us to help design the interaction. Although the engineers were making good progress, their designers were at an impasse. Just about anybody could occupy an airline seat, so they were trying to accommodate everyone from the total computer novice to the computer expert. They had no idea how to please all those constituencies. Neither did we, but we had our powerful design techniques, including personas, and were confident that we could solve the problem.

The Conventional Solution

Sony Trans Com had already designed and built a prototype of the P@ssport system with a conventional interface. It was very consistent with the program's internal structure that is, it was very implementation model. Basically, it consisted of a deep hierarchical tree of screens through which the user had to navigate, making decisions at each screen. The evident shortcomings of this prototype are what prompted Sony to approach me.

Each screen represented another layer in the hierarchy, and it required six of them to examine each movie selection.

It was a classic example of what I call uninformed consent. At each step, the user is required to make a choice, the scope and consequences of which are unknown. At the first screen the user must choose an entertainment type: music, movies, games, shopping, and so on. Selecting "Video" makes all the other choices disappear, and the next screen demands that the user choose the category of film. The screens keep coming until, at the sixth level down, the user can see a brief preview of the movie and then choose to watch it or not. If she decides to pass, it's six clicks and six screens back up to the top, and then six clicks back down to view the next one. Whew!

Because P@ssport runs on a screen in each seat back, every user is within arm's length of the screen. It was instantly obvious that a touch screen was a great, natural solution, rather than using a handheld remote controller. But Sony rejected the idea anyway. Sony realized that with six levels down and six levels up for each selection it would take several dozen taps for the typical user to select entertainment. It realized that the person sitting in front would be enraged by all the tapping on the back of his or her head. In a classic example of what Po Bronson means when he says engineers will keep fixing what's not broken until it is broken, Sony discarded the touch-screen idea and reverted to a handheld controller tied to the seat with a short wire. It threw the baby out with the bathwater. The engineers regretted the decision but saw it as inevitable in light of their schedule constraints.

The six-screen interface was a classic example of implementation-model design, accurately reflecting the internal choices of the software. Each decision screen offered up very little context or supporting information, so the user never felt oriented, which made navigation a big problem. Each time the user drilled down into another layer, she lost the current context. After she committed to "Video" she was no longer able to select or even see the "Games" option. At each step of the way, the program was ignorant of the bigger picture, so it kept the user similarly ignorant. The user had to choose "Video" without knowing which or how many movies were available. She then had to choose a single category of movie, again without knowing what those categories meant. Is True Lies an adventure, a romance, or a comedy? When she is finally shown movie titles, she is bereft of information. Hmmm, Eraser, wasn't that an art film about a mild-mannered schoolteacher?

But even while still in the prototype stage, the interface had beautiful 3D graphics, very artistic icons, and a map-and-globe metaphoric theme all the trappings of a good interface without the substance. It's what we call "painting the corpse."

Personas

As always, our design process began with a thorough investigation phase, consisting mostly of interviews, beginning inside Sony. We listened to most of the people working on the product, including the project manager, the development manager, a couple of the engineers, the product marketing manager, and the content manager. These interviews gave us a good idea of what Sony Trans Com wanted to accomplish with the product. It also gave us some historical perspective on past IFE business and technology. Armed with this knowledge, we shifted our interviewing process to the field. We listened to lots of airline personnel, particularly flight attendants from several airlines.

During the interview process, our design team kept inventing new personas. Every time a flight attendant would tell us a new story, we'd add another persona, until we had about 30. The more we listened, the more we learned, and eventually the similarities among the personas became apparent. As we found personas with common goals, we could collapse them into one. Eventually we narrowed the persona population down to 10; four passengers and six airline employees. As you might imagine, the airline employees with formally described jobs and responsibilities were pretty easy to understand and design for. The tough nut was the passenger persona. Each of the four passenger personas was an archetype in its own way, representing a broad segment of users, but you can't design an interface for four personas. You have to find the one common denominator. Here are the final four:

Chuck Burgermeister, business traveler. A 100,000-mile-club member who flew somewhere practically every week. Chuck's vast experience with flying meant that he had little tolerance for complex, time-consuming interfaces, or interfaces that condescend to novices.

Ethan Scott, 9-year-old boy. He was travelling unescorted for the first time. Ethan wanted to play games, games, and more games.

Marie Dubois, bilingual business traveler. English was her second language. She liked to browse the shopping, as well as the entertainment selections.

Clevis McCloud, crotchety septuagenarian. An aging but still spry Texan, slightly embarrassed about the touch of arthritis in his hands. He was the only one of the four passenger personas who didn't own a computer or know how to use one.

Passengers	Odyssey Airlines Crew
Clevis McCloud Age: 65, World Odyssey Class	Brent Covington Age: 37, Purser
Marie Dubois Age: 31, Odyssey Club Class	Amanda Kent Age: 28, Flight attendant
Chuck Burgermeister Age: 54, Odyssey Gold Class	Jean-Paul Duroc Age: 33, Interpreter
Ethan Scott Age: 9, World Odyssey Class	Molly Springer Age: 41, Content renewal specialist
	Mel "Hoppy" Hopper Age: 51, Mechanic
	James A. Tattersall Age: 47, Pilot

Our interface had to satisfy Chuck, Ethan, Marie, and Clevis while not making any one of them unhappy. But that didn't mean that we had to make all four of them exceptionally happy. Ethan knows that wanting to play games, games, games is something special, so he doesn't mind pressing an extra few buttons to obtain exactly what he wants, as long as he can obtain it. Chuck knows that his vast experience has earned him some shortcuts, but he is willing to put a little extra effort into learning and remembering those special commands.

Clevis turned out to be our common denominator. Clevis didn't have or want a computer. His motto was, "You can't teach an old dog new tricks." He wasn't stupid or lazy, just not an apologist for the antics of high technology. We knew that if we put a caption bar and close box on the screen, we would instantly lose Clevis. This meant that all computer-like interfaces were out of the question. We also knew that with his arthritis, no complex manipulation would be acceptable. He should be able to operate the system with the ball of his hand.

Any solution that focused on Chuck, Marie, or Ethan would be unacceptable to Clevis. Clevis would be scared and confused by Chuck's shortcuts and Marie's language-selection options. Ethan's twitch games would just get in Clevis's way. Yet a solution that made Clevis, the crotchety old Luddite, happy would be perfectly acceptable to Chuck, Ethan, and Marie, as long as their special needs were accommodated somewhere in the interface.

Chuck and Marie were old hands at flying, so they could find their way around any system, as long as it didn't involve a lot of time-consuming training screens for new users. We knew that if we made the system very simple and visual, it wouldn't involve a lot of interaction overhead, and Chuck and Marie wouldn't be offended. Ethan was easier, because we knew that he would quickly and aggressively explore the system to find out where everything was. As long as his games weren't hidden away somewhere, he'd be happy.

Throughout the entire design project, Clevis was our touchstone. His image became our battle standard. We knew that to make Clevis happy would mean that we would make any and every airplane customer happy. He was our primary persona, and we designed the system for him and him alone.

Designing for Clevis

Clevis had no experience with computers and no patience for the typical attitude of delayed gratification that most programs have. The solution to Clevis's navigation problem was simple: He could not and would not "navigate," so there could be only one screen. The solution to Clevis's reluctance to explore the interface meant that the product had to be very generous with information. We were parsimonious with choices but copious with information.

We turned the screen into a horizontally scrolling panoply of movie posters and album covers. We created a large, rotating knob which we call a "data wheel" that Clevis could spin like a station selector on a radio. This was an actual knob on the bezel of the screen, not an image of a knob drawn in pixels. As Clevis spins the data wheel, the posters scroll smoothly by, moving right if the knob is turned clockwise and left if it's turned counterclockwise.

Clevis views the posters going by, like strolling down Broadway peering into store windows. He never has to choose or even think about what category a movie is in. Because there was no tree of choices to traverse, we reinstated the touch screen without requiring woodpecker-like tapping. When Clevis sees a movie poster that interests him, he taps it once and immediately sees and hears a brief preview, along with written reviews, cast, crew, and pricing information. Clevis can then tap to watch the movie or tap to resume his leisurely stroll down Movie Street.

The scrolling movie posters are arranged in a manner we call a monocline grouping a single layer of information organized into groups. We often replace interface hierarchies with them. The top of your desk is likely organized in a monocline grouping, as are your bookshelves and your bedroom drawers. People, including Clevis, Marie, Ethan, and Chuck, very quickly and easily grasp monocline groupings. Monocline grouping changes the "category" of movie from a necessary choice that must be made in advance into a helpful attribute. Clevis can peruse movie posters and see what category any given movie belongs to without committing to it. It also neatly solves the problem of selecting which category something is in. The movie True Lies, for example, is an action film, a star vehicle, an adventure, an effects showcase, a romance, and a comedy. A hierarchy would force it into just one of those categories, but in a monocline grouping, it can easily have all of them as attributes.

After Clevis scrolls through the movie posters, the images seamlessly change, first to album covers and then to game posters. There are few enough selections that Clevis can merely spin the knob and bring everything into view. The knob is large enough, and its motion coarse enough, that even Clevis, with his large, hard, oil-field hands with their touch of arthritis can still rotate it with ease. A navigation bar across the bottom of the screen informs Clevis that there are several broad categories of entertainment, and a small indicator on the bar moves to point to his place in the spectrum of choices.

The Sony programmers fell into the three-number trap of 0, 1, and infinity. The P@ssport system can handle, in practical terms, about three dozen movies. From a programmer's point of view, 36 being greater than either 0 or 1 is the same as infinity, and the idea of presenting an infinity of movies seemed problematic, so they divided them up into categories. But Clevis enjoys scrolling through the three dozen choices. Even if there were a few hundred movies, he'd still enjoy the leisurely browsing, remembering movies he had seen and anticipating seeing those he hadn't.

A lot of the value of the solution was in the posters, which convey significant information about each movie: the stars, the plot, the attitude. The engineers saw this but were concerned that offering up movie posters would create extra work for the content providers. When we broached the idea to some movie vendors, they reacted in just the opposite way. They were ecstatic at having the opportunity to get their posters into the interface. After all, they had spent hundreds of thousands of dollars to have experts produce a poster that conveyed, most informatively and concisely, as much information as possible about a film and appealed to the broadest audience. Why not put that to use on the airplane? They considered it a great new opportunity to produce bitmaps for the product.

Although we designed the passenger interface for our one primary passenger persona, we made certain to provide for the needs of the secondary passenger personas. Chuck Burgermeister, the frequent flyer, will want some shortcuts, and those are built into the interface so that Clevis won't even notice them. If Chuck wants to move between categories of entertainment more quickly than the data wheel allows, all he has to do is touch the navigation bar at the bottom of the screen. The program immediately jump-scrolls to that part of the monocline grouping without forcing Chuck to scroll there. Clevis never even needs to know about this ever-present idiom, yet it is very easy to discover and learn, and more-experienced travelers like Chuck and Marie will quickly pick up the trick, either from their own exploring or from watching others.

Unlike images on a screen, physical knobs and controls invite manipulation. When Clevis first sees the data wheel, he can easily intuit from its shape and orientation how to work it. Although Clevis cannot intuit its behavior, all it takes is a single, small turning, and its behavior and effects are instantly clear because an equal motion of the movie posters on the screen instantly echoes any motion of the wheel. More probably, Clevis will see some other passenger spin the wheel and see the image scroll in direct proportion. The one-to-one relationship between wheel and screen is instantly understood, and Clevis has learned how to use the system in an instant.

I've only described the interface we designed for Clevis McCloud, the passenger. We also designed two other large interfaces, one each for the other two primary personas: Amanda Kent, the flight attendant, and Mel "Hoppy" Hopper, the mechanic. Their goals are quite different from Clevis's.

After safety, Amanda must focus on ensuring that each passenger has the best experience possible. Her interface must provide control over all in-flight operations. For example, if Chuck in seat 24C wants to move because Clevis in 24B has fallen asleep and is snoring loudly, Amanda must be able to transfer Chuck's account and his half-viewed movie to 19D, the empty seat that he moves to.

Hoppy's main requirement is to assess rapidly the state of the system. He determines what is malfunctioning, how serious it is, and what he can do to fix it.

Both Amanda and Hoppy use the same screen at the flight attendant's station, but their interfaces are dramatically different because their goals are different.

If you want to design software-based products that make people happy, you have to know who those people are with some precision. That is the role that personas play. The next step is designing the product to be as powerful as possible, and for that, you need to know more about the user's goals.