If you want to build great software, you can go it alone. You can design and build your product, make infrastructure decisions, manage releases, get the word out. Yet soon enough, if things are going well, you'll start to get traction, you'll want to scale, and your solo run will be over: You're going to need to work with others. You're going to need to create a team.

You'll find books and blog posts that will tell you how to create and manage a team, and they will include all sorts of helpful generalities. But I'll suggest a simpler framework for keeping the right things in mind: Think about your product team like a baseball team.

Nick Myers (Cooper) and David Bairstow (Thomson Reuters) are moderating a discussion on this subject at South by Southwest! Details here: Building Team Chemistry in Baseball & Technology.

Why baseball? Because both business and baseball are highly competitive, and baseball provides simple, clear object lessons for just about anything that you might confront in assembling a team -- how to spend money, how to evaluate talent, how to measure success. It's filled with vivid illustrations about teams that vastly underperform, teams that outperform, teams with rigid philosophies, teams that are fluid and flexible in their function. Most of all, baseball lays bare the fact that it is damnably difficult to create a highly functioning team. It's really easy to assemble a bunch of individuals who don't give a shit about anything but their own achievements; it's a lot harder to assemble people who are willing to learn, willing to work with others, and willing to do whatever it takes to win. A highly functioning team is not only about talent, not only about payroll, not only about organizational support, not only about leadership ... And yet it includes each of these things.

Find the right players

In baseball and technology, success starts starts with assembling good people. There's no way around this. If you don't have the right people, you're not going to compete. Ask the Kansas City Royals. They haven't had a perennial All-Star player since the 1990s, and they've only had one winning season since the mid-80s. (Disclosure: I am from Kansas City).

The challenge is not only to find great people, but to define who the right players are for your team. As longtime Baltimore Orioles manager Earl Weaver put it, "A manager's job is simple. Just pick the 25 best players for what he wants done" (emphasis mine). For Weaver, finding the right players meant finding players who could play a variety of positions in the field, which allowed him to employ a more situational, opportunistic style of baseball. It's not the only style of baseball, but Weaver worked it on the way to a World Series championship with a decade's worth of very competitive teams.

Fear conventional wisdom

If you're looking for someone to take the lead on a product, it's only natural to see the words "Product Lead, Apple" in a LinkedIn resume and say to yourself, "Let's give this one a call." Baseball executives used to do this kind of stuff all the time. They identified a conventional need -- "we need a big bat" or "we need a left-handed starter" -- and they go after a guy with that particular trait or great numbers.

Today's baseball executives evaluate players and positions with much more sophistication. They look for players who perform well in situations and environments that match their needs. If you're looking for a lead designer who can work across multiple product managers and scrum teams, you're going to need someone who can consult, cajole, and sell as well as they can design. The point is: Don't go after a big bat if what you really need is someone who gets on base. Get real about what's going to be needed to be successful in the role, and beware conventions and role names.

If you saw the movie Moneyball, you saw that the Oakland A's experimented with new methods of evaluating talent and performance. In the film, the team's scouts were portrayed as a group of grumpy old dudes who evaluated prospects with their guts, while the young guys in the corner uses "sabermetrics," baseball-ese for advanced statistics.

If you've ever tried to hire someone, you know how tempting it can be to use your gut: "Hey, she went to Stanford, so that must mean ..." Unfortunately, this method is doomed to failure, no offense to Stanford. Even more unfortunately, there's no sabermetric version of a person's career performance on LinkedIn. But the real lesson here is that the A's took the lingua franca of baseball performance -- player stats -- and applied it in a very different way to cut through the noise. So: What is the lingua franca of your category? What can you do to get beyond the traditional ways of evaluating talent?

Stay in your lane

Ever hired a dev manager who thinks he knows your business better than you do? Or a design director who can't stay out of the details? ... It's easy hire great people who don't know the boundaries of their greatness. Baseball is littered with cautionary tales of high-performing (and expensive) individuals who detract from the team because they're in the wrong lane, playing the wrong role. Conversely, the best baseball teams are characterized by players who know exactly what their role is, and who are employed by their managers in the right way.

