The User Experience of Airplanes

With Airbus unveiling its Titanic-esque A380 today, I wanted to note that I think this is probably the exactly wrong direction for the airlines to head. While other industries are looking for ways to make their businesses more personalized and designed for individuals, monster planes like this one dehumanize us further, cramming 555 people onto one cramped space.

Sure, they claim that some of the plane’s extra space could be used for stores, nurseries, and other sorts of recreational spaces, the makers also note that

how the plane’s extra space is used will be left up to airlines, whose A380 cabin designs have remained closely guarded. In the future, low-cost carriers could operate the A380 with a single economy-class configuration accommodating as many as 800 passengers.

Gee, how far in the future do you think that will be?

Airports like London’s Heathrow are preparing for the new superjumbos by installing double-decker passenger ramps and enlarged baggage conveyers. But…but…did anyone–a designer–think these things through? The experience of airplane travel and of airports in general is currently terrible. Getting on and off planes is particularly odious. It’s going to be great when 800 people try to get in and out through two small doors. How long will it take to load and unload not only people but also baggage? All I can envision are more missed connections, more waiting, and less personalized service.

In short, these superjumbos are built for the airlines, not for their customers. Airlines should have learned from their first-class service (and if they haven’t, they should learn from Apple or Starbucks) that people will pay more for a better experience. Virgin gets this, I think, but every other airline is intent on playing a losing game with bargain-basement outfits like Southwest. There is another way: distinguish yourself with your experience design. Make the experience user-centric. One of the many beleaguered airlines should take note and hire a designer. Or ten.

Designing for Multitasking

I’m a big fan of having something happening in the background while I’m focused on something else. Like having the tea kettle on while I unload the dishwasher. Even better is doing two things at once, one of which I might only vaguely be aware of. Like when I clean up my desk (and thus remove stuff from around the wireless antenna) and in doing so improve my wireless signal. We don’t design for this enough. We’re used to focusing on the task at hand. Perhaps overly focused.

We’ve been designing the equivalent of digital hammers–really nice hammers–that do the task at hand (hammering digital nails) but not much else. They don’t recognize us or adapt to us at all, they just do the task when they could be multitasking: collecting data about how it’s being used and by whom, adjusting itself to make it more personal and more useful. For most digital things, there’s no sense of history and this is something that can be easily gathered. If every time I visit a web site, I go to the same page, chances are, I want to go to that page and the site or the browser should somehow acknowledge that, either by simply taking me there or in some way making it easier for me to get there.

Computers and other digital devices register (and often record) our behaviors like nothing else ever has, except perhaps for royal manservants. And yet, for the most part, they are dumb to the use of this data. Sure, the occasional site welcomes me back, but this is pretty rudimentary. Amazon got this right back in 1996, and despite its current cluttered pages, still gets some things right, like showing me where I’ve been recently. A couple of years ago, BBCi did that brilliant thing where as you returned to the site repeatedly, you “made a path” through the site.

An important point to make is that the onus wasn’t on the user to do these things; the technology was what was smart and remembered. Both of these sites went the extra mile and did something more with the input they were getting in addition to just completing the task. They made completing the task in the future better, and that’s something worth designing.

Design on 34th Street

My favorite holiday movie of all time is Miracle on 34th Street. If you haven’t seen it, stop reading this and do so. It’s a Christmas movie that’s got some great performances, is light on the treacle and very smart. What’s smart about it is that it shows why people, businesses, and governments do the right thing: because it’s good for them. Mr. Macy starts encouraging people to go to other stores to find exactly what they want because it’ll improve his store’s sales. As does his rival Mr. Gimble. The judge rules there is a Santa Claus because otherwise his re-election chances are nil. And, of course, mother and daughter realists Doris and Susan learn to believe in the spirit of Christmas, bringing some magic in their lives.

Miracle demonstrates something designers should remember when selling their services: it’s not enough to discuss the goodness of something (like design). It has to make something better, affect it in a positive way. It has to be personal. Few organizations do things because they want to; they do things because they have to, because it would be bad for them to do otherwise.

Designers get too bogged down in talking about process and deliverables and the other minutia of the trade. With my wireframe fetish, I’m as guilty as anyone of this. What we need to focus on is the effect of design on the organization. The results, in other words. Thankfully, we’ve got some examples now: Apple, Samsung, Nissan, and OXO to name a few.

And, lest we forget, like the holidays, design is also about the intangibles: joy and happiness and especially, delight. What we do and the things we create should delight. Design should be about that little something extra: the way a well-crafted product fits in the hand, the beauty of the correct response to an action, the pleasure of use. It’s not only about being usable and useful. In the words of Miracle‘s Fred Gailey, “…don’t overlook those lovely intangibles. You’ll discover those are the only things that are worthwhile.”

Happy Holidays, everyone.

Designing a Design Vision

One of my classmates was just asked in a job interview what his design vision was. It’s a rather odd question, but strangely enough, one I’ve been asked before as well. Apparently, we designers are supposed to have vision. And since I have several interviews coming up myself, I should probably design one for myself in case I’m asked about mine.

Descending as I do from plumbers, factory workers, railroad men, coal miners, and potato farmers, I’m a fairly practical sort, so talking about vision seems a little quaint. I don’t have no visions, guv’nah. I just do the work! I’m much more comfortable talking about the work and the process of design than I am about a design vision. Visions are ephemeral, work is tangible. And while I have my thoughts on what Interaction Design with a big I and a big D is and should be about, I’m not sure that constitutes a vision. A vision implies a picture of the end-state, and I’m too much of fan of chaos theory and design to be certain of those.

