Savant. Rockstar. Gifted genius. Many of the ways we talk about creative work only capture the brilliance of a single individual. But creativity also thrives on diversity, tension, sharing, and collaboration. Two (or more) creative people can leverage these benefits if they play well together. Cooper’s pair-design practice matured over more than a decade, and continues to evolve as we grow, form new pairs, and learn from each other every day. While no magic formula exists, all of our most successful partnerships to date share remarkably similar characteristics...

Foundation

We play by the same rules

There’s many different ways people could work together, but when everyone’s playing the same game (and has a shared understanding of the ground rules), things flow more easily. The freedom to make up the rules as you go, according to your own whim creates chaotic, unstable, unpredictable systems. It’s hard to get work done when the basics are continually questioned.

David Bornstein a journalist who studies social innovation, recently described play in the New York times: “Play requires the acquisition of a complex set of skills. It’s not just about exercising or letting off steam. It’s about making agreements with others as equals, stepping into an imagined structure, and accepting that structure even when things don’t go your way.”

At Cooper we’ve got a loose set of agreements which give structural support for playing and producing together. We’re all consultants, doing user-centered design, following an archetypal process (adapted to a given project’s constraints), and we maintain specific roles for working together. These serve as the agreed upon structure or rules of the game.

How it’s played is left to the players. We value lots of autonomy within big boundaries. Every team settles on their own ways of working together for day-to-day project work. It’s as informal as a sketch of a calendar and a quick conversation around expectations. We make explicit what we need to get out of our time together, and what we’ll get done in our time apart. Everyone shows up on time, and ready to work. A quick goal-setting chat gives focus and clarity to design meetings. Starting on the same page gives permission to time-box discussions, and park unresolved questions. In meetings we’re present, actively contributing, and moving the project forward. Shared agreement about the game we’re playing removes stress around participation and supports a more trusting relationship.

Startups don’t have capital to burn or luxurious schedules for big-design-up-front. But unless your idea is by-and-for-engineers, design isn’t something you want to skip on your way to market. For a startup, design may mean the difference between simply shipping, and taking the market by storm. But with tight budgets, and aggressive timelines, how to include design and get the best value for the investment?

Eric Ries proposes a cyclical model for development in a startup: Build > Measure > Learn (repeat). Lots of smart people think he’s onto something. While Ries coined this model to explain how developers work in a lean way, the same model can be applied to design, only our “build” uses different tools, and the work products are at a different fidelity, but it’s still build. Our hypothesis is made manifest and testable.

In a recent Lean UX workshop hosted by the fantastic Janice Fraser (Luxr) and Cooper’s own Tim McCoy and Suzy Thompson (also of Cooper) suggested that the cycle was right, but that it begins in the wrong place. She suggested Learn > Build > Measure (repeat).

I buy it. After years of starting projects off with research (as little as a couple of hours in some cases) I’ve seen the power of starting off informed. Framing the problem before you start solving it is not only wise, but major opportunities for innovation often arise before anyone proposes a design solution.

So we have a cycle of Learn > Build > Measure (repeat). For a startup we can’t afford weeks of research, with the developers on the bench waiting for the voice of the user with thoughtful diagrams and artful persona back-stories. We need full-speed-ahead; design can’t afford to be the slow kid or the bottleneck.

Faster

How fast can we run the cycle? I’d suggest that design can run at a sustained pace of 3 days for a complete cycle. I don’t think you could do useful design faster. We often take 5 days for a cycle where we have time and budget, but 3 days is about the fastest you’d productively move. It bears noting that it takes a remarkably agile client to keep up with a 3 day cycle. Early stage startups with focused stakeholders and unlimited access to users for testing are the most likely to keep up with this pace. Larger enterprises benefit from a slower 5 day cycle.

Once we get the upfront work of personas and high-level scenarios done, cycles take on a regular pattern.

What do we get? Speed and low waste. We iterate quickly, with a 3 day cycle time we get moving quickly, we get rapid insights up front, ideas almost immediately up on the board, and pixel proofs within 24 hours. Sure they’re rough, but we don’t need high fidelity to test if the direction works, if users and stakeholders are getting what they need. All we need is something that gets the idea across. We’ll refine as we get deeper. And because we’re not letting design get too far out before getting it in front of users we’re keeping waste to a minimum. Our ideas will be tested early and often. We can throw out what isn’t working after a low amount of investment and focus our time on what is.

At this point the major win for startups is speed; design is incorporated without slowing things down. We also reap huge benefits from operating with such a low waste level. Days and dollars are spent building and refining the solutions that are most promising. But speed has a downside, we have little time to solve more complex problems. This may result in grabbing for obvious or standard patterns where a more thoughtful innovative approach might ultimately yield a better product. Also, design is an iterative process, the rapid cycles may seem like iteration, but the speed leaves little opportunity to revisit or reject and rework something. The first solution may easily end up the final solution. This may be acceptable for some projects, but when a startup is striving to innovate, it’s not enough to be first, you really need to deliver better.

More, better

There’s a way to supercharge this process in a way that produces predictably better solutions, and more of them. Add a second interaction designer. Pair design transforms the equation, from pure speed, into rapid insight that one designer with twice the time couldn’t produce. It’s not a case of twice as much in the same amount of time, speed isn’t increased, we’ve already maximized that. What we’re maximizing now is the quality. Two designers working together, paired in the right way delivers more, and better design.