Of course, people are often rewarded for ignoring the boundaries of his or her lanes. Steve Jobs never met a boundary he didn't ignore, which was part of what attracted great people to him. But how many Steve Jobses come around in a generation? You want team members with ambition and drive, but if you end up with people who are more driven by individual success or gratification than by the success of the team, you're going to have a harder time succeeding. Seek folks who want to be part of creating the Apple organization of your industry, rather than people who want to be the next Steve Jobs.

Identify your World Series

In baseball, the ultimate goal is clear: Win the World Series. Everyone knows this -- fans, players, coaches -- and it provides a very simple benchmark for evaluating overall performance. Your World Series should be a big goal, not simply increasing revenue 10% or landing a big account. It's a monumental achievement: an IPO; the millionth download of your app; becoming the market leader in your category.

It's okay if your World Series is unattainable today. In baseball and in technology, there are teams with no realistic shot at a World Series this year, or next. The task for teams like this is to establish a path to that ultimate prize. Most teams should be asking themselves: What's the first milestone on our way to the World Series? You need to win your division first.

Get lucky

Let's face it, there's no champion in the history of any sport that hasn't benefited from some moment of luck. The 2010 San Francisco Giants were on the verge of losing a critical game in the playoffs when the opposing second baseman experienced an utter meltdown in the field, making three catastrophic mistakes that allowed the Giants to escape with a win and go on to the World Series. Diehard Giants fans will recall the 2003 playoffs, when a critical error swung momentum toward the Florida Marlins, who ended up winning that game, and then went on to win the World Series.

So you could say that it all works out, but that's probably one of the areas in which technology and baseball are very different. If you're waiting around for your luck to change in product development, you won't be around for long.

What do you think? Join the conversation in Comments

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

Let's end this little charade

Our primary business tools can do better than asynchronous notes telling us that we've failed. Many of us set a variety of statuses during the course of a day, and good tools bring critical contextual information to us.

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

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

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

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

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

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

What do you think? Join the conversation in Comments

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

Finding the right reward model

Still, loyalty programs provide a good basis for understanding the basic levers of incentives and rewards, so we looked at existing loyalty programs to see what they brought to the table.

• The frequent flyer model — Participation -> richer experience — As a Premier Executive member of United Mileage Plus frequent flyer program, I can reserve exit row seats in advance, get a United representative on the phone quickly, and — best of all — board before the unwashed masses. The Ebay PowerSeller program is like this, from what I read here.
• The credit card points model — Participation -> cash — Most credit card programs (and frequent flyer programs) tread outside the strictly status-oriented realm. In most, an accrued currency ("miles" or "points") are exchanged for tangible goods (cash, flights, toasters, ShamWows). Amazon Associates, anyone?
• The American Express model — Participation -> Manufactured exclusivity — "Membership has its privileges." Amex marketing has taught us that simply using the card communicates a sense of status. There are many Internet translations of this. Invitation-only web services — Gmail, private torrent trackers, etc — use it as a way to predictably scale the system, but they also offer a certain cache to the users as representations of geek cred. The Yelp Elite Squad also appears to be more like this than like the PowerSeller program.

Leveraging status in the future

As the web becomes more vibrantly and dynamically social, concrete representations of status may become quite valuable (both to individuals and to businesses). The number of Facebook/LinkedIn friends you have, how often you successfully answer discussion forum questions, how many files you share, how many friends you pull in to a new service, or even how often you utilize online systems — all of these could be Internet versions of merit badges, airline frequent flier designations, etc.

At the same time, status seems to me to be a fairly tricky thing for businesses to trade on. As we all know, people's behavior with regard to intangibles can be exceedingly difficult to predict, and this behavior will likely change as technology continues to reshape expectations and norms. As businesses try to incent their customers with status, or (a natural extension) to assign value to certain existing status representations, I can imagine that people may be offended, or take evasive action.

So, the big questions: Are there other best practices around implementing status/affiliate/loyalty economies on the web? Are there appropriate ways for businesses to leverage this? Where is all this is going?

What do you think? Join the conversation in Comments

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

Scenes from Wednesday night's party at the Autodesk Gallery. More on Flickr.

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

