"Build a design that empowers ordinary people to do the extraordinary."
"Learn better ways to promote design concepts to partners."
"Challenge my process and how I work." 
"Nurture my creative side." 
"Learn techniques to better understand end-users." 
"Build friendships and connections."
"Learn ways to collaborate with coworkers." 
"Practice, practice, practice."

These are just a few of the reasons that 26 designers, engineers, and product managers joined forces in Columbus, Ohio last week for our inaugural UX Bootcamp competition. Their mission was to learn user experience design and use their new skills for social good. Over four intensely-packed days, they crammed their brains with Cooper's design methodology, broke into three self-selected teams, and put those learnings into practice to solve a real-world challenge for the American Red Cross of Greater Columbus. Each team pitched a concept for a mobile application that would empower and inspire members of ClubRED (a young professional's volunteer group within the American Red Cross of Greater Columbus). Cooper donated $1000 to the nonprofit in the name of the winning team, ClubRED Connect.

The winning team (ClubRED Connect), our friends from the American Red Cross of Greater Columbus, and one oversized check.

Inside UX Bootcamp

It's called bootcamp for a reason. We asked our students to perform within a tight timeline, and they took on our challenge like champs. We were mighty impressed when teams showed up an hour before the workshop one morning to get a head start on their designs (can you say, "extra credit?"). Although it was an intensive course, the teams kept great attitudes throughout. In fact, at one point, all the groups decided to set aside competition to work together to gather and share research data, knowing everyone's work would be better as a result. And they bravely stood up in front of a panel of tough, Dancing-with-the-Stars-esque judges to pitch their concepts at the end of the four days. We heard things like, "My brain muscle got quite a workout!", "You took me on a scary journey, but I came out smiling," and "The transformation was unanimous."

The judges scored teams in four categories: how well their concept addressed user and business needs; perceived impact; "wow" factor; and presentation skills. (Photo: Paul J Hart)

UX Bootcamp In Pictures

Get a taste of what it was like to be immersed in our crazy UX Bootcamp world by checking our our photo set on Flickr, or this nifty video montage:

The Final Pitches: What Teams Designed In  Four Jam-Packed Days

Winning Team: ClubRED Connect

Concept:

ClubRED Connect gives volunteers the ability to turn existing social experiences into fundraising micro-events for the American Red Cross...with very little effort. Here's how it works: designate a location for friends to gather (Let's meet for happy hour!), take photos of interesting moments, share them with your friends via the app, and make a correlated donation to the nonprofit on the spot. Your friends are challenged to one-up your donation by sharing a "Red Cross Moment" of their own and making a contribution themselves. In this way, your small contribution is amplified by your friends, your friends' friends and more.

Presentation Deck: TeamClubREDConnect_Pitch.pdf

Snapshots of the design process:

Developing Scenarios (Photo: Paul J Hart)

Developing Framework (Photo: Paul J Hart)

Mock-up of concept (Photo: Paul J Hart)

Team: I+CBUS

Concept:

I+CBUS removes barriers to volunteerism by offering lightweight ways to get involved in your local Red Cross chapter. Participation can be as simple as pushing a button to donate, scheduling a time to donate blood, pass crisis information on to your social network, sign up to attend social events, or learn about other simple ways you can pitch in. The tool gives the American Red Cross an easy way to push needs, alerts and calls-to-action to the public, while giving volunteers a simple way to amplify their participation and have greater impact.

Snapshots of the design process:

Brainstorming (Photo: Paul J Hart)

Branding explorations

Concept illustrations (alert and user flow)

Team: Save the Day

Concept:

Recognizing that we are all motivated differently, the Save the Day app gives people the ability to help at times of crisis in a way that makes sense for their lifestyle, personality, and skills. Some people prefer to assist at the scene with blankets and food. Others feel most effective and valuable by rallying their friends to fundraise. Some are best at getting the word out to their networks. The Save the Day app maximizes participation by acknowledging that it takes all types of contributions to get through crisis, and lets individuals respond to events in their way.

Snapshots of the design process:

Brainstorming session (Photo: Paul J Hart)

What's Next for UX Bootcamp

Creating a space for so many diverse, talented people to engage with one another, learn new skills, and apply them to a meaningful challenge was incredibly gratifying. As you can imagine, it just fueled our already passionate-desire to take the bootcamp to other places. We're solidifying the spot and nonprofit partner for the next UX Bootcamp adventure - stay tuned! (If you want to be notified directly of where we'll set up shop next, shoot us an email at CooperU@Cooper.com.