To me, a vision also implies bringing a lot of yourself into products, imposing your “vision” onto them. And while I certainly have an ego, I don’t have a fixed set of things that I think every product should be. Each product should arise from its circumstances. In fact, I suppose that could be my design vision: design is about being appropriate. Creating the appropriate thing for the appropriate time and for the appropriate people.

Few of the things I’ve designed work, feel, or look the same. Although like every designer, I have my bag of tricks, I don’t have much of a personal design style that I impose on my projects. I feel like that’s not, erm, appropriate. The result of the design process should be products whose characteristics have sprung up organically from the research, examined and molded by the expertise of the designer.

Now certainly, I think some of my personality is going to influence the products I create (as I’ve written about before). And I don’t think this is a bad thing. In fact, it’s probably desirable. To paraphrase what Kevin Lynch said about cities, we don’t want to make things that are alien to us. But we don’t make things that are inappropriate (unless they are deliberately, disruptively so–sometimes the most appropriate thing is the least appropriate) just to fit a designer’s vision. That’s not ego, that’s hubris. And while that can get you far, it can also cause some hellish things and events to be designed. Vision can be a dangerous thing.

So I’m going to stick with this appropriate thing for a while. It’s a modest vision for individual products, but broadly a very powerful one, I think. If every tool, every experience, was appropriate for you, perhaps especially for you, the whole system of the world would be less frustrating, less cold, and less cruel.

Help Where It’s Needed

The pilot light of my boiler keeps blowing out, often at the most inopportune times. Like in the middle of the night. Since I live in a city where the temperature is currently in the 30s and 40s F, I’ve occasionally found myself in a very cold house.

Lighting the pilot light is a fairly simple procedure of about five steps. However, if, like me, you’ve seldom done this and are confronted with this massive metal box filled with gas, hot water, and electricity in a dark and cold basement, it can be an intimidating thing. Even for the son (and grandson) of a plumber like yours truly. But there, on the side of the boiler, right above where the pilot light and the ignition are: instructions. Clear, single line instructions on how to light the pilot light, with even an arrow pointing to where to stick the match. Thanks to these instructions, it can be done even in the dark.

How many products do we use that you can say such a thing about? Usually the documentation is in its own (easily-lost) booklet or an owner’s manual, or tucked away on its own web page somewhere. That is, far away from where you are when you need it the most. I’d love a car with some diagrams and basic instructions printed on the underside of the hood. Or an application with some really fantastic help attached right to the pieces of functionality.

Yes, I know we’re supposed to build products that don’t need help files, and while that is a great goal, it’s sometimes unrealistic, especially for things that are tricky but happen infrequently. And sometimes what is simple for one user (obviously a heating guy wouldn’t need the instructions to light a pilot light), isn’t for another (me). We should just be mindful of when and where we provide help. We don’t want to be Clippy, but we also don’t want to be that stereo manual that can never be found when we want to add a new component either.

Follow the Money…then Destroy Them Too

Comment spam has gotten out of control here at O Danny Boy, so I’ve disabled most comments except on main pages. Please send me email if you want to comment on posts until I can figure out another solution.

But here’s another solution (in addition to this one) to the spam problem: we typically try to prosecute or disable the spammers themselves. Why not implement the Bush doctrine of destroying those that harbor and fund evildoers? Go after the online casinos, the peddlers of online drugs and pictures of Hot Asian Girls directly. Spam the hell out of them. Fine them. Hack the living shit out of them. Make them stop. They abuse the common good, which, more than servers, routers, and clients, is what the internet really runs on.

Role-Directed Design

One of the reasons designers do things like personas is to get into the head of the people they’re designing for, to understand their goals. But as Marshall McLuhan told us 40 ago, people are focused on roles, not goals. And yet there’s almost nothing about role-directed design, everything is about goal-directed design.

Which is not to say that GDD is faulty or wrong. Indeed, it’s very useful in that it lets designers not get bogged down in the minutia of tasks, as we are wont to do. But GDD is problematic in that goals, especially long-term, big-picture goals, are difficult to determine and easy to get wrong. Indeed, some have moved away from the term “goal”, instead focusing on the more tangible “intent.” What does the user intend to do, not what is the user’s goal (which might be very broad–too broad for use inside a particular project).

Maybe it would be good to start including some role information into our personas. Asking people not what their job titles are but what their role is, in an organization, community, or even household. And what role they’d eventually like to have. Since roles will likely have a cluster of tasks surrounding them (“I take the product specifications to the engineers”), the gap between the role people currently have and the role they want could be fertile ground for interaction designers.

This might be semantics, but could also be another means of design research.

Rhythm in Interaction Design

Ever do a repetitive action involving a keyboard and more than two keys? I just did while programming something. And while it’s nice to say we should just find ways to automate repetitive tasks, sometimes that’s undesirable or unworkable. Think of where gaming would be if you didn’t press buttons over and over, jumping over barrels or shooting at aliens.

In a repetitive situation, it’s easy to make mistakes unless you get into a rhythm, a pattern of doing it. When you find yourself designing something that out of necessity needs to be repetitive, try it yourself and see if you can fall into a rhythm of doing it. Click on the key sequences in a pattern for a few minutes. If you can’t find a comfortable rhythm, your users probably won’t be able to either. Thus, their task will be error prone and you need to redesign.