Author: by Phil O'Connor

"Regardless of what kind of game you work on, design leadership is at the center of success or failure," writes design consultant Phil O'Connor, whose credits include Far Cry 3 and Operation Flashpoint 2. Here are some of his practical tips to help you become a better design leader.

"Good judgment comes from experience, and experience comes from bad judgment." - Rita Mae Brown, Alma Mater

A few years back I was inspired to write an article, How to Hire Good Game Designers, which Gamasutra graciously published. The positive response it received was surprising and inspiring, so here goes some more advice -- this time to my peers in the design trade.

This is not an article about game design techniques, however -- that subject is so broad and personal to each designer that an article would barely scratch the surface. In addition, my fun is not your fun; everyone likes different things, and as a good designer, you should be true to yourself. Trying to make someone else's idea (or "formula") of fun is rarely successful. I guess that, in itself, is my advice on game design technique: do what you know, follow your instincts.

The real point of this article, however, is how to be an effective design leader in a development team. This is just a catalog of my personal observations over the years. It is neither a definitive pronouncement on the subject nor a standard that everyone should try to reach; it's just a collection of personal lessons learned over the years. Take them or leave them in whole or in part, ignore them, share them -- do as you will.

I have been designing games for most of my life and 16 years in a professional capacity. I have never really considered design itself difficult. What I mean by that is, coming up with gameplay ideas or concepts for a game has been the fun part -- the easy part, I guess. What has been the difficult part of learning my trade is how to work in a development team, and specifically work with the different disciplines in development.

As a designer, you don't work in a vacuum. Everything you do affects other people's work on the team, and learning to understand that effect and how to be a professional is the key to successful design implementation. This is a collection of my conclusions on the subject after over a decade in entertainment software.

Regardless of what kind of game you work on, design leadership is at the center of success or failure. Every studio has their own approach to managing design work, but these recommendations should apply in most cases.

The key to being an effective designer is understanding that you are at the center of a workflow that affects all the other disciplines. Design decisions affect art, sound, technology, production plans, budget, and marketing. Assuming you have good design instincts, fresh ideas, and a creative capacity, the key to being successful as a design leader is first understanding the high profile that your work has in the team.

The first thing that should come to mind when you realize this is to have respect, or humility, as Kim Swift put it in a recent article. You are in a tremendously powerful and sensitive position; you are going to have a major impact on the success of this project without necessarily having authority in the team hierarchy.

And even if you do have that authority, it should rarely, if ever, be used. Respect the other disciplines and their role in the project. They are not there to execute your ideas; you are going to work with them to create something fun, together. You work for them as much as they may work for you. Nothing turns off a team more than an arrogant and imposing designer who throws out his "vision" in vague public speeches or voluminous documents and expects them to turn into concrete gameplay.

Once a team has lost respect for you, there will be resistance -- even if not overt or obvious. A team that does not feel like partners in the design process will question every decision, will remain pessimistic about gameplay choices long after they have been implemented, and generally drag their heels throughout the project. This kind of atmosphere ends up hurting everything in the game; things take longer to make, features that had potential will get cut because they go over budget, and finally the greatest buzzkill: overtime is never far behind...

This is not to say that the designer is responsible for everything that can go wrong in a project, projects fail for many different reasons, but the central role of your work puts you in a position to affect the delicate relationships between all teams, so be mindful of this situation and always act with the intent of earning the team's respect and trust in a long term way. How do you earn the team's respect? Here are some ideas:

Be prepared. Whenever you are meeting with other disciplines to discuss implementation, make sure you are prepared with the latest information, updated documents, and a set of possible solutions from design. Developers don't like doing your job for you; if asked for information on how something is supposed to work, don't throw it back at them and ask them to figure it out. Have an answer, or work something out based on information they provide.

If there is a decision to be made, understand the options and the consequences for each option and make precise choices. That means you should be an encyclopedia on the project, and this is easier for you as the designer to achieve, because you have more contact with all the different disciplines. You are somewhat of a central repository for what everyone is doing, so use that position to share and communicate the current state of progress on the project. This leads to...

Make decisions. Artists/animators, engineers and sound designers work according to precise schedules and budgets. They must produce assets at a predictable rate and give regular constant updates on the progress of this work. Nothing can upset this more than failure to make design decisions when they are needed, or making vague ones.

Designers have to provide concrete and hard information when discussing the asset requirements for features with the team. No design document will ever provide all the information necessary for these teams to work independently of your input. You must interpret the design for them, modify it if necessary due to the myriad technical or production related limits, and provide a final say when it is necessary to have that precision.