The way we do pair design it’s not just any two designers locked in a room, struggling to wrestle the marker away from one another to prove how much better their idea is. We pair two interaction designers to maximize on the energy in polarity. We divide and conquer. One takes takes on the assertive role, the other the reflective. One takes on the drawings and interface, the other the patterns and words. One dives into details, the other keeps the big picture. One presents, the other captures. Through pairing and focusing on polarized responsibilities, we increase the value of the thinking and the product.

Let’s start with the first cycle:

Learn

While interviewing users and stakeholders we’ve got two observers, two sets of ears, two perspectives on what was learned. Our understanding is richer, fuller and more complex than any single practitioner could bring.

Build (personas/scenarios/early sketches)

One of our pair takes on the role of generating ideas, proposing solutions, getting something onto the board. The other is a dedicated thought partner. They hold back, poke holes, prompt, help evolve the ideas while they’re still forming. It’s a period of intense, rapid iteration. Roles can and do swap. We go wide, exploring much more quickly than a single designer could. Bad ideas are killed earlier. We develop clarity more quickly. We’re more confident of our decisions and more articulate about our reasons because they already went through the crucible of our partner.

Build (pixels and patterns)

Our pair differentiates further. One jumps into putting the ideas into pixels, the other into articulating the patterns that underlie the design decisions. Each works from the earlier design work, but refines it in very different ways. As we push our design though increasingly detailed scenarios it evolves. The two different approaches helps us triangulate on places where the design fails, and helps to identify fresh new opportunities. Two brains churning on the material coming from different directions, forces us to see more objectively, we can’t remain blind to the ideas we love that should be thrown out. The paired design team acts as an editorial cross-check on the thinking of the other. A single designer would be forced to choose between pixels or patterns, or struggle to articulate both poorly.

Measure (stakeholder/user feedback)

Pair designers divide up the work, focusing on a single aspect, presenting or capturing. One walks users through the flow, the other observes and captures notes. It doesn’t matter who’s doing what but each role is dedicated and focused. One designer would struggle to demo the design and really notice how users’ actions diverged from their verbal feedback, often critical distinctions which when noticed strongly inform future design decisions. With a pair of designers we capture the feedback accurately. We also have two perspectives on each test. We are less prone to fall into our own bias because we’ve got someone to check us.

More, better, faster is an investment

By pairing designers, we gain tremendous advantages. You’re running a startup and it’s easy to buy the process of a speedy cycle. It’s simple math and it maximizes cash, with quick early results. At first the idea of pair design may seem like a hard thing to sell to your board or investors. “Twice the designers, huh? Can’t we just get one and do more cycles?” Sure, people do it every day. But one designer doesn’t make more, better. Even a rock-star designer can’t generate enough polarity to come close to the “more, better” brought by two damn good designers who know how to work together as a pair. You buy a pair, you get more design; not twice the volume, but twice the quality. This isn’t that fine-china sense of quality, but the kind of quality defined by pure raw goodness. It’s the quality of solutions that people fall in love with. It’s the ephemeral but very real sense when you first make contact with the product that someone really truly understands you. Not all problems need or deserve this level of attention. There’s many times when one designer may perfectly address the need.But when your startup wants to design more, better, faster, go all the way, invest in it. Expect faster, and demand more, better. Your investors will want it too.

Related Reading

• Take the Design Collaboration and Communication class
• Lean UX workshop recap
• Lean UX, Product Stewardship, and Integrated Teams
• Integrating solve and do
• Explaining pair design (metaphorically)

Why is Google Maps on a mobile device so amazing and delightful? Why does Word Lens feel so mind-blowing? Why does a Prius feel so good when you get in and go? Why does it feel satisfying to look down at the lighted keyboard on the Mac?

It is noteworthy when the design of an experience is so compelling that you feel wonder and delight. When designed right it feels totally natural, some might even say it is truly "intuitive." No training is needed, no set-up, no break in flow, the tool fits seamlessly, improving without disrupting your experience; it's like a little bit of magic.

So how to design the delightful, magical experience?

In the digital world magic experiences are more likely to follow technology breakthroughs. New ways to give input (touchscreens, gestures, sensors), output (3D, haptics), and raw processing (speed, power) all provide opportunities for unexpected delight. These days passive input is an especially rich field because devices have many more sensors, and the raw processing power is ample enough to provide real-time turnaround on data-intensive tasks.

I'm using passive to describe input which is largely listening and processing signal which is self-identified, as opposed to active input where signal is initiated by the user with specific intent. Active input is keyboard, mouse, touch, and gesture. Passive input is background processing of optical, audio, kinesthetic, or other signal, and programmed response to this. In reality there's more of a spectrum between active and passive, not a strict divide.

If you'e got a smart phone, a Mac, or a new car, chances are your experience is augmented with passive input magic. GPS, accelerometer, light sensor, mic, OCR, RFID, and facial/object recognition are all used as passive input. But passive input signal alone isn't going to deliver delight. It's what you do with the signal which is where the magic happens.

Fully passive input, quietly helping in the background

Some sensors run in the background, quietly listening for the right signal which tells them to kick in and help. The fact that you don’t need to switch into a mode first makes the experience smooth and seamless, the magic just happens.

Your Macbook pro uses an optical sensor to evaluate the amount of ambient light. When the light falls below a certain threshold, back-lighting under the keyboard improves your ability to visually target the keys.

It's a small feature but it's super delightful. Your computer "knows" when to assist and jumps in to provide illumination. You don't need to interrupt what you're doing, but an automatic and subtle shift in the experience makes it better.

As more cars adopt it, the keyless entry and ignition of the Prius may seem unremarkable, but the design is still delightful.

Walk up to your locked car with your keys in your pocket, without using your keys reach for the handle and the car opens. Sit down and press the start button with the keys still in your pocket. Security is a necessary evil, allowing it to recede to the background of the experience is delightful.