Check it out, and let us know what you think. It's entitled "Designing the Form Factor and Interaction Framework," and it contains a discussion of the tools and techniques for generating and iterating design directions. If you're wondering what you're getting into, here's an excerpt from the Introduction.

Excerpt: Why this book

Every designer has the power to improve or even preserve life for some segment of humanity. Unfortunately, even the best designers can’t design everything, and good designers are in limited supply. I also know plenty of potentially great designers who simply don’t have the tools they need to make sure their designs see the light of day. This is especially true in our current digital age, when many design problems require the application of multiple disciplines, including interaction design, visual and information design, information architecture, industrial design, and more. Users have only one experience of a product or service, though, so this book attempts to include the perspectives and activities of all of these disciplines. (However, given that industrial design and graphic design make use of long-standing, well-understood methods, I have not attempted to address those disciplines in the broad sense, but only as they relate to interactive products and services.)

Although I love the ability to influence lives through doing meaningful design, I learned long ago that I can influence even more lives by helping other designers be more effective. My aim with this book is to help as many designers as possible make a difference in the world. Because designers cover a wide range of experience and skills, experienced designers may find that some parts of the content are merely useful refreshers. However, each chapter of the book includes content that I hope will:

• Help experienced designers be both rigorous and persuasive in their practice, to ensure not only that they’re doing great design, but that their design gets built
• Give designers from different disciplines a shared framework for collaborating on today’s increasingly complex products, which often combine software, hardware, services, and environments
• Help design students understand not only a coherent design process, but also the essential practices—from collaboration and project management to leading stakeholder discussions—that make real projects successful
• Show consulting designers how to engage with clients for the long term
• Help in-house designers see how consulting practices can make them more effective

Design is not—and never will be—a science. It will also never be a cookie-cutter process that anyone can do with an appropriate checklist in hand—the method doesn’t make the design, the designer does. This book cannot give you the imagination and aptitude for visualization, nor can it give you the judgment and mastery of craft that only come with experience. However, I hope what you’ll take from this book will help you more reliably design the right product or service, design it well, and get the design out into the world where it can improve the quality of human lives.

What do you think? Join the conversation in Comments

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

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

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

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

Check it out, and tell us what you think.

What do you think? Join the conversation in Comments

Kim, Suzy and I just got back from the annual conference of the Interaction Design Association (IxDA), interaction 09 in Vancouver, BC. Four days packed with ideas, insight, meeting new friends, and catching up with old friends; the program offered some intriguing speakers and provocative topics, and I'll highlight a couple here.


The keynote speakers played to packed houses.

Taking on big problems

Talk of sustainability often came up during the keynotes and the smaller sessions, and it seemed to be on the minds of many in attendance. Like other disciplines, interaction design is wrestling with the ways in which we, as a profession and as individuals, can do more than simply design more disposable crap. How can we design stuff that lasts, stuff that helps, stuff that addresses real problems? [Cooper took a shot at approaching these questions recently].

The opening keynote, by John Thackera of the Doors of Perception conference, took a sobering look at our prospects: (1) How quickly is the world going to hell in a handbasket? Answer: Very quickly. (2) Is this descent reversable? Answer: Not really. Current efforts are so far from being equal to the task. The focus of our efforts should be in finding ways to bring people together, to encourage and facilitate collective approaches to solving big problems.

Saturday's opening keynote by Robert Fabricant of frog explored recent work in sustainable design, pulling examples from the recent Greener Gadgets competition. He also talked through a case study of Project Masiluleke, a public health program addressing HIV testing in South Africa. The country hardest hit by AIDS, South Africa had experienced difficulty in establishing systems that appeared safe and confidential for testing. The project wove together a variety of interesting design elements — ethnographic research into the cultural forces at work, simple ways of using cheap mobile technology, and a distributed network of manufacturing testing kits.

Fabricant ended his talk with a very nice series of equations, and I'm paraphrasing here:

Our medium = behavior
Sustainability = a problem of behavior
Sustainability = our problem