If you need to make a decision on the spot, make it, record it (by email) and stick to it. Nobody expects you to be right all the time, or even to have all the answers, but they do expect you to make design decisions. When you fail to do this, you introduce uncertainty and leave things up in the air. It's better to risk making a mistake than to not make a decision at all. And you will make wrong decisions; all designers do. Which leads us to...

Don't worry about being wrong. Some things that you thought were cool won't be in the final cut, and that is part of development. Don't worry about your ideas not working out in the end; worry about the game as a whole. Some of your ideas will fail for reasons that do not invalidate the idea itself.

It could be due to scoping issues, or a technical issue no longer making it feasible, another feature rendering it obsolete... Don't sweat about your precious idea getting rejected after playtesting; games are created in an iterative process, and you can only find out if something is really going to work once it is actually prototyped. Until then, it is just theory, based on your design instincts. Speaking of theory...

Don't let the document do the talking for you. The game design document is not a blueprint for making an awesome game. It is a set of theoretical choices on gameplay, with a theoretical fun final objective. It will change a lot during development, and new information will modify its content rapidly.

That doesn't mean there is no point in writing one; even if it gets changed often, you still need to start somewhere, and the first versions of the design document are critical to shaping the overall vision and strategy of the project. However, many people will interpret it differently -- one sentence will mean something totally different to another team member. Engineers may need more information to understand something that is perfectly clear to an animator.

The design document is the starting point of your collaboration with the rest of the team; it is not the final result of your work. Make sure that when you put out a design document for the team that you go over it with the relevant department leads and people working on that feature. Yes, this means that you must schedule a meeting before they start working, and go over the whole thing in detail.

It really helps if everyone at this meeting has read it beforehand. During the meeting you will get a flurry of questions about stuff that you thought was perfectly clear in the document; this is normal and, in fact, healthy!

It means that you were not precise enough for certain people or that there was an ingrained assumption about the feature inherited from previous discussions. This is what this meeting is designed to iron out, and get everyone on the same understanding about what exactly this design is trying to achieve.

It also allows you to solicit input from the implementation group on how to execute features. The meeting should result in clarifications and small changes to the doc, and you should integrate those changes as quickly as possible and update the feature doc for the participants to review as quickly as possible after the meeting -- memories fade fast.

That process turns the document from a draft to a Version 1, and you are now off to the races. Talking through the doc will save you enormous pain down the line, and gives the team the chance to shape the design and inject their own ideas. You want this to happen -- trust me. The best games come from this collaboration. You must be confident enough as a designer to...

Ask for opinions and take other people's ideas on board. Be open and willing to acknowledge better ideas from others on the team, especially ideas outside the design group. This does not mean design by committee, nor should you hold a massive brain storming session with the entire team -- this will just result in a mess and make you seem uncertain and indecisive.

You are the designer; you are being paid to design the game. It is your responsibility, but all the ideas do not have to come from you; in fact, the best games are the combination of all the best ideas from the entire team. If you manage this process properly, whereby you can keep the design coherent yet at the same time adapt good ideas from others into it, you will have much better game DNA.

If your process is insular and exclusive of outside input, you will end up with an inbred design. It may look healthy and whole until released into the wild; then its crippling flaws will become obvious. On the other extreme, if design decisions are made by a committee, you end up with a Frankenstein game that is basically everyone's favorite personal feature from their favorite game forcefully stitched together in a painful and unnatural way. It never works.