Imagine speeding along the freeway, you become lulled into a less aware state, and suddenly traffic ahead is at a full standstill. Your reaction time is not what it should be, you didn't notice until it's too late to stop. But your Volvo S60 has been paying attention, it's been watching out for you and when it senses the stopped traffic it applies the breaks for you. Its finely tuned system adjusts the breaking to match the distance and your car stops a few feet from the bumper of the car ahead of you.

The radar system in your car searches for possible collisions with other cars or pedestrians, warning you and even taking action if you don';t. There's lots to go wrong if the system doesn't correctly identify and react to danger, but if it works as designed the experience is magic. Your car ceases to be a dumb hunk of metal hurtling around the roads and becomes an intelligent agent, working to keep you safe and protected. If the system only gave you a warning the experience of driving would be interrupted, instead it takes action and assists, improving your ability to drive safely.

Modal passive experiences, input with a little prompting

The form factor and design of hand-held devices often forces you to open an app (entering a mode) before delivering passive input goodness. The limited processing power, battery life and screen size simply doesn't allow for the activity to fade to the background. Also, no good interaction paradigm has been created which allows for automatic, smooth and intelligent switching between passive input modes. If it existed this would facilitate less modal choices, delivering instead the right assistance at the right time, without requiring a prompt from you.

There are a number of great apps that work with passive input once launched which deliver super delightful experiences.

Open Google Maps on a mobile device and it not only displays a map, but it pinpoints where you are and shows it. Move your device and the map moves to reorient based on which direction you are facing.

It's a magical experience because the map ceases to be an abstract puzzle. Its sensing and orienting to your position makes the map personal, it becomes an augmentation of reality, another view of where you are. This transformation is subtle, but deeply satisfying. The map unifies with the territory, its utility shifts from planning the route to navigating it in real-time.

Recent versions of iPhoto come with an amazing feature, the ability to automatically recognize and tag faces in your photo collection.

Once established the accuracy with which iPhoto performs this task is amazing. Add new photos to your collection and iPhoto figures out who's in them and organizes appropriately. It's a satisfying and delightful experience once you've trained it. It doesn't take a huge amount of time, but training anything takes away from the magic. Somehow training feels like doing work, you are part of the magic trick, not fully able to sit back and enjoy the show.

Nuance's Dragon voice transcription software used to take hours to train to recognize your voice. The experience was tedious and time consuming. This upfront work made it hard to feel wow'ed once it started working.

Today you can download a free app for your iPhone and simply start speaking. It's a pretty delightful experience because it just works. Your voice is instantly transformed into text.

The first version of Red Laser was novel, but failed to delight. What shifted the experience was eliminating the management and preparation required.

Version one required users to take a clear photo of the bar-code within a tight frame. The second version just asks users to point the video camera and loosely target the bar-code. It feels easier, more natural, more like how the eye operates. The experience improved and adoption rates shot up.

Point Word Lens at a sign in a foreign language and instantly read it in your native tongue.

A lot is going on under the hood to deliver this magical experience. Optical character recognition of the foreign text from a video grab, translation of it, and overlaying the video with replacement text, all in real-time. Of course you don't see any of this, and that's part of the magic. Your experience isn't interrupted, you see video that one instant is Spanish and the next is English. The video feed just got a lot more useful. Of course they also need to get the translation at least part-way right or it doesn't matter.

Pleco is another iPhone app that translates printed text. Like Word Lens it uses the live video feed. Unlike Word Lens the translation is fed back to you in a text box at the bottom of the screen instead of overlaid into the video feed.

This may seem like a small difference, but it interrupts and abstracts the experience. If your goal is to learn another language, seeing both at the same time would be useful, but for simply understanding, replacing the foreign language in place is a far more delightful experience. It feels more natural, and the interface itself doesn't dominate the presentation.

Sometimes all you need to do is give permission for the magic to happen. When you land on a web page in a foreign language, Google Chrome browser automatically takes action and offers to translate the page for you. If you accept, the page quickly transforms before your eyes, into language which you can understand.

What makes this delightful is that you are prompted at the right moment, with assistance which is immediate, and doesn't take you out of your browsing experience. The page maintains its layout, but suddenly the words are all familiar. Links still work, images still show up, it's almost as if a part of your brain has been turned on which can suddenly understand Japanese.

The promise of Jubbigo is huge: you speak into your phone in English, your phone translates what you say and speaks it in Japanese.

In practice Jubbigo gets the job done, but it never feels magic or delightful. You aren't forced to switch modes which is good; you speak words in and a spoken translation comes out. But your experience is still interrupted with the significant amount of processing time between input and output. The lag time between speaking and hearing the translation is more than noticeable, it dominates the experience. To be delightful you need near-instant performance. Google Maps works well because it finds your location immediately, Word Lens wows because the words are replaced in near real-time.

What makes a delightful, magical experience?

• Transformation must occur, adding utility, meaning, or even useful action
• It must happen without delay
• The transformation must maintain fidelity and accuracy to the original
• The transformation shouldn't interrupt the larger experience
• The less abstract, the more magical
• The less management/preparation the more satisfying

Take a look through the examples above. The ones that really delight are those that meet more than a few of these principles. When experiences show promise, but don't deliver you can see they fail to play by these principles.

Recently the internet buzzed with the introduction of Word Lens, an application for the iPhone which uses the camera to perform on-the-fly translations of signs and menus printed in a foreign language. The video demo is super compelling because the translation is so fast, and the interface so non-existent, it is as if you can suddenly read Spanish.

