Millions of us use these annoying robo-responses. Why? Because email is the primary communication channel for business, and because we want to appear attentive to customers and colleagues. We figure that it's better to hackily and immediately "respond" than to leave important people hanging. The makers of PIM tools (Outlook, IBM Notes, Entourage) obviously don't care why we use auto-replies; if they did care, we'd have tools that actually support what we want to do.

Let's end this little charade

Let's say that someone wants to send me email. (It happens from time to time).

Once the sender's PIM tool recognizes who I am, it could quickly ping the address.

Let's pretend at this point that I have told my PIM tool that I will be out of the office. This is immediately reflected in the sender's tool.

That's not good enough, though, because the sender needs to know that there is some kind of recourse. What if the tool could politely indicate where the message was going?

Even better, what if I could create a special VIP list who would immediately be forwarded to me?

Google Wave may make this argument irrelevant over the next few months, but until then, I offer the above, inspired in parts by Facebook, the real-time elements of the Google Wave demo, and a conversation with Jared Goralnick. Jared's service, AwayFind, provides a nice way to get around Outlook's blunt, siloed approach to business communication. Check it out.

I was recently involved in a project that involved the creation of a "status economy" on the web, i.e. a system in which businesses reward loyal users with stuff — a representation of increased status, better service, cash, etc. The parallel in the real world is the loyalty program, but the word "loyalty" seemed to imply a sort of exclusivity that is inconsistent with fluid and flexible world of web commerce and relationships. The web already has a variety of ways of displaying status, and the word "economy" more appropriately spoke to the web's transactional nature.

On Wednesday, we celebrated the release of Designing for the Digital Age, a comprehensive how-to for getting great products built. The release party was hosted by Autodesk in their amazing new Gallery at One Market in San Francisco. The Gallery is filled with cool toys and overlooks the Bay, so it was a pretty ideal setting in which to host a couple hundred of our closest interaction design friends. Big thanks to our friends at Autodesk for a memorable night!

Download the chapter here.
[PDF, 1.4MB, requires Acrobat 7 or higher]

Kim Goodwin delivered the closing keynote at interaction 09 on Sunday, and it's now available on Slideshare.

Clarification: We've posted only the slides and notes on Slideshare. We'll post a link to the video of the presentation when it is available on the IxDA website.

The title of the presentation is "Each One, Teach One," and it discusses the future direction of interaction design as a profession. We've seen demand for our services increase dramatically over the past few years, and, in order to continue to respond to this demand, we need to make more of us. Part of the solution involves creating academic programs to provide the foundation for learning the craft of interaction design; another part is to create a culture of mentorship. This means that all of us need to learn to teach what we do.

As Kim says, "[Being a good mentor] takes good listening, observation, and collaboration skills. It takes imagination, because you have to see the potential in someone who isn’t yet able to demonstrate everything they’re capable of. It takes a willingness to explore and wander a bit instead of going down the path of least resistance."

Check it out, and tell us what you think.

Taking on big problems

When I saw Christoph Niemann's recent piece in the New York Times, I LEGO N.Y., I was struck by the way that simple physical objects, accompanied by text, can beautifully illustrate ideas.

Both images are from Christoph Niemann's I LEGO N.Y.. He has a blog called Abstract City on nytimes.com.

At Cooper, I find that I'm often looking for new ways to activate design thinking, or to clearly and directly represent ideas. It can be easy to think too literally, to work over the same terrain again and again, and this is why I'm inspired by work like Niemann's — it gets back to basics. It speaks clearly, but also invites interpretation. It reminds me of Bill Buxton's discussion of "storytelling with found objects" in Sketching User Experiences:

As a child, when your parents got a new refrigerator, did you not take the box and transform it into a fort or spaceship? We have all seen and done such things — made free associations between objects and their meaning and purpose. The key observation here is that such transformations are as fundamental to design thinking as they are to childhood imagination and discovery.

I'm curious to hear from the design community: Are there techniques that you've used to radically reconsider familiar concepts? Or to vastly simplify the communication of your ideas?

Art house movies always seem to reveal new possibilities. Last week I watched Zidane, un portrait du 21e siècle, a deep dive into one of the world's most fascinating athletes — French football god and legendary hothead Zinedine Zidane.