Managing that middle ground takes confidence and experience, but if you are designing what you know (as opposed to someone else's idea of fun) it will be easier to navigate this tightrope. And it is a tightrope, because opening the floor to design ideas can be tricky if you are not confident enough about your design and you start to see a lot of people suggesting alternatives.

If you understand what you are trying to achieve, then you will quickly be able to earn the confidence of the team by explaining your decisions and making them see why you made those choices. Remember that people outside of the design team don't spend all their time thinking about design issues, and so they don't have the big picture that you are supposed to have as the designer. It's easy for them to look at a single feature and come up with a "better" idea outside of the context of the entire game system.

This is an opportunity for you, not a challenge to your ideas. This is where you start giving them a hint at how complex and interwoven the gameplay big picture is, and how much you have a grip on understanding it. It's okay to not have the answer to all the questions that come up during development, but you should have a few scenarios, or options, in mind.

This process should be informal. People should feel free to mention ideas to the design team at any time, without any expectations either way. Make them understand that you are comfortable listening to ideas and that you won't consider such a thing a challenge to your work. Be open and friendly about sharing the design, and your job will be much easier. To manage that process well you need to...

Be objective about your own ideas. Just because you are the designer doesn't mean that you are going to have all the best ideas for the game. You will need a lot of help, and if you shut out others from being part of that process, you will lose a massive resource: the accumulated brainpower of the entire team! In order to cultivate that collaborative relationship with the team, you have to learn to tame your own ego. You must be honest about your ideas and those of others.

It's easy to get defensive, as a designer, when you have all the experience and the job title but someone from an unrelated department comes up with something that is frankly better than what you had chosen. You have to be able to honestly admit to yourself first that this is a good idea, and then vocalize it to the rest of the team if you think it fits with the overall game.

It's not going to make them lose respect for you; on the contrary, it will increase their trust in your decisions when they can see that you are being objective and leaving your ego at the door. Vocalizing it also important -- publicly acknowledging the merits and source of the idea is very important to earning the respect of the team.

If you take someone else's idea and secretly stick it into the design, you will have earned nothing but contempt on two levels, first because you don't have the honesty to admit when you are wrong, and second because you are taking credit for someone else's idea. Even if it's not true, and you had no intention of doing either, nothing will tank you reputation with the team faster.

Being able to honestly evaluate the merits of a design idea regardless of authorship is key to being a good designer; there is no way in hell you will ever be able to make 100 percent of the design decisions 100 percent correctly, so listen to the team! Objectivity is also important to the people who pay for all of this...

Respect the business. Game development can be complex because of the uneasy mix of business and entertainment. In some entertainment industries, this marriage is well managed due to decades of experience honing that relationship. Yet there are still spectacular failures in the movie industry, despite over a century of refinement.

Things will not change in game development any time soon either. Technology is one factor; changes in the business model and evolving tastes are others; mainly problems stem from the easy-to-unbalance relationship between the business and the game people.

One way that you, as a design leader, can help maintain that balance is to understand the factors that are at the foundation of your project: the business conditions. This is probably the most important skill you will need to be an effective leader in design. This doesn't mean that you need to get inside the numbers that management deals with; it just means that you should know the lay of land -- the strategy behind your project.

A good tactician understands what the prevailing conditions are at the strategic and logistical level. In dev terms, you should be designing within the budget, within the technology scope, and to the projected release plan. This is tricky; I have seen some designers become more a part of the marketing team than the dev team as a result of being too preoccupied with the sales strategy side of the job.

Don't try to do upper management's job, but at the same time be aware of their plan and expectations on budget, and let them know you understand it. They need to know you are objective as well as passionate. This really comes down to your features should fit the scope, whether it's a $500,000, $5 million, or $50 million game.

How to Work with Different Disciplines

As a final bit of advice, here are some lessons I have learned about working with different disciplines. I have found that these have helped me build a good relationship within each "culture" in development, understanding the work from their perspective goes a long way to earn their trust and professional respect.

Working with programmers. When working with programmers, keep in mind that they work in very precise and concrete terms. Whatever feature you have come up with, they will have to make it happen down to the smallest detail, and in doing so they will be carrying the design mantle that you hand off once you have outlined the feature.

Be precise when discussing implementation with programmers. Mathematical formulas are nice, if you can provide them. Provide feature lists with all asset requirements, exact details on mechanics and systems.

Point form information is best for this kind of documentation. Programmers don't like sifting through paragraphs of flowery language, backstory details and character bios when looking for the information they need to code. Provide functional diagrams, failure and edge cases, alternative implementation options, Plan B versions -- as much as they ask for or need.

Some programming teams want to get directly into the design with you. Great! Build a mutual understanding of the gameplay objectives together, then discuss nuts and bolts as they require. Be available to the engineering leads to work on stuff according to their needs. Don't just begin publishing documents as the mood strikes you; ask the programming leads to give you a work list that will satisfy their information needs according to their pipeline. If you can be Johnny-on-the-Spot with the information they need when they need it, you will be working together.

Programmers need to know that the information that you are providing is relevant to their current work; they don't want to sift through a large bunch of documentation looking for the information they need. Direct your documentation to their needs and at the level of detail they need, when they need it. If you cannot detail a feature because of a dependency on something else, then discuss the dependency and agree to a mutual plan of action.

This essentially means that you should be writing two levels of documentation: big picture level stuff that gives overall vision and scoping detail for general team consumption, and nuts and bolts design documents that are as direct and precise as possible regarding features and mechanics. Engineering leads may have a preference for the format and style of this kind of documentation; talk to them and find out what would suit them best.

Working with artists. Artists, modelers, and animators deal in aesthetics as well as concrete asset production. The important part for you as a designer is to not intrude upon their area of expertise -- the aesthetics, or simply put, the art.

When reviewing art assets or discussing art direction, don't become an artist. Make sure you keep your designer hat on, and leave the art to the artists. If they solicit your input on an aesthetic call, give your personal preference by all means -- but know that nothing turns off artists more than a wannabe art critic. If you have artistic training, great, make sure that they know you may have some basis for your opinion, but don't try to be the art director as well as the creative one.

If you want artists to be part of the design process, ask them for options and preferences and see if that works or fits the game. You want to cultivate their artistic sensibility so that they pour their best work into the game. If you criticize art choices based on personal preferences rather than what is objectively best for the game, then you shut them down as partners in the process.

When you ask for art assets, make sure that you get into stylistic dos and don'ts before they start working on them. Telling an artist that your game is not steampunk style after they made a character model is never going to win you points. Be clear about what the game is NOT about as well as what it is stylistically close to.

Some art teams want precise, detailed designs on all art related components; some teams want to be able to interpret the art needs from the design direction. Make sure you work with the style they prefer. If it is detailed they want, then detailed you give. If they prefer to be left to make assets according to their interpretation, then try to work with that and harness their creative talent while of course keeping it within the scope of the design.

Animators merit a special mention. Depending on how much animation your game uses, this is a crucial relationship. Animations have a huge impact on performance and the final appearance and polish level. It is easy to become overzealous in animation and break the memory bank, but if you go too cheap, your game will not compete visually. Finding that fine balance requires a close understanding between you and the animation team.

What is the minimum that your design can live with, and what is the "would be awesome" extra that would really give you more bang for the buck is a tough thing to work out ahead of time. Working closely with animation throughout the project is important to maintain that balance. Keep on top of animation design, make sure that the designers and animators are in agreement, and provide precise lists of requirements as the animation team needs. Make sure that the animators and gameplay designers are both working on the same page in terms of visual bang for asset buck.

Working with sound designers. Sound is psychologically a huge part of the game experience (right up there with the visuals). I go online and look for soundtracks of games that I played almost 20 years ago because they bring such a rush of nostalgia and good memories. There is something very primordial about sound, as far as its role in building emotional memory.

Your relationship to your sound design team should be such that you both understand what kind of mood you want to build in the game. You should pitch the design to them and ask them to pitch you music and sound effects that would match it. It's just like scoring a film, and just as important.

The best way to show them what you mean is videos and sound files. Once you agree on the atmosphere you want to create, then the rest should be relatively smooth. If you are providing dialog for them, or even directing recording sessions, make sure that you are open to changing things on the fly. Experienced sound people know what sounds right; don't be resistant to changing your script based on the sound designer's or voice actor's different interpretation of it. Something that looks good on paper may be totally silly out loud. Just like the other disciplines, be willing to make your stuff better with the creative input of those who have the experience to know.

Working with production. The production team is in a delicate position between the development team and upper management. Answering to both can be tricky, and brings a lot of stress.

A good production team should consider itself more a part of the development team than a voice of upper management. You, as the designer, can help make them feel part of the team by including them in your design reviews, implementation meetings and even some of your design team discussions. This may make you nervous of producers interfering in the design process, but good producers don't consider themselves designers and leave the designing to the people responsible for it.

The more they know, the better then will be able to help you. Keeping them in the loop gives them the information they need to feel on top of things. A good way to do this is regularly record major implementation meetings in note form and publish them to production in emails, if they can't have a production member present at each such meeting.

This way they will be able to represent the team's goals and direction to upper management in a way that is more transparent and in terms that are relevant to them.

When an upper manager can see what is happening on the shop floor more clearly, they put less pressure on production, which then flows down to the team. Producers are your boss, but in a more collaborative way than just purely subordinate-manager relationship. The producer is your ally; they will settle disputes between teams, mediate, make final calls, and drive things forward when they need to.

A good producer knows that all creative collaborations are full of differences in opinion and methodology; they avoid becoming a conduit for these tensions, instead keeping the politics and rivalries to a minimum, making calls for the good of the project, and quashing the rumor mill.

Let me share with you a possibly completely unrelated anecdote that I think illustrates what makes a good producer:

Michael Caine, one of my favorite actors, shared this little story in a recent interview. While he was filming Zulu, the movie that made him a star, he was quite nervous as an actor, and was not quite sure how to play the part of a British officer. He decided that to appear to have more authority, he should keep his hands clasped behind his back during his scenes.

It wasn't long before he began hearing rumors that another actor was complaining about his performance, that he "didn't know what to do with his hands." Caine became nervous and went to the producer, worried that he was about to get fired. When he asked the producer about the complaints, the reply was (and I paraphrase in this more polite version) "Well, you haven't heard anything about it from me, have you? Now get on with it." Knowing the producer was on top of things gave him the confidence to pour his energies into his acting and enabled him to give the performance of a lifetime.

Working with other designers. Working with other designers can be the hardest part of the job. Why? It's simple: designers are an opinionated bunch. They have such strong opinions that they feel compelled to turn them into games. They have opinions about all kinds of things and turning opinion into reality with a bunch of other opinionated know-it-alls can be quite tricky! Remind yourself that they are just as passionate as you are, and for the same love of games that you have. You are in this together.

Fun is a very personal thing. My fun is not necessarily your fun, and vice versa. You will not share the same passion for different kinds of game fun, so try to find the areas where you have commonality, and build that game. It is important not to seem to look down on other people's fun when discussing design.

Whatever your personal feelings, don't make it personal. That means that you will have to change and adapt as much as everyone else. If you really absolutely feel very strongly about a particular element of gameplay, then by all means argue it, pitch it, and sell it. But there is a big professional difference between fun and fanboy. Don't be a fanboy in design meetings. Stay passionate but be objective (I know I keep repeating this, but it is worth emphasizing.)

Don't shut down ideas because they are not your cup of tea; as always, remain objective and argue from the point of view of what is best for the overall game experience. And yes, you will have to argue -- not in the negative sense, but in a "lawyer making a case" sense. You should be able to explain the merits of your choices and decisions, test them against the opinions of the other designers, and validate them as a group. Experienced designers don't get bogged down into arguments on what color the character's hat should be; they fight the important battles and they argue rationally based on what is best for the game.

After the argument phaseof design discussions, then comes the decision phase. If the group can agree on a course of action, great. If not, the design leader must make a call, then move on. Either way, once the choice is made, do not keep picking away at it, and make sure everyone works to support the decision whether they initially agreed with it or not. Sometimes a designer is expected to come up with the idea, and sometimes they must follow someone else's. Make sure that everyone knows when the time for debate is over, and when the time to make it happen starts.

A little bit of creative tension is important for a healthy design team, but managing that is tricky. It is important to establish a clear design vision so that everyone is on the same page before discussing specific choices. You, as the design leader, must ensure you have provided that top-level framework that everyone's ideas should be directed to. Don't just start your design discussions with "we are going to make a painting", start with "we are going to paint a pastoral scene in the Romantic style. What should we put in it?" You also have to drive the design forward and make the final decisions if consensus cannot be achieved.

Another thing that is important to manage is consistency. Make sure you are saying the same thing to everyone and so is your design team. Don't get in a situation where your designers are contradicting each other in front of the other departments; it will just make you look like clowns and confuse the team. If the design team is not on the same page, you might be spending too much time meeting with the rest of the team than your designers.

Drive consensus and mutual agreement on features before you break out to work with the other teams. Designers can argue and debate in design meetings, not in implementation meetings. If you need to make a call, make sure you don't contradict that call later on. Nobody likes to throw work out. If you contradict yourself in the documentation, are vague, or don't give proper explanations for what you expect as an end result, the consequence is lost work and grumpy developers.

Once you have everyone working away on features and development is chugging along, be sure to check on your designers outside of the regular Scrum meetings, group updates, etc. Some designers end up "going native" when they work too long embedded in a cross functional team -- they end up pulling a Colonel Kurtz on you! Some of this is okay. You want them to bond and feel ownership, but keep the central design team meetings alive, remind all the designers they serve the greater game interest -- they don't belong to a feature "tribe."

Last piece of advice: if you are going to give a designer a specific feature or design task, let them do it according to their game instincts. Assuming your direction has been clear, don't back seat drive a design; if you are going to hand it off, let them make the decisions and then evaluate the end result. If you give them a task and they need your permission to make choices, you are not really giving them the task at all, you are just setting them up to fail.

Conclusion

I hope this reads more of "learn my from mistakes" than "I am such an expert! Blah, blah, blah." These lessons are personal to my experience with game development; they are not universal truths about design leadership awesomeness. As usual, experience is the only real cure for mistakes, but I hope that this small list has a ring of truth.