Imagine the places you will go. The richness of your new experience, when the previously opaque meaning of foreign signs is now clear. You are no longer forced to wander the streets, wondering what kinds of shops you are passing. You can understand signs regarding public transportation, tourism and safety. You sit down at a restaurant and with the help of Word Lens you can read the menu. The waiter approaches and quickly utters something, and waits attentively for your response. You glance at your iPhone... nothing. You flash a pained smile back, mutely trying to communicate you don’t understand. Word Lens is lame because it’s only half of the solution. You’re dumb because you can’t speak and really communicate.

Don’t get me wrong, Word Lens is a great step forward. It will help with some of the anxieties of travel, in particular in using and navigating complex transportation systems. These kinds of tasks don’t really require two-way communication. Simply reading and understanding your options is a major win.

Trying to buy tickets for the Tokyo subway, would have been nice to have Word Lens.

But, you don’t need to read to understand what a particular storefront offers. You just look at what’s on the shelves.

Hong Kong street scene, no translation needed for understanding

You don’t really need translation help for safety related issues. These were solved a long time ago with universal picture language.

Where safety is concerned pictures have long sufficed, Parisian "walk" pictograph

The hardest part of travel isn’t understanding, it is being understood: Asking for directions, ordering food, asking for a receipt. It’s frustrating to struggle at expressing your needs.

Word Lens leaves you with a little more input, but a frustrating lack of output. Now you may understand, but you still can’t say a damn thing.

The speed and accuracy of the underlying technology is a breakthrough. The transparency and dead-simplicity of the interface is exactly how visual hand-held translator should work. As many people have commented Word Lens delivers on the promise of augmented reality. This technology shows great potential and will most certainly be adapted and built upon.

But, until we get a voice, a way to communicate back, Word Lens is little more than an amazing party trick.

Typing into Google translate lacks the elegance, speed and simplicity of the Word Lens interface, but it does get you to "speak up" for yourself. How could Word Lens improve upon this?

A couple of girls use Google Translate to order Indian food

“We don't finish the movies, we just release them.” -- John Lasseter of Pixar

It’s easy to think of design as an ongoing iterative process, a constant refining that never reaches an objective “end.” It is especially easy to think of software in this way. Because code isn’t static, design of software is relatively dynamic, able in many situations to alter direction or incorporate new functionality without overturning initial design-framework decisions. While this can be true, it is also possible for design to reach a state which is done. Not simply done for the next release, but where design reaches finality. The design no longer carries the evolution of the product forward.

Once design reaches a stage in which the difference between versions is more window-dressing, or a change in interaction approach, rather than a realization of deeper functional improvements, design is done. When the ideas on how to improve a design no longer come, when the designers can no longer see a way to improve the idea, it is done. It isn’t that someone else couldn’t take the idea and evolve it, but that the stewards of the design reach a point where their collective imagination can’t move the product forward.

Design which is not done

It’s easy to find examples of design which isn’t done. Lots of first generation software is released delivering basic functionality. Later versions fill out with functionality, growing to meet the latent potential in the first version. This design isn’t done.

Early designs of Evernote promised much more than was delivered. Successive versions cast and recast the design until the initial flaws could be worked out. Early versions provided little more than a limited word processor that stored stuff in the cloud. The interaction paradigm was a little strange and frustrating. Evernote continues to be a design in process. Functionality continues to evolve and improve with each release; the design isn’t done.

Mature software may not be done either. Photoshop versions 5, 7 and 8 delivered significant design shifts. Paradigms for working with text, the inclusion of vector images and interface for handling of RAW images marked major departures from previous versions. As an 11-year old product the design of Photoshop accomplished remarkable adaptation and revealed the “incompleteness” of prior designs. Of course the design leveraged advances in technology which were not available for earlier versions, but that’s the point. The design wasn’t done, design could still be used to improve the program, to advance what it did and how it did it.

Design of non-software products may also reveal a level of “not done.” A baby stroller from BumbleRide is “done” in the sense that you can purchase one and it works. The design is largely coherent and shows evidence of finish. But even here the design isn’t finished. A comparison of the 2008 and 2009 versions shows significant advancement of the design even though each of the versions was sold as a completed design. Wheels gained quick-release, the safety harness adopted a single button release, and the sun hood extended for more coverage. So is the design done now? I’d argue no. Improvements in ergonomics, materials, and signage all provide ripe areas for the design to continue to evolve.

When it reaches "perfection"

Design isn’t done when it reaches a pinnacle of efficiency or goodness. Done isn’t really a measure of quality or perfection. Many products never reach any level of quality or refinement. They represent evolutionary dead ends, still-born ideas with no potential in which to grow. They are poorly conceived, even if executed well. Crappy products may arguably be done before they are ever built or coded. The lack of vision from the start dooms the product to an evolutionary dead-end before it’s even born. If perfection is the measure of done we don’t have any way to agree on what is perfect or good. Perfect doesn’t give us a way to evaluate done.

When it feels done

Subjective evaluations by the creator may be acceptable in the realm of art. Artists work until the piece is “done;” till they feel the idea has been expressed. Design of products whether software or hardware need more objective measures than feelings. In part, designers need this because the act of creation relies on a whole team, not just an individual. We also need measures because products exist in a marketplace; there are deadlines, ship dates, feature sets, marketing and sales efforts, which require more clarity around when the design will be done.

When the time or money runs out