Update: Fabricant's thesis — that our medium is behavior rather than technology — seemed a self-evident truth to me, but it spawned a bit of a tempest (in the tweet-pot). Fabricant posted some thoughts on the disagreement on frog's blog, Design Mind. Or, you can check out the slides themselves and form your own opinion.

Working together

Another recurrent theme was around collaboration — finding new ways to leverage the knowledge of a larger group without bogging down the design process. Leisa Reichelt put the free social web to work during the drupal.org redesign, using tools like Flickr, Twitter, and her blog to stay engaged with an active and involved group of stakeholders. Leisa wrote more about this on her blog.

Chauncey Wilson discussed ways to kick start collaboration in brainstorming by using metaphors, a topic that Alan would have appreciated. I particularly enjoyed the fact that he introduced me to a social psychology term for the inertial effect of too-large brainstorming sessions —social loafing. Also, thanks to Nathan Moody of Stimulant, who introduced me to "previz," an appropriately sci-fi-ish term used in the film industry, to better describe the kind of storyboarding that is useful for interaction.


Kim Goodwin delivering her keynote, "Each one, teach one."

Our own Kim Goodwin gave the closing keynote, an appeal to all interaction designers to do what they can to make more of us. She applied Anders Ericsson's 10,000-hour rule to interaction design, positing that it takes roughly 5 years of diligent work before a person attains mastery of a craft, and that academic programs, while necessary, are not sufficient to the task of creating the next generation of interaction designers. The experts among us need to make a conscious effort to mentor our junior colleagues, and in return for that effort, become even better at what we do.

At the end, I was exhausted, but I also wish I'd been able to see each and every talk. (I also wish I'd slept more. But I guess I'll have plenty of time to do that before next year's edition, interaction 10 in Savannah, Georgia). Thanks to the IxDA for another impressive installment.

What do you think? Join the conversation in Comments

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

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

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

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

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

What do you think? Join the conversation in Comments

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

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

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

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

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

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

What do you think? Join the conversation in Comments

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

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

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

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

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

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

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

What do you think? Join the conversation in Comments

Tolstoy said it about families, but it's true of teams as well: Every happy team is alike, but each unhappy team is unhappy in its own way. Where Tolstoy and I differ is that I think that there is much to be said for happiness.

In the design world, the idea of working in a "team" often provokes dread. Teams introduce overhead; they require communication; members often battle to see their ideas implemented. The end result of teamwork is often seen as compromise, i.e. as a "taco pizza," i.e. a situation in which everyone (including the customer) loses.

On the other hand, there are many examples of highly functioning creative teams, and my own experience tells me that a team approach can be vastly more efficient and effective than working solo. Who doesn't want a well-matched partner to ensure that the ideas flow, the problem is considered from all angles, and dead-ends are avoided? And lets face it — some of the most interesting and important problems are too big to solve alone.

At Cooper, we've spent a lot of time noodling on this problem, and we've got some ideas.

Wrestling at the whiteboard

Early Cooper design teams were born of necessity. Alan Cooper and Wayne Greenwood confronted big, complicated design problems, and together they pummeled the problems into submission. This pummeling, however, was not always reserved for the design problems. Both Alan and Wayne are prodigious generators of ideas, and this kinship sometimes led to conflict: Alan talked over Wayne; Wayne wrestled the whiteboard marker from Alan's hand. (One of the old design spaces was christened "The Yelling Room" for this reason).

Alan and Wayne have great energy for debate, but this sparring — though entertaining and productive for them — was unsustainable as the foundation of a consulting practice. They could never quite remember what they had agreed upon in previous meetings and needed help sifting through their ideas to make ready to present to clients.

Finding a thought partner

Alan and Wayne addressed their dilemma by hiring a person with a different skill set and disposition. As they explored various directions to find the perfect manifestation of interactivity, they needed someone who could capture the essence of the design to communicate it in a way that made sense to clients. So they hired a detail-oriented person with a tech-writing background, and they called this person the "Design Communicator" (DC).

As it turned out, the DC's narrative ability was an indicator of a deeper complement to the skills and disposition of the Interaction Designer (IxD). In order to compellingly tell the story of the design, DCs gravitated toward clarifying and synthesizing ideas and directions during design meetings, asking "What does this do?" and "How is this different?" and "Why?" and "Why is this good?"

