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.

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.

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

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

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

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

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

A student sketches design concepts for the mobile experience.

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

Thank you Globo, and thank you Rio!

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

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

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

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

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

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

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

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

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

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

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

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

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

As a business person, you may consider your software to be an operational tool, part of the sales or operations of your organization. But to your customers, it is a pipeline to your corporate soul. The behavior of your software indicates what is really valuable, what is truly important to your company, and there is really no way to hide.

Websites let your customers access your products and services, but as a side effect, they also access your corporate values. If your website is clumsy or slick, easy or confusing, it tells them a story.

Most clients hire Cooper to solve superficial problems. When they first approach us, they ask us to help make their websites “be more friendly” or their software “easier to use.” Sometimes they just want us to “make it pretty.” In every case, we find that hard to use, unfriendly, or even just ugly software is a symptom of deeper problems within the organization.

Over the years, client organizations have taken this advice to heart, with more and more forming user experience teams that focus on assessing and meeting user needs. However, just having a seat at the table is not enough. As designers, we can help shape and facilitate the overall conversation.

To bring designs to fruition, designers need to collaborate effectively. While technologists and business executives value design, they often sense that design decisions are subjective and arbitrary. To get buy-in, designers need to help their partners understand design rationale and decision-making. Through collaboration and communication, designers can ensure that all team members have a shared understanding of the stakeholder objectives, the user needs, and the intent of the design.

Cooper now offers “Design collaboration & communication,” a course that sets the stage for collaborating on design and communicating design decisions. In two days students learn how to involve others throughout the design process, so that the design vision is agreed upon each step of the way. Communicating design throughout the process reduces the likelihood of other team members misinterpreting or altering the design during development.

The course covers the following topics:

• Designing workshops to conduct with stakeholders to ensure a shared product vision
• Choosing appropriate research methods
• Involving others in research synthesis
• Prioritizing what should be built based on business objectives, technical constraints, and user needs
• Articulating the value and benefit of design decisions
• Defending design without becoming defensive
• Determining the right level of documentation for your development process
• Moving the discussion from features and functionality to user goals and business goals

Whether you follow a traditional waterfall model or an agile development process, the communication and collaboration techniques in this course can help you gain buy-in for your design decisions.

This course provides great techniques for designers who want to create buy-in and build credibility within their organizations. The course is also great for cross-disciplinary teams of designers, product managers, and developers who want to communicate more effectively.

Our next public offering of this new course is July 25 & 26, 2011 in our San Francisco studio. A Cooper designer can also deliver the course at your office, and the content can be tailored to fit your particular needs around design planning and collaboration.

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.

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?

We recently hosted an open studio, with presentations about using social media for social good from Jennifer Aaker, co-author of The Dragonfly Effect, and Robert Chatwani, social media innovator and Head of Global Citizenship at eBay. It brought together over 100 people in laughter, tears, and inspiration. Throughout the evening, designers and organizations came together to explore how they could use social media for a variety of initiatives, such as forest preservation, energy conservation, and education. We've posted a few photos here, and we wanted to express our gratitude to the speakers and all in the community who took part.

Designers, social advocates, entrepreneurs, and developers chatted and mingled early in the evening

Robert shared his story about Sameer Bhatia and Vinay Chakravarthy, two friends diagnosed with leukemia

Jennifer spoke about the meaning of happiness, social media, and storytelling

Robert highlighted ways corporations with authentic, core social values that can still be profitable.

The evening was a great success and left many energized and inspired

In case you missed the evening, Robert's original talk at the Stanford Business School is available to watch on YouTube: part 1, part 2, part 3.

Jennifer Aaker and Andy Smith are participating in several upcoming events and you can learn more about their book, The Dragonfly Effect, via their blog.

Our desired outcome for the event was not simply to inform but to encourage people to act. We highlighted a few opportunities for designers, developers and entrepreneurs to use their skills for social good but hope to share a broader scope of ways to get involved in the near future. If Robert's talk about Teams Sameer and Vinay illustrated anything, it's that each of us can have a large global impact given a clear, focused goal.

Thanks everyone for their interest and involvement in our open studio, and we'll keep you posted on our events in 2011.