By Scott Berkun, May 2002

“How we get along is no longer an implicit fact; it’s an explicit imperative. Collaborate or the design suffers.”
– Clement Mok

For projects of importance, you need divergent skills to succeed. It is not possible to find an individual with all of the skill sets needed, nor would you want to. To create a first rate website or software product, you need many tasks to be done in parallel, which means that more than one person has to be working at them. As soon as two or more people are involved, the dynamic for how decisions are made, and how work gets done, becomes important. Any group of people can do work together, but it takes the right approach and team philosophy for that group to produce good work. Collaboration is critical in any creative pursuit involving groups of people, from film making, to urban architecture or even web and software development.

The parallels of film and design

Software development and film production have many similarities. Both involve large numbers of people, working on a limited schedule and budget, with the goal of producing something with unified values and presence. Different sub-teams, with specialized skills, are responsible for separate but converging aspects of development and production. Many project schedules slip. Unforeseen problems often arise. The quality of the result at the end is difficult to predict at the beginning. Millions of dollars may be at stake. Many projects are canceled. Although the contexts and skills are different, there are an outstanding number of connections to be made between these two industries. We can learn much by comparison with the older and more mature roles and processes in the film industry since many of the goals, problems and roles are the same.

Specific to collaboration, our muted conflicts of testers and programmers, designers and usability engineers, has a framework for comparison. Is cinematography more important than acting? Lighting more valuable than sound? The screenwriter more important than the director? Conflicts are natural where viewpoints converge, but success is the result of orchestration, not simply organization. Someone has to be capable of making tradeoffs that cut across disciplines, sacrificing certain things to enhance others, for the greater good of the entire customer experience. A good leader can do this with the support of each discipline, instead of against it. The goal is to achieve synergy of the different contributions, and not a domination of one over the other.

Elaboration on Collaboration

To collaborate in design and engineering requires being open. If you want a synergistic product, that has the highest quality customer experience, your team process has to change. It’s one thing to write a piece of code, and throw it over the wall to the test team. It’s another to open your process to them, and to figure out how you can both avoid wasted effort, and improve code quality, by examining how you both get your ends of the work done. The difference is beyond attitude. It’s in having the confidence in your own process, and your own knowledge, to allow someone else inside. If you can’t be open to making changes in how you work, how can you possibly expect someone else to be open to you? Someone has to lead the way in establishing this kind of higher dialog, and there is no reason it can’t be you. Start by being curious and open to other ways of looking at the work. Your value isn’t in how you were trained, or in some pedagogical mindset based only on your degree. Instead it’s in what new things philosophies and approaches you can add to surpass the limitations of what you were taught.

Collaboration happens as a result of both or all parties recognizing the interdependence of the work each party has. It’s in everyone’s interest to understand enough of how the other person works to make them more effective, because if you do this, the favor will be returned. To make this happen, start by meeting with one or all of your counterparts. Talk about your goals for the project, and find the ones that you share. If you are on a well managed team, there should be many. Within those goals, brainstorm about how you can help each other to be more effective in reaching them. Come with a list of things you’d like them to do, and also a longer list of things you’re willing to do to help them. The more generous you are when initiating change, the better your odds of success. You do not need the group manager to initiate this: you can do this today, by going down the hall and starting a conversation.

Of particular importance for interaction design is the teamwork among analysts and creators. Usability engineers, who lean towards method, and visual or interaction designers, who tend towards intuition, both share the burden of ensuring good interaction design. If their relationship and co-ordination is poor, no amount of design brilliance or methodological craftsmanship will save a project. It’s the partnership of synthesis (design) and analysis (usability) that makes great user experiences happen. Some product teams feel this relationship is so important, that they are unified into user experience teams, reporting to the same person, and co-locating their offices and resources. User experience design is about unifying aproaches, not segregating them.

Interaction Design comes from multiple disciplines

Point of view is worth 50 IQ points – Alan Kay

Imagine attending a conference on a Caribbean beach ( I can dream can’t I?). You walk along the sand, between workshop sessions, and find a stone at the crest of a wave. If you had a physics degree, you’d see the stone as an elaborate construction of particles. If you were a civil engineer, you’d consider it’s strength and tolerances for building. If you were an artist you might examine it’s shape, and the tone of its shades. Who is it that really sees the stone? The answer is none of them. Each perspective is accurate within the limits of one domain, but none of the individual views are complete. The true view of the stone encompasses all of the perspectives. It follows that the best decision about how to make use of the stone will come from the person that has the most awareness of the most perspectives. Or even better, the one person who can lead an effective dialog between each of the disciplines. (I’d vote for leaving the stone alone where it is, so someone else can delight in it.)