The film spans a single game, and dozens of cameras are trained on Zidane for the game's 90 minutes. Throughout, you're connected to Zidane — pressed up against his face, attached to his hip as he glides through the defense, drifting around him as he scans the field. You're also immersed in the sound of the event — chatter between players, the sound of cleats cutting into the ground, the distant crowd roar, and strange periods of silence.

Zinedine Zidane, from the film Zidane, un portrait du 21e siècle, (translation: Zidane, a 21st century portrait)

It's the sound that really did it for me. The gasps for breath, the immediate shifts in the pace of footsteps, the ka-chunk of the foot hitting the ball, the zzzzzip of the ball on top of the grass. If you applied this super hi-fi sound to sports I watch all the time — NBA basketball, for instance — the end result would be incredibly compelling.

Remember Clippy, the Microsoft Office Assistant? If you're like me, you remember Clippy because you hated his guts. Figuring out how to do basic stuff in Microsoft products is (often) frustrating and difficult, but being patronized by a grinning cartoon paperclip while doing so was infuriating. The fact that Clippy seemed to offer help at all the wrong times — well, that just added fuel to the fury. When Clippy joined his anthropomorphic predecessor Microsoft Bob in the UI dustbin, every user became a little happier and more productive.

Clippy came to mind when I was in Japan, a nation and culture richly populated with animated characters. On every surface, there are characters — talking penguins, inflatable dogs, instructive manga characters — and their cumulative presence seems to make the environment more engaging and friendly.

I saw this little guy in the UI of a Nintendo DS when I toured ATR, the Advanced Telecommunications Research Institute in Kyoto.

I don't know what he's saying, but he sure is cute.

So, after my trip to Japan, I'm worried that we've taken the wrong lesson from the shortcomings of Clippy. There must be an appropriate a place for characters in interactive systems that are not simply games — not all interactive systems, but some, maybe?

My question: Can anyone point me to some good implementations of characters in non-game software? Or recommend some best practices?

I'm a big fan of democracy. I believe that every citizen should have equal access to power, that a community should express its values and priorities through elected officials, and that the outcome of an election is a critical expression of the state of that community.

Still, there are limits to the utility of democracy. You don't ask your friends to vote on the probable cause of your stomachache. Newspapers don't poll their readers when they're deciding what leads to pursue. Our elected officials don't ask us to decide whether a complicated bailout plan is the right course of action for stabilizing our financial system ... (Umm, actually, I take that back).

Makers of the excellent publishing platform Wordpress recently asked their users to vote on certain UI decisions in its next release. They didn't ask users to design the UI from scratch, but they did ask some strategic, fundamental UI questions:

Q.2: The La-Z-Boy goes: (a) to the left of the TV; (b) to the right of the table with the pizza on it; (c) under the reading light; (d) other: [please explain]

Here's a screenshot of the whole survey. The survey authors tried to be helpful by providing rationale for each option, but it sounded a little like the engineers at BMW asking me where I want my steering wheel and what intervals I want on the wiper switch. On one hand, it's a nice gesture; on the other, these questions are fundamental to the user experience of their product. Shouldn't it be the business of BMW to determine the appropriate implementation?

The point is: There ARE right answers to these questions. They are not matters of taste. The key to determining the answers, however, is deeply connected with a long-term strategy for the user experience. Does Wordpress have a long-term strategy for its UI? To use a counter-example: Facebook could have asked its users whether the News Feed was a good feature. (As you may recall, users initially hated it). Facebook kept it, with a slight modification, and it is now the foundation of the tool. That's strategy at work.

On a more philosophical note: When there is expertise in a field, why pretend that there isn't? When Wes Anderson makes a movie, he doesn't revisit the first principles of filmmaking and decide anew whether film editing is really something that an "expert" should be hired to do. He hires an editor because he knows that the editor will bring out the best in the film. I would argue that UI designers have a similar effect on the technology underlying a product. They're able to craft a cohesive whole from the disparate elements. Search is a disparate element that needs a place in the cohesive whole; why ask the community to decide where it fits in the experience?

Amazement operated on many levels during the Opening Ceremonies of the Beijing Olympics. During each performance, my mind struggled to process what I was seeing. What is this? How in the world did they pull this off? Where does an idea like this even come from?