The introduction of the DC initiated a Socratic dialogue within the team. The DC's questions exposed gaps and flaws, drew connections between concepts and ideas, and in doing so honed the designs, revealed opportunities for additional exploration, and ensured cohesion within the ultimate solution.

As the role has evolved in the 10 years since its inception, Cooper as an organization has continued to define the characteristics of the ideal thought partnership within the Cooper teams, seeking to support and encourage leaps of imagination while maintaining cohesion and rationality. (As Cooper grew and as the practice of interaction design expanded, three additional, equally critical specialties have evolved. As I'm trying to keep this discussion relatively simple, I'll save that story for another day.¹)

Naming the roles

Inside Cooper, the role names — IxD and DC — served as convenient shorthand for talking among ourselves about the nuanced, subtle qualities of potential hires and team pairings. We'd often ask things like, "Would this person be able to do the DC clarifying thing like Steve does?" or "Would that person be able to be the generative IxD in the way that Robert is?" We knew that both approaches and perspectives were essential to the practice of interaction design, and the role names simply stood for a host of intangibles shared by the individuals who exemplified the roles.

Still, this inside language got in the way of explaining our team structure to people outside of Cooper — candidates, students, clients, and even recruiters. Many people incorrectly assumed that the DC was the IxD's trusty scribe. (One recruiter told us that she never used the term "Design Communicator" when trying to find the kinds of people we wanted for the DC role; she always described it as a different kind of interaction designer.)

So, not long ago, we decided to find a more accurate way of referring to our interaction design pair.²

After much internal soul searching, and many deep, detailed discussions, we settled on a construction that exposed the similarity of the roles and a critical distinction. Because both are fundamentally concerned with interaction design (and because it is usually impossible to attribute the source of a design idea to one or the other), we used that term as the foundation for each role; because each has a distinct perspective, disposition and responsibility, we applied a primary difference as a modifier.

• The IxD role became "IxD: Generation"
• The DC role became "IxD: Synthesis"

We prepared the table below as part of the renaming effort; it lays out the axes of distinction in more detail. The two roles are as much about disposition and personality as they are about skills, as each Gen/Synth pairing brings a variety of complementary approaches to any given design problem.

Caveat: For the sake of keeping the table simple, I left out the other Cooper roles — the Visual Designer, the Industrial Designer, and the Engagement Lead.

	IxD: Generator	IxD: Synthesizer
Focuses on	Establishing the interactive structure and flow between a human and a product, service or environment.	Articulating and synthesizing the overall experience users have with the product, service, or environment.
Takes responsibility for	Driving the concept direction	Ensuring that the concept is coherent and satisfies user needs and goals
Leads during design meetings	Generating ideas toward a solution	Synthesis of ideas, defining the problem, clarifying the solution, explicating rationale
Expertise	Concept, visualization	Analysis, communication
Disposition toward creativity	Generative	Methodical, synthetic
Comfort zone	Invention	Evaluation, clarification
Approach to problems	Draw a picture, top-down	Tell a story, top-down
Advocates	Structure, flow (interface)	Cohesiveness, context
Thinks in terms of	Concepts, models, experience (screen flow)	Anatomy, relationships, experience (scenario)

Finding the right people

Still, how do you ensure that people with similar skills and interests will work well together?

You make sure that each team member knows and understands their responsibilities, that they enjoy giving up a little personal ownership for the benefit of others' perspectives and skills, and that they deeply trust the other team members to play their parts. Without those fundamental qualities, the team is likely to go the way of Tolstoy's unhappy families — division, mistrust, high drama. Good material for a novel, but bad for designing compelling products and growing a business.

Footnotes

¹ We've since supplemented the twin interaction designers with other equally critical roles. We've added the Engagement Lead, a senior designer who handles the business relationship, as well helping to keep an eye on the big picture of the design solution, kind of like a Socratic creative director. We've also added visual designers and industrial designers to the mix; consequently, a Cooper design team can consist of five people (or more).
² You'll notice that our websites still uses the old titles; we're working on this.

What do you think? Join the conversation in Comments