A special thanks to Kendra Shimmell for envisioning the UX Bootcamp and leading the curriculum development effort. We also want to acknowledge Constanza Miranda and Teresa Brazen for bringing their unique content ideas to the coursework. Kendra did a stellar job leading the workshop, with the support of co-instructors Teresa Brazen and Brian Stone. A special thanks to Brian for connecting us with our fantastic, engaged nonprofit partner. Speaking of which, we appreciate all the support the American Red Cross of Greater Columbus provided throughout, like having staff onsite throughout for questions and critique, and bringing in ClubRED volunteers for research interviews. And, last but not least, thanks to Sparkspace for providing a truly inspiring place to learn, teach, and play.

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.

It’s rare, but it sometimes happens. You will be in an interview and you hear something that doesn’t quite ring true. Knowing the warning signs and what to do in these edge cases will help you make course corrections during the interview so that it is still useful.

Screen capture from Rock Star Games' title L.A. Noire

At Cooper, we’re quite fond of pair design as a way to get to the highest quality design quickly. (Even if you have to cheat your way there.) Most of our client engagements involve a pair of interaction designers dedicated to projects full time. Over the years, two specific roles have evolved out of this paired practice.

We struggled to come up with descriptive titles for each of the roles. Though the debate was a tough one, we erred on the side of accuracy at some cost of accessibility, and call the roles generator and synthesizer. (We’re aware that that makes us sound like machines, but with the quality of design teams are able to produce in this way, maybe that’s apt?)

Generator	Synthesizer
The generator is the one whose job is to fearlessly generate design ideas; to walk up to the whiteboard or OneNote page, draw some designs, and say, “OK, here’s how I’m thinking it will work for the persona.” The gen, working with visual design, makes the design solution visual; first with hand drawings, then in illustration software.	The synthesizer is the one whose job is to insightfully keep challenging, improving, and synthesizing the design into a whole. As the “gen” posits ideas, the “synth” will ask questions, help analyze, improve, and iterate it. The synth describes the behavior in words, incorporating the gen’s drawings to create a design specification.
Together they…
…identify and evolve designs, so that the persona using the system we’re designing accomplishes their goals in awesome ways.

Some asides about these distinctions:

1. These roles aren’t cast in stone. Sometimes when the gen is out of ideas, she might hand the pen to the synth so he can draw what he’s thinking, and she’ll “synth” him.
2. We’re experimenting and refining our methods all the time, as with our new integrated product development offering. Not all projects need two interaction designers.
3. Our team structures include additional, invaluable members like visual designers, industrial designers, engagement leads, etc. This article is just about the relationship of paired interaction designers.

This is some heady stuff to explain, whether to our parents, at a cocktail party, or interaction designers applying to work with Cooper. For this reason, we often find ourselves employing metaphors to explain the relationship. Since this is usually when the lightbulb goes off, I thought I would share some of the more effective and engaging ones.

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)

In partnership with Janice Fraser of LUXr, Cooper hosted a two-day workshop to share our emerging thoughts around lean user experience and agile product stewardship with a group of designers, developers, and product strategists from Cooper, Adaptive Path, Hot Studio, 500 Startups, and several other organizations.

We spent the first day exploring the intersecting arcs of lean startup, customer development, user centered design, and lean and agile development. Each of these approaches to making software look at the puzzle from a unique perspective: lean startup and customer development come from the world of business and entrepreneurship; lean and agile development practices strive to build healthy collaborative teams and coerce order and purpose from the sometimes chaotic world of programming; user centered design emphasizes understanding and empathy for people served by the software we create. Lean UX and product stewardship seeks to weave together best practices from all of these approaches.

Material from first day of the workshop is available on Slideshare.net at http://goo.gl/aJwdm

The next day, the group put their new thinking to work helping Change.org envision and clarify a new initiative. It was fascinating to see founders of early stage startups and consultants to Fortune 500 companies find common ground in their approaches. Some were learning to recognize the particular value of narrative to provide context around features, others identifying places where their existing processes could be more lightweight or robust. When we were done, the fine folks of Change.org had three promising approaches and everyone understood a little bit more about how to move our practice forward.

I'll have much more to say about the ideas and practices behind lean UX and agile product stewardship and I'm excited about sharing our experiences and learning from yours.

Understanding how the brain works is important in interaction design not only to be able to craft experiences that support the way people think, but also to avoid common biases in our own brains as we make design decisions. One bias that sneaks into design problems all the time is called the “availability heuristic”, or the tendency to judge how important or common something is based on how easy it is for us to think of an example. For example, if you were to ask me how the baby boomers react to technology, the first example that jumps to my mind is my mother who happens to be a complete technophile and Apple fangrrl. Because of the ease with which that example comes to mind, I am at risk of grossly overestimating technical interest and ability amongst the baby boomer population.

If you’re involved in the design of products, you run into this problem all the time. Stakeholders use their own most easily-retrieved examples to compare against, whether it’s the CEO who is influenced by the pundit he read that morning, or the product manager who knows that one guy who is just like your target market, or the designer who is really designing for himself -- the self being the extreme “available example.”

