A Simple Technique to Prevent Fights in Design Meetings

Oct 1, 2015 | 0 comments

Designing games involves a lot of decision-making. What’s the game about? Who is the main character? Does the game have a story? What comprises the core game loop? How will the game be monetized? The questions you need to answer to complete your game can feel endless.

If you’re creating a game with a team, this often means you’re making game design decisions together. And where there are decisions, there are debates or even arguments as your team works their way through a problem and determines the best solution.

Sure, sometimes you get super awesome meetings where everyone agrees, the discussion is easy, everything is unicorns and rainbows, and then you get on with the day. It does happen!

But other times… A simple discussion turns into a heated argument, completely derailing the meeting. I’ve seen yelling, screaming, passive aggressive behavior, insults, and straight-up fights where there was a lot of words being thrown around but hardly any work being done. I’ll be the first to admit that I’ve been guilty of some of the above as well. (In my defense, that other designer totally WAS a stupidhead. But I digress.)

Arguments can take a toll on your team, impacting productivity and making people less satisfied with their jobs. How can you love what you do when the simple act of going to a meeting can become a stressful, all-out fight?

When your team doesn’t work together well, your end product suffers. This is very much a fatal flaw — I’ve not seen a single instance of a dysfunctional team releasing a killer product. So if your design meetings feel like a battle, this is something you’ll want to address.

As a design lead, there’s a really simple technique you can use to defuse arguments and help your team work together. It’s something you can start doing today, and something you can teach your team to do as well. 


Welcome to an Imaginary Design Meeting

Imagine you’re in a design meeting now with two designers named Amy and Bob. The goal of this meeting is to make a decision about a particular feature in the game, with the intent of walking out of the door after the meeting and following through on that decision.

For the purposes of this example, I’m going to use a feature we discussed very early on in the development of The Sims 4. At that point in time (2008), TS4 was to be a multiplayer, online experience, and we ran into a lot of complicated issues as we attempted to convert a single player experience into one that multiple people could enjoy at the same time.


So here’s our problem:

“Players enjoy using the Create-a-Style system in The Sims 3 to alter the color and pattern of every object in the game. At this meeting, we need to figure out if this is a system we can keep in a multiplayer game.”


Let the meeting begin!

Amy suggests a solution.

“Players are going to be expecting the TS3 experience to be carried over into TS4. So therefore, we need to have Create-a-Style, including the ability to upload custom art into the game. We shouldn’t change anything about the system at all.”


Bob interprets Amy’s suggestion as a poor idea, and then shoots it down before the discussion goes any further.

“We can’t do that. Allowing people to upload whatever they want? That’s a moderation nightmare! We absolutely shouldn’t allow players to customize EVERYTHING. We’d never be able to maintain the look and feel of the game world!!” (Outrage! Disgust! Horror!)


What happens now? Usually one of two things: the conversation either turns into a heated argument between Amy and Bob, completely derailing the meeting, or Amy is silent for the rest of the discussion, having been discouraged from contributing. In both of these outcomes, the idea is often never investigated fully and the tone of the meeting has completely changed — arguments can suck the creativity out of a room pretty quickly. 

Considering all options in a design meeting means suspending your doubts and concerns temporarily so that you’re fully able to participate in that exploration. Exploring ideas is really important. It’s essential to understand all sides of an issue before you can really make the best decision — you need to know what you are saying “No” to. This is easier said than done, of course.

However, there is a technique you can use to encourage your team to approach ideas with an open mind. It will also help you keep the meeting on track by preventing arguments and allows your team to problem-solve together. This technique has really simple structure with two basic parts.


Part I

When responding to a suggestion, first you say:

“Here’s what I like about that…”


Then, talk about what you like. Even if it’s a totally off-the-wall idea, there must be something you like about it. Whatever small portion of the idea you can get behind, focus on that. Don’t bring up any concerns or problems here, just focus on the positive aspects. This is really important! Only good stuff here.

This lets the person that shared the idea feel validated for their contribution, regardless of the outcome. By focusing on what works, you’re helping that person feel appreciated, and when someone gets positive feedback for sharing their ideas, they’re much more likely to do it again in the future.