When looking at a software or web design, similar problems of perspective arise. A usability engineer, when presented with a design problem, may offer a methodological approach for examining the issue, hoping to use data to make a decision. A developer may see a potential code change, that eliminates the feature (and the problem) altogether. The designer might imagine two alternative prototypes that combine the needed elements in new ways. How is a decision made as to which approach to invest in?

With no collaboration, everyone might try their own approach in isolation, which potentially wastes resources. Someone or everyone has to be aware of the bigger picture, the picture beyond any one discipline.

On a collaborative team, each individual is not only aware of what their own domain can contribute, but is inviting and considering approaches from outside of their domain. Does the usability engineer ever ask the designer to make a recommendation? Does the designer ask the usability engineer for supporting data to help inspire their new prototype? Is someone keeping the developer informed, so that engineering dead-ends aren’t pursued? Someone has to lead that dialog, and make a cross disciple discussion take place. Without that kind of communication, the best ideas will not even surface, much less make a positive effect on the final design.

As film is to web design, the director is to who?

The missing part of my analogy is the role of director. Unlike film, the production of software and web sites is often driven by engineering and technical processes. Things are modularized, with limited provisions for building coherence into the customer experience. Some organizations manage this better than others, but often the equal distribution of power along equal sub groups, results in designs and experiences that are fractured and disjointed. Sometimes, each sub-team has it’s own designer, or usability engineer, but they work in the limited context of a single feature area, or are concerned only with the work of one small development team. Orchestration is done only responsively, as collisions and problems arise, instead of by plan or direction. Group managers pay more attention to schedule and the checklist of features, than to the design quality or the experience integration of the component parts.

Each discipline often wishes it was in the role of director. From information architects, to usability engineers, to interaction designers, everyone thinks that their discipline or background captures the true essence of the problem, and would be most suitable to orchestrate all of them. But what often is forgotten is the true breadth of contexts required that are part of the decision making process. Can the usability engineer make strategic business decisions? Can the designer make engineering decisions? Can the information architect make the right schedule and personel decisions? Cut the right features at the right time? Nothing in the training of any of these disciplines prepares them for these roles. There is a gap in the specialized training of these fields, and the generalized nature of project, group and business management.

As an example from web design, it may be the right choice to sacrifice some usability for an improved aesthetic. An ounce of enjoyment may be more important, in a specific type of product, than an extra ounce of ease of use. Sometimes the opposite tradeoff is appropriate. That kind of judgment call can not be made algorithmically, just as deciding to slip the schedule, sign a deal, cut a feature, or any of the other hard decisions that need to be made in managing a project. The film model is interesting again, since directors are often forced to make financial vs. artistic vs. market choices, and are responsible for the consequences. For those that consider project management devoid of design matters, what could impact a web design more than cutting a feature? or adding one? What could make a product more usable or desirable than deciding how the resources, including personel, are allocated?

In many cases, it is project management or team management positions that approximate the role of director, since all of the individual disciplines report to them, and they have some degree of schedule or resource management responsibilty. How much directorial power or influence they chose to exercise over creative or content choices may vary, but often they are the closest thing to a cross-discipline leader. Generally, project managers play an unglorified role, but in some organizations their contribution to the overal design is signifigant, whether they are trained for it or not.

For whatever reason, it seems uncommon in my experience for people from design or usability backgrounds to take project or group leadership positions within their organizations. It is not within the scope of these single domains as typically defined, and the theme of how to transition into these roles is uncommon in the books, essays, or conferences of any of these disciplines. The future of good interaction design may be hinged on the mainstreaming of people with our specialized backgrounds, into more generalized leadership roles. It is only there that they can ensure that creative collaboration and orchestration is performed, and by the right people. The future of good design might not be in design at all, but in bringing design into management and the leadership of our organizations.

Books for the interaction and film minded

The Director’s journey: The creative colloboration, By Mark Travis – How one director manages the relationships of key creatie talent in the process of directing. Easy to read, easily transferable to any colloborative and creative effort.

Making Movies, By Sydney Lumet – the director of 12 angry men, failsafe, and Network, describes his philosophy and approach to film-making. It’s written for film lovers, and is a great place to start for learning more about the craft, and the complexities, of making movies.

Film directing shot by shot, By Steven Katz – Somewhat technical review of camera and angle constructions in thinking about film, including storyboarding as a planning technique. Even just flipping through this book, you won’t look at movies the same way again.

Directing the film, By Eric Sherman – Collection of interviews with great filmmakers from the last century. It covers every aspect of film production, including the role of the director, scriptwriting, managing the set, everything. Outstanding constrasts from the masters in how different their approaches often were ,and it all relates to building and designing interactive systems.

Making Movies work : thinking like a filmmaker, By Jon Boorstin – Highly accessible book on how to approach the creative process. In some ways this book lends itself to interaction design more than the others.

---

Scott’s first book, the art of project management, will be published by O’Reilly in April of 2005.