Availability biases leads to poor design decisions because they are based on single, potentially skewed, examples; they also result in thrash because each individual involved in the design has his or her own reference example, making consensus difficult.

Effective research is only the first step toward avoiding this problem. Properly conducted ethnographic research will provide an understanding of the needs, goals, and behaviors of your target market, but it won’t solve the problem of availability bias on its own. It is too easy for designers and stakeholders to be influenced by, say, the most recent interview conducted, or the most memorable one.

Fortunately, we have a well-honed tool to elegantly overcome this problem: the persona. A well-crafted, research-based persona is an archetype that smooths out the idiosyncrasies of real individual people while retaining the patterns of needs and behaviors in the target market. At the same time, a persona retains enough human detail to feel like a real person. With practice and dedication, the persona becomes the first example that comes to mind. You still suffer from availability bias, but the bias is in favor of reality.

Incidentally, I got to thinking about the availability bias when Chris Noessel pointed me to this video on YouTube. Be forewarned: the tune is catchy and likely to cause a nasty case of earworm . Bradley Wray, FTW.

What tools do you use to overcome cognitive biases in your work?

I have to admit that I’ve been steering clear of talking about “design thinking” for a while now. A couple years back, when I first heard about what sounded like an exciting new angle on design strategy, I eagerly scoured the web to figure out what it was all about. At Cooper, we’ve always concerned ourselves with challenges beyond skin-deep ornamentation, and we particularly relish working for clients who value the insights that we can bring to their strategic business decisions. I’m interested in anything that gives us leverage to help businesses get beyond the assumptions that stand in the way of truly serving human needs.

So when I set off to learn more, I was a bit disappointed to discover that all the information I could find about “design thinking” appeared to prominently feature the Keeley triangle, some business success stories and not a lot more. (For those that aren’t familiar, Larry Keeley, an OG innovation strategist, devised the triangle as a way of expressing how successful businesses are balanced in the concerns about the desirability, technical feasibility and financial viability of their products.)

The Keeley Triangle. The d-school site appears to have been refreshed in the interim, but if I remember correctly, at one point, the home page featured a marker sketch of this diagram with the words “this is design thinking.”

To be clear, I have no argument with the Keeley triangle. It was part of the foundation of Alan’s arguments in The Inmates are Running the Asylum (Alan Cooper’s 1999 book about the challenges of creating great digital products), and throughout the years I’ve found it to be an incredibly useful device in explaining how design fits with business and technology concerns.

But I guess I feel like defining design thinking by the Keeley triangle alone is like explaining how to fly by stating the laws of physics. In a 1998 HBR article, one of the first articulations of design thinking, Tim Brown defined design thinking as “a discipline that uses the designer’s sensibility and methods to match people’s needs with what is technologically feasible and what a viable business strategy can convert into customer value and market opportunity.” I have very little to disagree with in this, yet I don’t find it particularly useful or interesting. And it really begs at least one big question—what part of “the designer’s sensibility”? The obsession over details? The ability to create incredibly disorganized Photoshop (or Fireworks) files? The propensity to wear black?

All this said, I certainly see promise in the vision and enormously appreciate the work that Brown and IDEO have done to popularize the idea that human-centered design methods are fantastic tools for improving all kinds of things—not just product skins and interfaces, and that businesses can get vastly more value when they ask designers to participate in the product (or service) conception process, rather than to just pretty-up an already-formed idea. So I was really excited when I finally got around to reading Roger Martin’s The Design of Business and discovered a conceptual model that has really helped me understand what part of the designer’s skillset is really useful for this big picture thinking.

Martin refers to this conceptual model as “the knowledge funnel.” The funnel starts with a mystery—for example, how to feed the newly emergent car-centric middle class of 1950s Southern California. Businesses then can create value by moving along the tunnel first to a heuristic, or simple idea about how to solve the mystery—a quick service hamburger stand; then to an algorithm, or the specific operational rules about how to achieve the heuristic—where the hamburger stands should be located, how they should be designed, what the menu should be, how to prepare every item on the menu, and how customers should be served.

Among other things, what emerges in Martin’s model of design thinking is that this “designer’s sensibility” that Brown speaks of is the ability to use an understanding of customers’ needs (as well as technology and business factors) to move inwards and outwards in this funnel by iterating through many different heuristics and algorithms to ultimately imagine and then validate a way of solving this mystery. Intrinsic to this ability is abductive reasoning— making logical leaps to imagine what might be true in the future.

These ideas really resonate with me, but I struggle with the notion that abductive reasoning abilities are unique to designers. Martin is dean at the Rotman School of Management at the University of Toronto, and his audience is largely business people. I understand why he wants to differentiate these sensibilities from the largely analytical skills that dominate modern business education. But when I first read and thought about the idea that abductive reasoning is “design thinking”, I had two reactions: first, this is what I’d thought business people were supposed to be doing all along; and second, I know plenty of designers who aren’t at all interested in or good at abductive reasoning beyond their medium of, for example, interaction design, visual interface design or industrial design.

