Where have you gone 2011? We have fond memories and can't wait to see what 2012 brings. For this year's last sCoop, here's highlights of a great year and our wishes for everyone to have the happiest of holiday seasons.

May you design the life you want to lead, and lead the life you design.
- Everyone at Cooper

January:

We welcomed the new year and a new visual designer, Glen Davis, who began rocking our design world on day one.

We didn't win Design Dodgeball, but we did have the coolest t-shirts on the block...designed by Glen.

We hosted a Lean UX workshop with Janice Fraser of LUXr.

Chris Noessel piloted our first international Cooper U Interaction Design session in Auckland, New Zealand, following it up with a presentation at Weta Digital.

February:

Nick Myers shared his insights and experience about how The Visual Interface is Now Your Brand at Interactions 11.

We hosted Service Design Drinks at the Cooper studio, and enjoyed discussing service blueprinting and ecosystems in between cocktails.

March:

Our Cooper family grow even more:

• We welcomed Phil Paulick to give us the financial insight we need to run a healthy business.
• Tamara Wayland joined us to lead us away from sales and towards true business development.
• Andreas Braendhaugen strengthened our design team...and programming team...and videography team...and...
• Kendra Shimmell arrived to take our training and education to the next level.

Chris and his co-author Nathan Shedroff were featured presenters at MacWorld for the upcoming book Make it So to be released in 2012.

Kendra Shimmell, Tamara Wayland and I recently enjoyed some Spring weather in beautiful Rio de Janeiro while sharing methods for interaction design, collaboration, and communication in an agile environment with forty employees of Globo.com, the Internet branch for Latin America's largest media conglomerate.

The team knew that Rio would be warm this time of year, but what really amazed us was the warmth and hospitality of the people we met. Andrë Braz, Globo.com's User Experience Design Manager and Art Director, and his team were engaged and inquisitive, and really hungry for ways to take their already successful site to the next level of efficiency and innovation.

During the course we talked about how to effectively integrate user experience design into an agile environment, and shared techniques for collaboration and communication that are lightweight to create but provide big impact. The Cooper team showed Globo.com a blueprint for defining and designing digital products and services that centers on users, but within the context of business needs and implementation realities.

Here are a few snapshots from class:
Participants quickly grasped the value of focusing on goals and behavior patterns when developing personas.

A cross-functional team works together to storyboard the key contexts and moments in time that their primary persona will interact with the product they are designing.

A student sketches design concepts for the mobile experience.

The enthusiasm carried over into the final day of the week, during which we were joined by close to 80 Globo designers, developers, product managers, and executives. We can't wait to go back (and I am still dreaming of the feijoada we had on Friday afternoon).

Thank you Globo, and thank you Rio!

The World Series is barely over, which means most of my thoughts this time of year get colored by baseball. Events in game five got me thinking about design exploration, of all things. I'll try not stretch the metaphor too much.

I work throughout the year with product managers, technologists, and executives at companies ranging from small startups to Fortune 100 megaliths. Many of these companies have a vision for creating a game-changing product within their industry, “the iPhone of the xyz market.” They mean it, too. But as conversations progress and a project plan begins to take shape, many of the project owners start piling on technology constraints before any design work has even begun.

“We need to use these off-the-shelf components.”

“Don't explore any solutions that won't let us use our current technology platform.”

“Actually, what we really need is just a facelift of the presentation layer.”

Not exactly the words I imagine Steve Jobs used to drive the creation of the iPod and iPhone.

Sometimes this slow degradation of vision is a result of poor or conflicting communication...which brings me back to last night's baseball game. St. Louis Cardinals manager Tony LaRussa, already a two-time World Series winner and owner of the most wins by an active manager, had a vision for which pitchers he wanted to be warmed up in the late innings of a tight ballgame. He called the bullpen coach (using a land-line telephone in the dugout), and, amazingly, not once but twice, the bullpen coach misheard LaRussa's instructions and warmed up the wrong pitcher.

I don't know if that's happened before in a World Series game, but in the corporate world, we see the wrong product get sent into the game all the time. Executives have a vision for the future, but don't clearly articulate it to the product owners (other than specifying a deadline which is often arbitrary and not tied to actual work milestones), so what gets built isn't visionary at all but driven by the calendar...which means introducing lots of constraints from the beginning. The result may be an incrementally better product, but not a game changer.