For consultants, work is “done” when the contract (time) is up. Projects are scoped to meet specific deadlines and requirements which fit those timelines. Design deliverables are iterative, each pass we give moves a level deeper and we work out more of the design details. We give great value for our time, but design is “done” when we run out of time. Our design is rarely done in the sense that every detail has not been worked out, all the possible problems have not solved. We work down from larger more fundamental patterns and frameworks, iteratively filling in the details. The big picture may be done when we deliver, but often it is internal product owners or developers who will actually “finish” the design.

When the requirements are met

It could be argued that design is “done” when the initial requirements have been met. It’s done enough to release a version, but it’s not really done. After the product ships the design team refines the design, adding in features or fixing issues which shipped in the previous version. The designers work to fulfill the full potential of the product. As long as their work produces advancements the design isn’t done.

When innovation plateaus

Design is done when its evolution plateaus. A couple of versions are released with little more than rearranging the deck chairs. Rework or changes to the interface reflect passing fashions rather than fundamental shifts in direction or functionality. Innovations in the marketplace or in technological breakthroughs are not incorporated or addressed in the design. Evolution grinds to a halt, the product ceases to advance in meaningful ways.

Design continues on many products long after the design is done. Design effort is wasted in chasing a market rather than leading one. Products become bloated with features which compromise the clarity achieved when the design reached “done.” Features are designed which don’t evolve the product; they complicate the vision reaching to be all things to all people, ultimately hobbling the product. The design of Microsoft Word has delivered little beyond version 5.1. It is a quite usable word processor, but the design for word processing was solid in 1991, in the subsequent releases little was advanced. Features where added that did little to improve the word processing experience. The design also failed to take advantage of shifts in the marketplace or technology. Five versions later Word is still largely a pretty good word processor. While much has changed in the interface switching interaction paradigms from menus to the ribbon can hardly be thought of as a fundamental shift in functionality. Word hasn’t evolved so much as changed it’s wardrobe.

Some products manage to react to changes in technology or marketplace. The design accommodates changing needs and opportunities. The product evolves through design to include new functionality, utility and continues to add life to the product. While Adobe Acrobat Pro has struggled with its share of bloating and incessant updates, the design of the program has continued to evolve. From humble beginnings of a reader/writer for portable documents, Acrobat has incorporated new functionality unimaginable when the product was initially designed; OCR of text, automatic creation of interactive forms, document markup, digital signing and distributed workflows. The integration of this new functionality has stumbled at times, but Acrobat X delivers a coherent, usable evolution of a product that is more than 17 years old. What was just latent potential in the embryonic design of the first versions of the product has been realized.

Some products are so deeply bound to a specific paradigm that the only reasonable evolution is an entirely different approach. The original design is done. A new product, with a different design, is created to address new technology, and a new marketplace. The original iPod‘s design is done. The scroll-wheel/menu design of an mp3s player was groundbreaking and brilliant, and it was well-executed. At some point it became clear that this design was done; it couldn’t evolve while maintaining the same core design. The only road forward was to abandon this “done” design, and adopt a new paradigm. The result was the iPod Touch. The shift was more than simply adding a bigger screen with touch input; what the product could do radically shifted.

Why does it matter?

It is important to acknowledge that design can reach a place of “done.” If we don’t, we may end up fooling ourselves that we are moving products forward when we are really just treading water. If we can’t step back and evaluate whether a design is done, we may continue to put effort into a product which we can’t improve. We will continue to release products that don’t help people achieve their goals, or worse--damage great products by bloating them with features no one needs. Knowing when the design is done allows us to recognize when our efforts will be productive and when our efforts will be wasted. When design is done it’s time to move on, to take up new challenges or products and start designing again.

The best public transit experiences provide riders with wayfinding and signaling which makes everyone, from tourist to commuter, able to navigate the system like a pro. People who are new can easily understand which train to catch, where to get on, when to transfer and when to get off. Those who ride it every day are able to relax, focus on entertainment or reading, and when their stop is reached, gracefully exit without confusion.

Every morning I ride the Bay Area Rapid Transit (BART) train from Berkeley to San Francisco. When I was new to BART, I spent my commute worrying that I was getting on the wrong train or missing my transfer. Now that I’m a regular, I stress about running to catch my train, and wonder whether I should try to cram myself into the packed car or wait for the next one which will have space.

There are many clever solutions that would rely on location-aware smart phones, but with over 30 miles of tunnels, cell signal is unreliable, if available at all. There are apps such as iBart Live which give riders access to live BART schedules on mobile devices. When these work, some of the trouble catching the right train and transferring is alleviated. When they don’t, because there is no signal or because the data is inaccurate, riders feel stranded and annoyed. At some point, the telecom infrastructure will be reliable enough to provide consistent, good information; but even then, there's will be more to be done to make things straightforward and easy for riders.

Outside the station

Riders have no visibility into the live train schedule until they reach the platform. Often this means running down the escalator as soon as you realize the train with the open doors is YOUR train, only to have the doors close before you can reach them.

On the outside there is no way to know which train is approaching the station

Give a heads-up to people before they enter the station. Knowing that my train is due in one minute I’d rush sooner and be able to make my train. Knowing that that the train I hear isn’t mine would allow me to step aside to let those who are tying to catch it move ahead.

Supporting people's usage contexts has always been an important component to good interaction design. With mobile devices, the diversity of these contexts has gone up, and thankfully many applications have become more responsive to changes in context. It turns out though, that all of this responsiveness has created a big gaping need for better capabilities for easily returning to previous contexts. I think I've got an idea that would help.

Imagine Carl, an iPhone owner. As someone who is directionally challenged he relies on his phone for directions to almost anywhere. In the morning he accepts an invite to dinner across the bay and uses his phone to map the route and figure out how much travel time to plan. During lunch he opens the Map application to find a local electronics store. If he wants to use the route to dinner this evening has two options. Abandon the route, do his search and later reenter the addresses for directions, or save the origin and destination addresses as bookmarks to use later.

