We're working on a larger post about the awesome IxDA 2012 in Dublin last week, but in the meantime, I wanted to chat separately about sketchnoting.

I'm a drawer, there's no doubt about it. I can barely manage to consider a design problem before I'm reaching for a pen and paper, or my Tablet PC and a stylus and cranking open OneNote for an explanatory drawing or mind map. But that got taken to the next level when I attended "Visual Thinking Through Sketchnotes," a workshop by MJ Broadbent & Eva-Lotta Lamm.

In it we covered the basics of sketching and then went further into what that means for capturing the complex ideas communicated in lectures and speeches. I was hooked, and challenged. I spent the next three days both enamored of the excellent ideas being presented (high marks on all four things I look for in presentations, nearly across the board), but also trying my new skills at sketchnoting. Here's the whole set.

Where do you start when you're approaching a complex software design problem? If you work on a large development team, you know that software engineers and UX designers will often approach the same design problem from radically different perspectives. The term "software design" itself can mean very different things to software architects, system programmers, and user experience designers. Software engineers typically focus on the architectural patterns and programmatic algorithms required to get the system working, while UX designers often start from the goals and needs of the users.

In the spring of 2009, I participated in a research study that looked at the ways in which professional software designers approach complex design problems. The research study, sponsored by the National Science Foundation, was led by researchers from the Department of Infomatics at the University of California, Irvine. The researchers traveled to multiple software companies, trying to better understand how professional software designers collaborate on complex problems. At each company, they asked to observe two software designers in a design session. At my company, AmberPoint, where I worked at the time as an interaction designer, I was paired with my colleague Ania Dilmaghani, the programming lead of the UI development team. In a conference room with a whiteboard, the researchers set up a video camera, and handed us a design prompt describing the requirements for a traffic control simulation system for undergraduate civil engineering students. We were allotted two hours to design both the user interaction and the code structure for the system.

Jim Dibble and Ania Dilmaghani at the whiteboard in their research design session

In our modern digital environment, all businesses have a great competitive need for creative thinking that far exceeds our industrial forebears. In the quest for an institutional source of creativity, the brainstorming session, where several people meet to have fresh ideas, has emerged as the front runner. Brainstorming can be fun, and some prominent consulting firms have prospered proselytizing this technique, but it has a remarkably thin track record of success.

While people think and behave differently when they are in large groups versus when they are alone, I also believe that people behave still differently when they are in the presence of only one other person. This is often overlooked, yet I believe that creative people can be at their most effective when they work in pairs.

I believe that all people share these three modes of behavior: solo, paired, and group. Generally, these differences are noted only as interesting social quirks, and have not been investigated by academia or exploited by business, but their differences have important implications for the creative manager.

Brainstorming's adherents believe that a group of people can together imagine more and better solutions than any one person can alone. I won't dispute that assertion, but just because one is better than the other doesn't imply that either is anywhere close to being optimal.

A recent article in the New York Times put forth the radical idea that brainstorming might not be such a good idea, and cites recent research indicating that working solo is more productive than working in groups. The author, Susan Cain, points out that many of our greatest innovations came not from large groups of ideating peers, but from solo geniuses working in isolation. Her case in point is Steve Wozniak, the enigmatic inventor of the Apple computer.

As a former inventor who worked almost exclusively by myself, I agree with Cain. The problem is that, at the time, I would only work for myself, and like me, few independent creative people can be motivated to solve the problems of someone else's business. Unless you get remarkably lucky, you need to find a way to reliably innovate with people content to have a steady job.

When I began to consult for others, I too faced the challenge of generating consistent, reliable, and predictable imaginative problem solving. After some struggle, the correct solution finally emerged: pair designing.

This year marks Cooper's twentieth anniversary engaged in intensively creative work performed for hire, on schedule, on budget, for a wildly diverse clientele. Our work is nothing if not creative, and we consistently astonish our clients with the depth of our innovative thinking. What's more, we almost never do group brainstorming, and solo problem solving is, while not forbidden here, institutionally frowned upon as being too slow and expensive. Our ability to innovate reliably and effectively is largely due to our insistence that our creative consultants work in pairs.

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.

Like it or not, the digital world has changed at a wicked pace, and more and more interactions between companies and their customers now happen via an interface. Software serves us everywhere, and the user experience now shapes these interactions every day. At the center of all this change sits the brand. TV and print advertising now regularly feature digital experiences from the likes of Apple, Google, Toyota, GE, and Amazon. The visual interface has become the new face of your brand. This means that the role of Chief Marketing Officers (CMOs) is now harder, and their influence must reach further into the organization than ever before.