TV: These small boxes will now take the form of a keyboard, and the keyboard will sprout a peach blossom.
Doug: ... Huh.
TV: Now the small boxes, which have made precise, machine-like movements for the last ten minutes, will reveal that humans have been operating them the whole time.
Doug: ... Wait, what? ... How ...
TV: Now a globe will rise, and dozens of people will fly around it in precise circles.
Doug's brain: [explodes]

In a Wahington Post editorial, Roger K. Lewis recently wrote that NBC didn't once mention the architects of the venue, Beijing National Stadium. Hmm. That's funny. I didn't mention them during the telecast either, but that's because my brain had been reduced to a pre-verbal state.

The BBC miniseries based on Steward Brand's How Buildings Learn became available on the Internet a few days ago. It's chock-full of provocative stuff, and lays out compelling arguments about how structures succeed or fail in satisfying the needs and goals of people. (Let's hear it for design on TV! First Mad Men, now HBL. It's a televisual golden age!)

The Ferry Building

As I watched the opening episode, I thought of the quintessential local example of a learning building: The Ferry Building in downtown San Francisco. Built in 1898, it served as a ferry terminal for points around the Bay; as San Francisco changed and bridges eased the traffic burden, it gradually fell into disrepair. In 2004, it re-opened as gourmet food court, serving the prosperous downtown lunch crowd. San Francisco changed, and the Ferry Building "learned" to address a new set of needs. Beautiful.

Is architecture really a good analog for IxD?