He has also figured out that for short trips he can just take a screen shot, so long as the directions fit on one page. This allows him to save many routes that he uses on a regular basis, though he hates that he can't zoom in or scroll around, and they don't show live traffic. He wishes that screenshots would actually be more like saved states of an application, that when he opened them would allow him to interact in the usual way.

He'd like to save states for more than just maps. He gets travel itineraries emails that he needs to reference repeatedly over a week long trip. He does the screenshot trick when he can, but sometimes they are long and he can't screencap-scroll. If he could save the email screen state he could just return to that important email without scrolling or searching though his inbox.

He gets mobile boarding passes as links that open in Safari. The page tries to refresh when he opens the link from his email. If he could just save the screen state in Safari it wouldn't need to refresh the page, and he could scroll down to locate his seat number.

With the recent introduction of multitasking on the iPhone, there is the possibility of saving an app in an open state. Why not extend this functionality to allow for saving multiple states of an open app? Apple could provide an application which works similar to how the photo app works with screenshots. But instead of static images of the screen the application would allow Carl to open the saved state of the application. Instead of a static screen, the information could be manipulated as usual (scrolling, zooming, turing on and off options).

Simple things like scrolling (which is not available on screen shots) would make it easy to save and retrieve mobile boarding passes. Saved states of the map application would maintain the route and allow for live traffic updates. It would be easy to retrive a specific email, or return to a web page without refreshing the data. For Carl the best part would be that he can save many different states, so he can save every route, and return to many different emails.

The application could replace the screenshot function. When Carl wanted to grab a screen state he would press the "Home" button at the same time as the "Sleep" button. Visual and auditory feedback would confirm the action was successful. To return to the saved state Carl would simply open the Saved States application. He is greeted with a simple interface; icons of the saved state of the screen are displayed in a time sorted matrix across the screen, he can scroll down, and view older state captures. Since he captured the states he has some visual memory of the screen and icon helps him distinguish between different captures. The sorting by time serves as a secondary way for him identify captured states. Once the desired state is located Carl touches the icon to relaunch the application into the saved state. Once open he can manipulate the application like normal.

With Saved States Carl can quickly capture a screen he will want to return to. When he revisits the saved screen state he has all the functionality he expects, but starts off with the application loaded with the data he wants, rather than starting out from the beginning every time.

I've been looking for a new place to rent using craigslist, and while it's an invaluable source of information, i've been frustrated by how much unnecessary work has been required. I've wasted huge amounts of time writing emails and making calls to fill in details not included in ads. Even when I do this extra legwork, I forget to ask about something and show up to a place I wouldn't have even considered if, for example, I'd known it didn't have a gas stove.

Part of the problem is that every posting on craigslist is formatted uniquely. One person is a realtor and posts an HTML formatted ad, while another is a homeowner listing a rental for the first time. One is verbose and full of irrelevant details, another is three sentences long and only lists generic information such as number of rooms.

It's clear that most people writing a listing aren't real estate professionals, and when faced with a big blank text box, they type in whatever they can think of off the top of their heads and post the ad. Sometimes this works out, but much of the time this results in lots of overhead answering questions via email and phone, or showing the house to people who aren't a good fit for the place.

Current craigslist housing posting form

Luke Wroblewski wrote a great post about narrative format registration forms -input boxes within sentences-basically madlibs. While the focus of his post was on increased conversion, it shows that this kind of approach can be more inviting and friendly than standard form boxes that can feel like you are doing a lot of work to input information.

What if Craigslist offered a narrative format template just for listing rental properties? Housing listings are a constrained problem with a limited set of vocabulary which lends itself to templates. This template could guide home owners in crafting a post which is easy to read, includes the kinds of information that renters need in order to make decisions and saves everyone time. Of course the old text box could still be an option for those who want to craft their own post.

Mad-libs style template approach for posting rental listings

The template offers a simple streamlined method of posting, resulting in ads which are more consistent, yet customized in the places which matter most, highlighting the unique differences between rentals. The mad-libs format is faster and easier to compose, and results in prose postings which are easier make sense of and save time and effort of matching renters to homes.

There has been a lot of hype recently as Netflix announced provisional winners of their million dollar contest to improve their recommendation algorithm. The goal was to improve matching by 10%. Since it took over 50,000 entrants the better part of three years trying to improve past 10% this is probably a trick they can only pull off once. Given that their current recommendation engine does a miserable job of recommending movies for me, even a 10% increase isn't likely to be particularly satisfying.

I've rated just shy of 800 movies on Netflix;and just over 150 items on Amazon, yet Amazon's recommendations are usually satisfying while Netflix struggles to accurately recommend any movies I'd like to see. This isn't a case of esoteric movie tastes, in fact I'm fairly mainstream, largely preferring the entertainment of a summer blockbuster to the intellectualism of an indie documentary. The books I like are the opposite: non-fiction, obscure, expensive, limited runs, or out-out-of-print, in short; not popular. And still, Amazon recommends the right books.

Pandora is a music service which delights me by consistently recommending new music to me which I like. Netflix can't give me great recommendations. Amazon and Pandora do. Why?

Clearly the algorithm is a critical part of any good recommendation engine. But there seem to be limits to what can be accomplished just by tweaking the math. If Netflix can only squeeze a 10% improvement out of the calculation for recommendations, where can they turn to get additional increases in quality?

Tweaking what happens before and after the algorithm seems to be the only other opportunities. Both of these are ultimately interaction design solutions. Let's take a look at a few approaches to recommendations used by Netflix, Amazon and Pandora and see how they lead to different results.