And, if your designers are feeling supported and appreciated, they will do better work. Responding positively is a simple, “thanks for contributing,” that can go a long way in terms of productivity.


Part II

Once you’ve explained what you like about the idea, then you say:

“Here are our challenges…”


Any problems you identified when you first heard the idea, if there was a moment that you actually thought, “Well, that wouldn’t work because…” this is when you get to bring that up.

However, this must be done carefully and in a very specific way. It’s essential to frame the downsides as hurdles — things you must overcome — that are standing between you and your goal. If you do this right, what you’re conveying is, “if we can just solve these problems, this is a good idea worth consideration.”  And now you’ve turned an argument into a problem-solving session for your team.


Here's what I like... Here are our challenges...

And just like that, your design meeting becomes all happiness and rainbows.


The concept — simple. Remembering to do it, each time there’s a decision to be made? Harder. It requires you to think before reacting, and to carefully word your response. With some effort, it’s totally doable. It gets easier every time you do it.


Back to the Meeting

Let’s start over with our imaginary meeting above.


Amy suggests her idea.

“Players are going to be expecting the TS3 experience to be carried over into TS4. So therefore, we need to have Create-a-Style, including the ability to upload custom art into the game. We shouldn’t change anything about the system at all.”


This is it — your cue! Jump in right here before anyone can start an argument.


(“Here’s what I like…”)

“Amy, that’s a really good point. Sims players have very strong expectations of what the game they love is supposed to be like and we should keep that in mind. The Create-a-Style system is definitely a fan favorite, so we know that if we don’t carry it over, that may cause some upset in the community.”


This statement validates the concern that Amy has, so she will now be immediately receptive to what you have to say. And her concern is an easy one to get behind, because meeting the expectations of your player base is an important consideration for every development team. A designer considering the ramifications of changing a system in a sequel? Good designer, here’s your cookie.

Pause briefly, and then continue.


(“Here are our challenges…”)

“We have some problems we’d need to solve in order for that to work, though. Let’s talk through them. If we want to allow uploads of player-created content, we’d need to manage it in some way (moderation, opt-in mode for players, something else) because we need to ensure that our game world is a safe place for all players. I also have some questions. Do we need to retain the whole Create-a-Style system in order to meet player expectations? Which parts of the system are most important to players? Do we have any data on that?”


And so on. At this point, you have your team engaged in collecting the challenges and questions, which you can write on the whiteboard. Then you can use the meeting time to discuss the challenges and potentially find solutions for them.

If anyone drops into a “but we can’t do that” mode, pull them back out by reminding them that the exercise is about finding solutions. Ask them to stay flexible, and rephrase their concern as a challenge for the team to solve.


Problems = Challenges

I really like re-framing problems as challenges because completely changes the context and tone of the meeting. Instead of the discussion turning into an argument, you’re teaching your team to try to solve hard problems rather than fighting or giving up — not just accepting that they are impossible to solve. And that’s a good part of what game design actually is — working through really tough problems so that you can deliver the best, most engaging experience to your audience.

This process may help you come up with unconventional solutions to the issue at hand, or your team may discover that when everything is factored in (player desires, core features, budget, schedule, project goals, etc), there’s just not a way to make it work. If that happens, the exploration was still a great use of time — a stepping stone that helped you get to your final decision. You’ll end up in a place where everyone has a good grasp of the problem from all angles, and they understand why you’re going in the direction you’ve opted to go.

The best part about using this method consistently over time is that you can actually change the way you approach problems in a way that eventually becomes a habit. Being more flexible and open-minded in your thinking can make you a better problem-solver and an awesome collaborator, two must-have skills for a game designer.


Using it Wisely

Is this method bulletproof? Well, of course not — but I can’t think of one that is. Identifying the right time to use it is the key to success. Generally it tends to be better in situations where you have room to explore ideas, such as a project pre-production phase. If you’re in a scoping meeting where you need to discuss what feature you’re going to cut in order to get the game out the door on time… Well, it’s probably not right for that.

Either way, it’s a useful technique you can add to your arsenal, and over time you’ll learn how to wield it. As a bonus, it works surprisingly well in situations outside of design meetings. The next time you hear something you don’t quite agree with, try it!