Aside from all of the fascinating examples of the ways in which our built environment responds (or doesn't respond) to change, what the miniseries reveals to me more than anything is the limitation of using architecture and construction as models for software design and development. Architecture serves as a helpful stand-in when you're talking about the macro stuff — the planning process, the rough apportionment of the screen "real estate," and discussions around extensibility or repurposing — e.g., Is this thing the first piece of the big structure, or is it the temporary thing that we live in while the big structure is built?

But when you're talking about the way people experience things in a digital environment, architecture is a limited analog. Software is made up of subtle, nuanced interactions and ever-evolving technical capabilities. Interacting with software is conversation between two active participants; it's fast-paced and packed with immediate possibilities. For example, changing context in software seems more akin to a change in facial expression than, say, a movement to a different room. (It should, anyway). The ever-evolving technical capabilities have created a world in which we're all often experiencing some particular digital interaction for the first time; in fact, if someone wrote a book about how software is experienced, it could be called something like, "How Software Teaches Us How to Use It."

Solutions begat problems, problems beget solutions

Of course, there's another side of Brand's perspective that's relevant to our work: Most design projects (at Cooper, anyway) begin with what is presented as a straightforward task: Design a solution for the problem the clients have identified. Architects probably experience a transformation similar to ours, because the real problem is often quite different than what the client has articulated. Brand's perspective is interesting to consider here, because our solution often simply modifies (or modulates) the problem -- makes it smaller, hopefully — but still: Will our solution be able to handle the need to evolve to further reduce the problem? Of course, if anything could learn and teach at the same time, it's software. But software that can learn ... Hmm. Something sounds fishy about that. Remember that part in Terminator where they're talking about how the computers took over?

[Start with Episode 1 of How Buildings Learn at Google Video, and thanks to smashingtelly for the tip]

Once upon a time, Google made the dumb interface look like the smartest thing to ever hit the Internet. By removing the blizzard of navigation that characterized Excite and Yahoo — and by actually delivering reliable search results — Google removed huge hurdles for millions of users. Still, Google-style search is far from the end of the road; it has always had limitations and drawbacks, and it seems like these things are cropping up a lot in conversations and in the media recently.

Just yesterday, my team and I heard something interesting during some research into a really complex system for analyzing corporate finances. When we asked what had been discovered in previous user research efforts, we were told:

Whatever we build has to be stone simple. It can't be like Google, where you type in how you think about it, and I type in what I think about it, and we both get different sets of results.

Constructing good Google search strings can seem like a black art, but individual users develop personal techniques and styles that help them get more reliable results. Still, the fact that others must craft their own path toward reliability creates a lack of confidence that others will get a similar view onto any given topic.

Search results: Skimming the surface

My mind isn't going — so far as I can tell — but it's changing. I'm not thinking the way I used to think. I can feel it most strongly when I'm reading. Immersing myself in a book or a lengthy article used to be easy. My mind would get caught up in the narrative or the turns of the argument, and I'd spend hours strolling through long stretches of prose. That's rarely the case anymore.

Andrew Sullivan at The Times echoes the above author's sentiments in a blog review of the article:

The experience of reading only one good book for a while, and allowing its themes to resonate in the mind, is what we risk losing. When I was younger I would carry a single book around with me for days, letting its ideas splash around in my head, not forming an instant judgment (for or against) but allowing the book to sit for a while, as the rest of the world had its say — the countryside or pavement, the crowd or train carriage, the armchair or lunch counter. Sometimes, human beings need time to think things through, to allow themselves to entertain a thought before committing to it.

These reading-related pains remind me of writers' critiques of word processors, and the growing popularity of interface-free tools like WriteRoom. There are certain behaviors that require some radical reconsideration of current UI norms. Few would propose that we go back to a pre-search world, but the question seems to be: How to appropriately apply UI and technical smarts to retrieval technologies to foster the confidence and comfort that comes from predictability and structure?

Like most design agencies, Cooper crackles with conversations on a variety of topics. Unlike lots of other agencies, we've mostly conducted these conversations in primitive channels — over email and in person around the large, U-shaped couch where we eat lunch.

We call it "The Departure Lounge"

Up to now, private has been easy. Publicizing our conversation means work — to set up, to moderate, and to keep current. When you also factor in the unknown amount of Alan-wrangling, you're talking about a lot of time away from design, problem-solving, and the stuff we all love.

So why take it public now? Because we want to be part of the bigger conversation, and to bring people into our conversations. Up to now, we've participated in formal, somewhat old-fashioned ways — at conferences, and through our newsletter. We'll still do these things, but we'd also like to talk about stuff happening like, now, and the logical place to do that is via a web-based publishing platform more commonly known as a "weblog."

Our mission is to communicate deep and clarifying insights, to kick around sparky and elegant ideas, and to discuss design methods and processes. And we're excited to bring you, the Internet, into it.

So, without further ado: Welcome to the Cooper Journal!

Healthcare is a target-rich environment for design. Discussing even the smallest design challenge quickly exposes the hacked-together systems and processes that somehow function to help us stay healthy. Designers must understand the context in which they work, yet confronting the complexity of healthcare can be paralyzing. It seems impossible, for example, to discuss the viability of mobile devices at the point of care without discussing the Byzantine network of roles, regulations, and workflows that the device touches: nurse assistants, the lab, the patient, receptionists, regulatory bodies, HIPAA, hospital and lab information systems, IT departments, point-of-care coordinators, ADT systems, and so on.

While it’s important to understand the knotty context of a healthcare design problem, it’s just as important to know when to reach for the sword of methodology to cut through it. To illustrate this point, I’ll discuss some healthcare design challenges I’ve seen during my research and design work and the methods I’ve used to tame the complexity.

Few modes of communication burden the user with as much interaction hassle as text messaging on mobile phones. Without help from word-prediction assistants, the word "Hello" requires 13 button-presses, not including an additional 5 to get from the start screen to the messaging app. Nevertheless, the clear benefits of short text message services (SMS) have lured untold millions into uncomfortable, not to say unsatisfying, partnerships with their mobile phones.

Most people buy mobile phones because they want to be able to make phone calls anywhere, anytime. All the other stuff that's crammed into phones—calculators, game players, text-messaging capability—represents incomplete solutions for problems that are better served by devices dedicated to those needs. If I want to play a game on the go, I won't buy a Nokia 8290.

Still, phones offer a lot of sophisticated functionality to support specific mobile phone needs. Users need a way to quickly change ring-tones, ring volume, and message alert tones—so phone manufacturers allow you to tweak these so that one's phone can behave appropriately as one moves from the construction site to the movie theater.

In the mid-1980's, a team of physicians, lawyers, and public health experts conducted a lengthy study of the nature and causes of medical errors. They published their findings, entitled "Incidence of adverse events and negligence in hospitalized patients," in the New England Journal of Medicine in 1991.[1] Their research indicated that "there is a substantial amount of injury to patients from medical management, and many injuries are the result of substandard care." While the industry evaluations and renovations sparked by these findings have taken effect, physicians and clinicians have simultaneously adopted more sophisticated technologies to provide more accurate and efficient care. [2]