In the past few years the design community has taken sustainability from a mere buzzword into a call for action. Eli Belvis, Tony Fry and Cooper's own David Fore have all championed the idea that the practice of interaction design must promote and encourage sustainable decision-making. The Designer's Accord has emerged as a mandate to turn the the goodwill into commitment and a plan of action, improving the role of design in sustainability.

This is all good, it's all needed, but we also need to get down to brass tacks. A cursory survey of the internets reveals a hunger for actionable discourse about sustainable interaction design. What does sustainable interaction design look like in the wild? What does sustainable mean when it comes to designing software? What are practical design choices that encourage sustainable behavior on the part of the end user of software?

How do you thoroughly critique a design without crucifying the designer? What are ways of critiquing that result in better designs, rather than defensive justifications?

Scott Berkun explores a model for design critique in a detailed post, but I'm interested in the little stuff that works for your design team in day-to-day practice.

At Cooper, our teams often work together for a year or more. It is important for us to create a dynamic of cooperation, but great design often happens when we push on assumptions and challenge the first iteration. We want to encourage this critique, but make sure that it doesn't derail the meeting.

Why is that good?

It's pretty common to hear a skeptical Cooper designer begin a critique with some variant of the question, "Why is that good?" Many ways to express disagreement have negative effects on the meeting or relationship. "That won’t work because," or "But what about." These tend to bring momentum to a halt. Designers must stop, defend their ideas, or chase objections.

As anyone who has faced a blank whiteboard knows, once the ink gets flowing it is important to run with it and see where the idea goes. Communication strategies of design partners can enhance or detract from this process. By asking to see the goodness, we focus on enlightenment, encouraging our partner to help us see what they see. Also, asking an open-ended question is an acceptably naïve way of pushing your design partner to step up and show you what is going on in their mind.

At the core, we want our teams to feel comfortable in expressing healthy disagreement, and to focus on clarifying rather than justifying.

What are ways that your team has developed to critique design while maintaining harmony on the team?

Software makes us think. Sometimes, it aids productive thinking by pointing us toward the right things to think about. Other times, it gets in our way, poses confusing choices, and generally frustrates us; this unproductive thinking can be seen as the cost of doing business with an ineffective interface.

Christof van Nimwegen's doctoral thesis focuses on the ways in which software can be used as an aid in creative thinking, and it specifically discusses the trade-offs between requiring users to construct an internal understanding of the system, and externalizing that system in the interface, via menus, dialogs, or wizards.
Bill Thompson, a regular commentator on the BBC World Service program Digital Planet, enthusiastically responded to the paper with the following:

It is also the sort of basic psychological research that we desperately need in the Web 2.0 world where major sites like Facebook are constantly being redesigned on the basis of little real understanding of how people engage with their computers.

I was interested to see someone addressing interface design from a strictly psychological perspective, rather than one rooted in interaction design:

We concluded that relieving a user’s memory and making interactions assisted by externalizing information does not have beneficial effects. It makes users count on the interface and gives them (unrightfully so) the feeling that the task and thinking-work is partly done for them, which seduces users in more shallow cognitive behavior.

Wizards can have the effect of seducing users into shallow cognitive behavior. When users are guided through a simple process, they are often shielded from an underlying complexity. While saving the user time and effort in the short term, the wizard may also make them less capable in the long term because they haven't had to deeply consider their actions.

Nimwegen continues:

... Interaction should facilitate or even persuade users to learn what underlies the task they are doing. The same is true in situations where interruptions are commonplace and where in the meanwhile mastery of what is underlying a task or domain is desired, or when operations come with a cost and direct solutions without deviations are the aim. In designing our interfaces we have to be careful with providing interface cues that give away too much, and must design in such a manner that the way users (should) think is optimally supported, which in turn could help the software to achieve its specific goal.

Not every task is important enough to teach users the mechanisms that support it. Many interfaces benefit from a level of abstraction or decoupling from the underlying processes. The spirit of this research is to point out that the effort to dumb down can go too far. Removing some of the obstacles to learning complicated or deep domain applications may actually do more harm than good for a user.

For example, a beginner may struggle to through the myriad complexities of 3D modeling software, and this struggle may in the end produce more competent users. The software shouldn't erect unnecessary obstacles, but a learning curve that is too shallow may actually hinder their ability to really develop competence in program in the long run.

(Via BoingBoing)

At Cooper we talk a lot about goal-directed design. Usually the term "goal" is used without an explicit distinction between goals and a motivations. The distinction is an important one which can influence design.

Users enjoy the satisfaction of achieving their goals. User goals help us focus our design on solving meaningful problems for the user. If we design with the user's goals in mind, in the best case we will help them achieve their goals, at worst we stand out of the way.

Goals are defined as the "state of affairs that a plan is intended to achieve". Goals are what a person wants to do, achieve, or become. They are boundaries to states that people strive toward, and once they reach either terminate their efforts, or shift into a maintenance of the achieved status. Feeling smart, getting the best deal, and living the good life are all examples of goals. They represent a desired end-state of a set of particular actions.

Motivations are the drivers behind setting and pursuing goals. Motivation is why someone wants to do something. Motivation is what arouses and sustains action toward a desired goal. It gives purpose and direction to behavior.

In researching this, I was disappointed to find that there is little consensus on what are the core motivational needs. Some theorists claim motivation comes from stimulus-response, others from affect, others describe motivation in terms of social or cognitive drive. A survey of the major motivational theories reveals a few commonalities. Needs, desires and wants are the sources of motivation. Motivation directs behavior toward increasing, decreasing, or maintaining a specific state. Dr. William Huitt's list of motivational needs provides an overview of all of the major theories. I have distilled this list into the essentials.