We like the saying “reality bats last,” one of Alan Cooper's original design principles. For us that means for any design we create to actually be a solution, it needs to be buildable by our client. It has to live within their unique technology, price, deadline, and resource constraints. However, we have been pushing more and more for the opportunity with our clients to do at least some unfettered, unconstrained design exploration on every project, even ones that have a narrow scope. We don't completely ignore constraints (especially things like regulations which are out of our client's control), and we won't explore designs that rely on telekinesis or nuclear fission, of course. That said, we will definitely push the envelope on what's possible—for a few days or even up to a week—so we can begin with the mindset of the absolute best experience for the user. Over the course of the project we'll push to achieve as much of this game-changing vision as we can.

Allow some your design team to let their imaginations run wild before they get saddled with constraints. (photo by Peter Duyan)

Typically, the output of this design exploration is a collection of hand-drawn sketches that target key plot points in the most important scenarios, and signature interactions (parts of the system fundamental to the experience). The sketches often explore a range of ideas, some that can be implemented within all known constraints, but also others which may bend (or break) constraints. After that, it's really a business decision our clients need to make about how to proceed. Sometimes it makes sense to restructure deadlines, add resource, buy a technology, or abandon a legacy infrastructure to get that “killer app.” Other times it doesn't make sense...but as designers it's our job to imagine the future and enable business decision makers to make the most informed decision they can.

Which brings me back to baseball. You are the manager of your company: what's your strategy? Reality is a heavy hitter, but it shouldn't bat in every slot in your lineup. Can you really afford to play it safe every game? Even if your competition is miles behind, spending time to imagine a better future for your product will position your company to more nimbly take your offering to the next level when constraints go away.

And while you are at it, I would recommend upgrading those bullpen phones.

Design research has been a key component of most of the projects I've been involved with at Cooper. Since it adds time and cost, sometimes we have to go to great lengths to convince clients to include research in a project. But design research isn't just about giving the design and product team a leg up on understanding user goals and needs. It's also about minimizing business risk and validating—or challenging—the current strategy. Typically, the insights we gain by talking with and observing users help our clients look at their business goals through a different lens. In addition to providing necessary input for designing successful products and services, this new perspective helps them make better decisions about the long-term trajectory of their product roadmap and approach. For some products and companies, it can be even more transformative, as the insights they gain help them re-imagine not only how to design and deliver better products, but also how to better structure their internal organization to do so.

Of course, companies can only make these kind of strategic pivots if they have the appropriate decision-makers engaged in the initiative, with time set aside in their decision-making process for integrating the input that may come out of user research. I've found that the business executives who treat design initiatives as a strategic endeavor and not just a tactical execution of product definition get much more value for their design dollar.

I remember studying the concept of the “reluctant hero” in college lit classes. This is the protagonist who is thrust into the role of being a savior or hero, often unequipped and unwilling to be The One. Think Bilbo Baggins, who just wanted to stay home in his hobbit hole rather than steal treasure from dragons, or Arthur Dent from Hitchhiker's Guide to the Galaxy, or even Han Solo. The reluctant hero typically needs some kind of supernatural intervention or magical object to get them to act.

As an interaction designer, I've found sometimes I need to design for the “reluctant user." This is someone who, given a choice, would rather not use the product I am designing-at all-no matter how cool the features, or how well-designed the experience. I've worked on products for disease management (“I can't wait to sit down and focus on my health condition!”), health insurance (“Sorry I can't go to the party, I'm too excited to check on my claim status!”), and—the mother of them all—filing taxes (“My dentist couldn’t fit me in for a root canal so I'm doing this instead“). In none of these cases do the users want to use the product and the related service. Yet there are consequences if they don't, so it’s incumbent on the designers to make the experience as painless as possible.

Case in point

As with any project, key to success is identifying the users’ most important goals, but it's critical to keep those in the context of how much time they are willing to spend. After working with our tax software client and talking with teams who’ve worked on projects with reluctant users, we’ve gathered some things to keep in mind when designing for the reluctant user:

• If a user’s goal is to get it done as quickly as possible, make it so. Don't get cute with whizbang interactions that prolong the experience.
• Automate when possible (or at least provide options for automating). Users will likely be willing to trade some control for simplification.
• Use language that engages the user, and be careful to avoid jargon; users won’t be motivated to look up terms (for example, a user dealing with a health insurance claim dispute will want to see procedure names, not just billing and procedure codes).
• Set expectations about how long the process will take, and show (and celebrate) progress with feedback about completed tasks.
• Fill up “dead time” (such as waiting for steps in an installation process) with either useful information (such as tips or demonstrations…NOT advertisements), or provide a time estimate so the user can go do something else.
• Focus on and highlight any positive benefits that come out of having to endure the experience (such as that tax refund).

Quicken does a nice job with this last point, communicating how using TurboTax can help people get a bigger refund (free money is always a good angle to play). Another example is from home healthcare products that take every opportunity to reward the input of information and celebrate improvements in the numbers used to track health.

We’ve recently been hoping for a shot to redesign the DMV service experience, but are still in line waiting for our number to be called. While we are waiting, have any of you worked on products that target the reluctant user? What did you do?

We’ve all got our own personal benchmarks for what makes a good user experience. My personal list includes a few: Does it delight me? Will I recommend it to my friends and colleagues? Would I have used the same approach if I had designed the product? I’ve found among some product executives one particular pattern for this subjective evaluation criteria that is both humorous and troublesome: “Would my mother/grandmother/Luddite Uncle Bill be able to use this product on the first try?”

While there is a sort of noble aspirational quality to this kind of thinking—let’s make everything so dead simple that any person can use every product—it also sets the bar for the experience rather low. I imagine a sea of step-by-step wizard dialogs that target the lowest common denominator and force everyone else to step through the same predefined (and very explicit) experience. If I’m designing a product for people who have specialized knowledge, I want to leverage that knowledge in the product. Why force people to walk when they can run? I’ll want to provide these people with clear, appropriate pathways through the product, but I also want these specialized users to be able to forge a variety of their own pathways through the interface, dependent on the specifics of their situation or how they want to do things.

I once worked with a client to design an intravenous medication delivery device called an infusion pump. This is a machine that nurses in hospitals use to administer drugs to patients by attaching a bag of medication to the device and specifying delivery parameters such as how long and how fast to dispense the medicine. This is critical stuff; the consequences of a mistake could be catastrophic.

I recently stumbled across an article about personas written by Andrea Wiggins late last year in Boxes and Arrows. Wiggins does a nice job talking about how personas can help the design and development process, and some approaches for creating a good persona set. But what really gave me pause was the title: “Building a Data-Backed Persona.” Data-backed? Wait a minute…is there any other kind?

We have a saying around the office: "If you can't explain the design, it must not be right yet." It's a reminder to designers to not get so caught up in idea generation and specifying details that we lose sight of creating a coherent big picture for the design.

We need to exercise the ideas we generate by articulating them coherently; chances are high that if we can't describe our "great idea" with clarity, it's not such a great idea, after all. It's amazing how many design ideas seem just dandy on the whiteboard, then deflate like a punctured balloon when poked at with the sharp pencil of design communication.

There's a dirty little secret that nobody in the design community wants you to know: it's actually possible to build and ship a software product…without designing it first! There. I said it. Now my time is short; even as I type, assassins with square-toed shoes and goatees are stalking my whereabouts.

But just because you can construct software products without designing them first, why on earth would anybody want to?

The analogies are endless: you wouldn't point a construction crew to an open lot and tell them to build a structure without giving them blueprints, would you? You wouldn't ask a doctor to re-set a broken bone without looking at an x-ray; you wouldn't storm the beaches of Normandy without a battle strategy and a good map; you wouldn't even don your shoes before putting on your socks.

Executives chuckle warmly at these analogies, and agree wholeheartedly that yes, it's always best to design products—the things that their companies sell for money—before building them and putting them in the hands of customers. Yet even though business decision-makers of all stripes acknowledge the merits of design, it's the designers and usability professionals who are the first to get jettisoned from a project plan when the going gets rough.

Personas and other user-modeling techniques are often solely discussed as tools for product definition and design, but they are useful tools in other arenas, as well. Technical writers responsible for creating user documentation can benefit greatly from a well-defined persona set, too.

Using personas to guide your user-documentation creation-process helps you:

• Determine the primary and secondary audiences for your documents
• Prioritize technical writing tasks by giving you a tool for identifying which aspects of the product are most important to your readers
• Write documentation in a way that helps your users achieve their goals, instead of simply cataloguing all of the product's features.

Technical writers are oft-forgotten constituents in the product development cycle. Although they are rarely tasked with participating in product requirements definition and product design, technical writers are in a unique position to affect product design. However, they will find that subtlety and subterfuge are sometimes necessary to make a politically correct impact in an organization that has not embraced interaction design as a formal part of the development process.

Technical writers and interaction design

When I started my career as a technical writer in 1992, interaction design did not exist as a stand-alone discipline in a product development organization. My role in the development process went something like this: early in the development process, I made a documentation-effort time estimate based on some vague, high-level requirements provided by a product manager. Months later, development would finally distribute an early internal release, which only faintly resembled the initial requirements definition. The technical publications team would revise our time estimates and scramble to start documenting the software. Once a week, the development team would release another internal version of the software—which might or might not resemble last week's release—and so on.

Someone always asks the question, and I am never ready for it.

"So, what products out there are well-designed?"

As an interaction designer, I learn about users and design a product that helps them meet their goals—one that is tailored to the way they work. Yet this question can still stump me. I am not alone: all too often, people in our field focus so much on pointing out the egregious interaction design mistakes that make it to market, we forget to pay attention to the good design that exists. Not only does it make our profession look bad if we are always complaining, but it also makes us less effective. How can we create good products if we can only articulate what “bad” is?

Ever notice how often a product that makes a huge splash at tradeshows fizzles in the marketplace? The story goes like this: Product is introduced at show to much fanfare. News media gives Product lots of press, and consumers everywhere express interest in Product's features and capabilities. Product hits store shelves…and stays there. Some early adopters purchase Product, but it never penetrates into mass consumer markets.

What went wrong? Market research clearly identified potential dollars in target markets just waiting to spend money on the new product. So why did it fail?