Gamasutra: The Art & Business of Making Gamesspacer
How to be a Better Game Designer
View All     RSS
October 30, 2014
arrowPress Releases
October 30, 2014
PR Newswire
View All

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

How to be a Better Game Designer

January 29, 2013 Article Start Previous Page 4 of 4

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 phase of 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.


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.

Article Start Previous Page 4 of 4

Related Jobs

Grover Gaming
Grover Gaming — Greenville, North Carolina, United States

3D Generalist / Artist
Demiurge Studios, Inc.
Demiurge Studios, Inc. — Cambridge, Massachusetts, United States

Lead System Designer
DeNA Studios Canada
DeNA Studios Canada — Vancouver, British Columbia, Canada

Analytical Game Designer
Blizzard Entertainment
Blizzard Entertainment — Irvine, California, United States

Senior User Experience Designer, Irvine


Josh Sutphin
profile image
Having been in AAA design leadership myself, I must say: this is the strongest article I've seen on Gamasutra in years.

Bravo, sir. Bravo.

Randolph Heard
profile image
Why no mention of writers? Have you not encountered us in your work?

Nice piece otherwise.

Erin OConnor
profile image
O'Connor's RULE !

Luciano Lombardi
profile image
great read, thanks for sharing the article. Many useful advices

Noah Young
profile image
Thanks for this article ! As a starting Game Designer it's great and insightful advice :)

Phil O'Connor
profile image
@ Randolph: Yes, I have made several grave sins of omission, writers, LDs and marketing to name a few. My apologies! I have worked with writers, but only for a very small proportion of my projects. I guess I haven't learned enough about working with writers to recommend best practices in the article, just one more thing I will need to learn as writers become more and more important in the industry. I also did not mention level designers, but this is because I consider them the same as designers, perhaps this is old school, sorry to any offended LDs out there..... To all those marketing people out there, you are just as important, but I rarely work with marketing day to day during a project, and the article was mainly about daily working interaction with the team. Maybe there is a marketing person out there who can help with a suggestion on how they like designers to work with them?

@ Erin: "nec timeo nec sperno" :)

Thanks to all for your kind comments. They are much appreciated.

John Rose
profile image
This article has a little of everything! Well done, and thanks for sharing the wisdom of decades.

Anthony Buchalka
profile image
Thanks for sharing Phil. Although we have a relatively small team of 7, there are plenty of great tips here that we will start using immediately. Cheers.

Muge Arikut
profile image
My associate producer recommended this article and there are really lots of useful details for both of us here.
Thank you Mr. O'Connor.

Marvin Papin
profile image
The firsts 2 lines are enough and i totally agree.

Mark Sample
profile image
Really good article. Nicely done and no fluff... win!

Gregory Booth
profile image
"I hope this reads more of "learn my from mistakes" than "I am such an expert! Blah, blah, blah." "

God knows we have enough "experts" here on Gamasutra.

Your qualified opinions and experiences are a breath of fresh air!

Awesome article. Please write more!

Tray Epperly
profile image
Good tips. Thanks for sharing!

Francisco Javier Espejo Gargallo
profile image
Thank you very much for sharing. I've been on testing for 9 years and I miss our role there. As a QA Manager I always teach my mates to be close to the Lead Designer and know as much as him/her about the project.

For me it's the most important thing and I always though that we're crucial to anticipate design flaws and help the design team finishing a polished game.

Phil O'Connor
profile image
Indeed, yet another vital role that I did not include. QA is of course, essential to successful development, sorry for the omission!

Francisco Javier Espejo Gargallo
profile image
It's pretty uncommom to see designers willing to share their goals or objectives with testers, and I feel that they should be included on the team meetings and the discussions.

Please spread the word! :-P

Axel Cholewa
profile image
Great article!

A small addition for "Working with programmers". I recently read a very nice article (
k-order-hell) by Joe Houston (former Dishonoured programmer, now went Indie), and he advised programmers to approach problems "by getting into the skin of a game designer."

The other way 'round is also true: for communication with programmers, it's a great exercise to think like one.

Jeremie Sinic
profile image
Thanks for sharing! As an ex-producer, I praise your sound advice to game designers: producers are not the enemy :)

Tyler Gedeon
profile image
This is a fantastic article; thank you for sharing your experiences with us!

Abby Friesen
profile image
This article is great! It really shows how a designer is both a leader AND a servant to the team.

Christopher Stallworth
profile image
Wow excellent piece. My collegues and I are starting our own indie company and this article has helped me be able to clarify things and see that I have been taking the wrong apporach in some areas, which would have killed our project. I am the game/level designer for our company.....amazing!! Thanks Phil

Kain Shin
profile image

Jim Chen
profile image
Hi, Mr. O'Connor,

This article is great, most opinions of this list remind me some experience and mistakes I'd been through.
I am a game designer from Taiwan. I'm wondering if you can authorize me to translate to my native language, Traditional Chinese, to let more developers in Taiwan read your article and understand your great advice.

I will note your name and this page's URL in the translation. After I finish the translation, I will give you my blog's URL to check. Let me know whether you allow me to do and any other requirement.

Thank you so much! I learned a lot from this article!

Phil O'Connor
profile image
Mr Chen, thanks for the comments, absolutely go ahead and translate this article and share it. That is why I wrote it :) Any one else who wishes to translate and share the article has my permission.

Jim Chen
profile image
Thank you so much!
Here is my translation:

Kushal Yeole
profile image
Hi Mr. Phil O' Connor,

This article is great learned a lot......

Thank You for sharing....:)

Antonio Zapp
profile image
Thank you for sharing your experiences Mr. O' Connor. I'm coming from another "world" (electronic engineering) and I completely agree with your thoughts on the large discussion of team managing. Your considerations are valable on many fields (especially the general initial ones) not only in the game factory. It is really a good article.