More customer interactions are now digital, and the brand sits at the center

Expectations are now much higher. My wife, for example, has lost all patience with technology. She hates how TiVo doesn't record her programs on time; her Dell laptop seems to break frequently; her iPhone is too slow. It's not just my wife, though. I see it frequently in healthcare and financial services. Even employees in larger enterprises have lost patience and expect better.

At Cooper, I see clients struggle with traditional marketing practices to deliver software that lacks the deeper level of engagement that customers are looking for. Some of our clients have changed their approach to marketing and product design and are reaping the rewards with a place on Forbes' Most Innovative Companies list.

This first week of August has been good fun from start to finish! Jim, Faith, and Rock Health agilely went from stories to a plan of action.

Alan's post on ideas, innovation, and creative teams reminded us of an interesting perspective on innovation from Clay Christensen and Art Markman about busting innovation myths.

We took a break to watch the Giants game with our amazing summer interns Mo and Brendan.

Today, Golden, Greg, and Jenea are doing their part at Device Design Day. Get some design goodness of your own at in the upcoming Visual Interface Design session August 15-16.

Other interesting scoops this week

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.

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)

Have you ever used a public service that understood your needs? We all have horror stories of waiting in seemingly endless lines at the DMV or hunting forever to find the information we need on poorly designed city websites. Who is making sure that government uses effective design and technology to meet the needs of citizens in the 21st century?

Introducing Code for America

Code for America is a brand new non-profit that is taking on this challenge. And part of the challenge is understanding the target users of the technology. To help in that effort, Suzy Thompson and I taught a day-long workshop on Research for UX Design to the fellows at Code for America.

Code for America signage at their offices in San Francisco, autographed by the 2011 fellows

Code for America helps local city governments leverage the power of the web to become more efficient, transparent, and participatory. Built on a model similar to Teach for America, CfA encourages developers and designers to apply for a year-long fellowship, during which they will create open-source technology solutions for city governments. Out of over 300 applicants, CfA chose 20 fellows for their inaugural year, from a wide variety of backgrounds including Web 2.0 startup entrepreneurs, developers for local city governments and school districts, open source contributors, a researcher for the New York Times, a digital journalist, an intellectual property lawyer/programmer, and a museum exhibit designer.

Code for America 2011 fellows (image used by permission from Code for America)

Code for America Institute

The fellows are spending the month of January in San Francisco at the Code for America Institute, learning from guest speakers about a wide variety of topics, including treating government as a platform (Tim O'Reilly), building local communities (Danielle Morrill), being a change agent and nurturing social network communities (Caterina Fake), and taking an entrepreneurial view of their city projects (Eric Ries).

Host City Projects

Each of the fellows is assigned to one of four city teams, each with a target project:

The fellows will spend the month of February in their host cities, learning about the IT infrastructure and interviewing city stakeholders and users of their system. They will return to San Francisco in March to design and develop the open-source applications. They will present and hand-off the applications to their host cities in the fall.

Cooper Training

Because Cooper has extensive experience connecting user research to product design, Code for America asked us to come in and present a one-day workshop. From our courses on interaction design and design communication, we carved out a day's worth of materials on finding stakeholders and users, preparing an interview instrument, conducting interviews, debriefing interviews, and synthesizing and presenting research findings. We also gave them a look-ahead to personas, scenarios, and framework design.

The fellows got a chance to plan an interview instrument and conduct a 45-minute interview with members of the CfA staff. Conducting good ethnographic interviews takes practice -- I think the fellows came out of our workshop with a sense of confidence in talking to their city stakeholders and application users in February. I look forward to hearing about what they learn about their users, and to helping them create personas and scenarios from their findings. And I can't wait to see the amazing applications that result from their work.

Great Government Research and Design

A question to our readers: Where have you seen user experience design principles applied to government applications or services, to achieve an amazing outcome? At Cooper, we're currently working on a project with CalSTRS (California State Teachers' Retirement System), and in the past have done pro bono work with the SF Department of Health. I have also read about fellow Cooperista Renna Al-Yassini's service design work for the Roudha Center in Qatar. What user experience design work in the government or social service sectors has impressed or inspired you?