With Governor Sarah Palin's very public web-email security breach this week, there are dozens of blogs and websites pointing out how common password reset schemes are broken and debating how to improve the security of password reset tools.

Of course, password reset is just one part of the login experience which could use some improvement. There are a variety of ways to set up a web login system. A survey of many of the leading social networking and web services reveals some best practices and a number of less than satisfactory solutions. The choice of approach to a login ID determines how users must act to recover usernames and passwords and what kinds of verification must be provided.

When we create a persona or a model organization, we're deliberately creating an archetype — a person or company that does not map to any one "real" person or company out there in the world. In creating personas, we need to be up-front with ourselves and our clients about the choices and assumptions we made along the way. We also need to be clear about what questions we asked and what we didn't. When we don't have the data, we need to acknowledge this and rectify it if necessary.

This point may seem like a methodological nuance, but it relates to ethical considerations that in other realms, as I recently discovered.

My design partner Chris Noessel and I just completed three weeks of research travel around the world. Neither of us had been to many of the countries, and we both photographed our adventures obsessively. One morning, he asked me to compare a photo he took to one that I took: Why did they look so different? We were using almost identical cameras and taking photos often of the same views.

Chris's photo.

My photo.

Why does mine look different? Because I adjust the photographs post-capture, slightly adjusting the contrast, lightness, and so on. For me, the unprocessed photos rarely convey my experience of the event or location, and the post-processing is intended to re-create my memory of the experience. I take photographs to share that experience, not to share the exact pixels the camera captured.

Chris admitted that it made my photos "look better," but that I "took liberties" to adjust, and once I started, where would I stop? How much change was too much change? How different could it be from his untouched version and still be the Great Wall of China?

Of course, this is part of a much larger conversation. Photographs appear to be very faithful representations of reality, so one may argue that viewers of photography bring a different set of expectations to them than they do to other visual art. Viewers expect photos to be more "real," more true to life, and therefore post-facto monkeying could be seen as deceiving. On the other hand, who is to say what "real" is, really?

Essayist and photo critic Susan Sontag addresses this argument in the introduction to her book, On Photography.

In deciding how a picture should look, in preferring one exposure to another, photographers are always imposing standards on their subjects. Although there is a sense in which the camera does indeed capture reality, not just interpret it, photographs are as much an interpretation of the world as paintings and drawings are.

Even before taking the shot every photographer has made choices which will affect the captured image — camera and lens, film v. digital, SLR v. point-and-point shoot — and each has an effect on the contrast, color, and depth of field, aspect ratio, and so on. We can continue to split hairs, too; for instance, we accept that the journalist which uses a telephoto lens is "telling the truth" even though it grossly manipulates scale between foreground and background. With so much noise in the system, it seems arbitrary to assign "reality" to the raw output of the camera, doesn't it?

The National Press Photographers Association defines a couple of broad categories in the altering of photographs.

There are technical changes that deal only with the aspects of photography that make the photo more readable, such as a little dodging and burning, global color correction and contrast control. These are all part of the grammar of photography, just as there is a grammar associated with words (sentence structure, capital letters, paragraphs) that make it possible to read a story, so there is a grammar of photography that allows us to read a photograph. These changes (like their darkroom counterparts) are neither ethical nor unethical — they are merely technical ... [However], once the shutter has been tripped and the moment has been captured on film, in the context of news, we no longer have the right to change the content of the photo in any way. Any change to a news photo — any violation of that moment — is a lie." [The emphasis is mine].

The NPPA distinguishes between the technical aspects of making photos "more readable" and "changing the content," and I think that this is an interesting analog to the world of creating design targets (i.e., personas, organizations, environments). In our process, you could look at the transition from research to personas is the process of making the research "readable."

Of course, creating personas from research is a lot different than manipulating contrast and lightness in a photo editing app, but the principles are the same: Altering the content is a lie; each archetype that we create should faithfully reflect the gathered information, and each should bring out the priorities, needs and experience imperatives that affect the design. You can monkey with research just like you monkey with photos. When done well, slight adjustments to the color and contrast of the research more effectively reveals the truth. When done badly, they can lie and deceive.

Recently, a client who was observing us perform stakeholder interviews made a casual off-hand remark at the end of the day that the interviews had "wandered around a bit." We had explained how our interviews are less survey-driven, and more ethnographic in style, but it's often hard for the uninitiated to see the immediate value of an ethnographic type approach to interviewing, especially when it results in circuitous answers. We were particularly happy with the wandering of our interviews, which had produced visceral clarity which could never have been delivered with an overly structured interview. For example, hearing that the back-end systems are "dog shit" provides an additional layer of information than simply hearing that they're "dated" or "inadequate."

Tommy Stinson, Strategic Director at Cheskin, another Bay Area innovation engine recently blogged: "The goal of the discussion isn't to just get the participant's 'take' on the topic (at least it's not limited to that). The goal is to understand this person (or people) and their culture - the 'webs of significance.'"

We work from structured interview instruments, but as a journalist friend of mine is fond of saying, "the best quotes happen when the tape stops rolling." When we leave the scripted interview and allow someone to lead the interview themselves, often things which we couldn't predict or identify are revealed — and, in some cases, new topic areas can be added to the instrument as a result. Of course it's important to return to the script to hit all of the main questions we have, but it is equally useful and important to allow an interview subject to lead a little, to give them enough time and latitude to wander into areas which are not on the map.