Ultimately, I have grave concerns if imagining a better future becomes solely the province of designers or design thinkers, a world of business and political leaders will be absolved of their core responsibility—making things better. (Not that I’m suggesting either Brown or Martin propose this; in fact, they both very focused on how non-designers can learn to think like designers.) I also worry that the term “design” will lose relevance for all the other meanings we rely upon it to convey. As Michael Beirut recently put it, “Don't say design, say innovation, and when innovation doesn't work, make sure you saved some of that design stuff, because you're going to need it.”

Given the big challenges we face in terms of the economy, environment and society, I think it’s a great idea that everyone learns more about creatively engaging with mysteries through abductive reasoning. Still,there must be a better term than “design thinking” to describe it. Any ideas?

Here’s a quick tip for you as you conduct your goal-directed interviews with users and potential users: Leave a four-second pause after your interviewee pauses their response, allowing them to add more information or additional detail.

This is hard to do. In ordinary conversation, people will often step in and fill these silences. Especially with a stranger, we don’t want to leave the conversation “hanging,” preferring instead to offer up some response or reflection on what the other has said.

But an interview is not a cocktail conversation. The interviewer is trying to get as complete a picture as he or she can of the user’s thoughts. To help do this, we want to give them that room to think about what they’ve just said and append as necessary.

Last week some designers from Google came to our studio for a discussion about the  practice of interaction design. We each shared a bit about our team structures and processes, and talked about some of the unique challenges that we face as a consultancy vs an in-house design team. But some of the most interesting discussions emerged when we focused on the areas of overlap - the basic bread and butter of interaction design. One of the most provocative questions posed by the Googlers was simply: “Where do ideas come from?”

We spend a lot of time thinking and talking about how we do things around here, but if we’re honest, this is the “then a miracle occurs” step in our design process.

This is where the rubber meets the road for every designer: you’ve done your research, synthesis, and analysis to clearly articulate the problem you’re trying to solve, and now it’s time to produce that winning design solution. You get up, grab a marker, and hope inspiration strikes somewhere along those five small steps to the whiteboard. As seasoned designers, it’s not something we think much about anymore - it just happens (unless it doesn’t). But as mentors, it’s important not to yada yada yada the best part (though we DID mention the lobster bisque).

So this week, we’ve spent a little time looking inward to try to develop a deeper understanding of where design ideas come from. Here’s what we found:

Research matters

Cooper designers conduct our own user research, and many feel that this provides indispensible fuel for design ideas. Experiencing real people in their actual environments fuels our senses of empathy and intuition that helps to guide us towards the ideas that make people happy, successful (and even better looking). Plus, the research phase affords us the opportunity to be fully immersed in the users and the domain for a few weeks at the start of the project, which in addition to providing rich data and empathy, also gives our brains boot-up time to start noodling on the problem and explore possible solutions in the background. Many of our designers confessed that they often doodle during interviews, sketching design ideas when inspiration strikes without the pressure of being expected to produce a solution. At the end of the research and analysis phase when patterns, goals, and requirements have been formally defined, designers can flip back through these quick sketches and easily pick out the good ideas from the bad and begin to improve upon them based on their deeper understanding of the users and the problems that must be solved.

Sometimes, words are worth 1,000 pictures

The first step in our design ideation process comes before any “official” sketching is done: we describe the users’ ideal experience in words. The scenarios we develop at this stage are forward-looking and technology-agnostic, focusing on the personas and how they think, feel and behave rather than on specific interface elements or technical implementations. We also identify experience keywords that describe the emotional response that users should have to the product. Not having to answer the “how” frees us up to think big, imagining the best-case scenario for how the product supports each persona in achieving his or her goals. Then, when it comes time to actually start sketching and exploring interaction, form and visual languages, we’re already united around a clear vision for the kind of experience that would truly delight our users, helping us to focus on design solutions and visual styles that most fully embody that vision.

Just do it

Fear of the blank page can be daunting for all of us. Sometimes, just pushing past that fear and starting to sketch can get the juices flowing. Our designers make sure to have a tablet, sketchpad, or whiteboard easily accessible at all times, and we don’t wait until we have a fully formed thought or idea to use them. We may look like we have a brilliant idea in our heads as we approach the whiteboard, but often those few short steps aren’t where the thinking actually happens - the ideas start to come only after we draw the first few rectangles. There’s something special about the process of sketching - even jotting down some really bad ideas helps us learn about the tensions on the problem and gets us closer to a workable solution. (See Bill Buxton's Sketching User Experiences for a fantastic exploration of the idea that the act of sketching is integral to ideation and design problem solving.)