“Working with researchers who are legendary game designers in their own mind”

A good serious game is inherently interdisciplinary. It requires multimedia artists, engineers, business people, content experts, behavioral scientists, designers, project managers, quality assurance experts, producers, administrators and members of the target audience to work together seamlessly to produce a product that combines engaging gameplay with learning goals. One of the biggest challenges facing the serious game team is overcoming the clashes (wars?) that inevitably arise when people from different backgrounds come together to collaborate. One clash that is particularly vexing for game designers is when they disagree with what a researcher proposes to implement as “fun” gameplay.

Problem: The researcher thinks they are a good game designer (but they’re not)

You may have a researcher new to working on games and they may offer some good gameplay ideas now and then. The problem is when the researcher starts thinking they are great game designers, particularly when they really want you to implement a game idea that you think is clearly atrocious. This issue absolutely needs to be managed. It can get very dangerous if you as a developer feel like you can’t disagree with the researcher. You may feel this way if the researcher is particularly dominating, arrogant, stubborn and narcissistic (not uncommon traits for researchers!). You may also feel uncomfortable voicing your opinions if the researcher holds the purse strings and you fear you may lose the job if you don’t implement every little detail the researcher wants. You may also have a personal motto of “the customer is always right” that, much to your dismay, the researcher is holding you hostage to.

Solution 1: Review roles and responsibilities

This problem can be avoided from the start of the project when you define the roles and responsibilities of each team member. The developer should be the master of the domain of “fun and engagement.” The researcher should be the master of the domain of providing a framework for learning goals but not necessarily the domain of exactly HOW those learning goals will be reached in gameplay. When you face this situation, you can gently remind the researcher of their role and responsibilities on the project. If you never clearly defined roles and responsibilities at the start of the project, this clash should be your warning signal that without further ado, this knowledge should be made explicit and agreed on by team members.

Solution 2: Review and confirm shared goals of the project

In addition to reviewing (or specifying) roles and responsibilities, you can also work on a resolution by reviewing the shared goals of the project. The goals will hopefully include some specification that the game must balance fun and learning. Project goals can also include scope and quality. The researcher’s idea could be outside of the core game mechanic and thereby require an increase in the scope of the project which could potentially compromise timely delivery of the final project or the quality of the game if the resources are inadequate to support the increased scope. By reviewing the goals of the project, you can direct attention to the shared goals of the project, rather than personal agendas or egos.

Solution 3: Determine the intention behind the suggestion and create options

In addition to reviewing roles and responsibilities and project goals, you can further ask the researcher to describe the specific learning goal that they were trying to reach with their suggestion. Were they trying to get the user to practice a key behavior? To feel a sense of reward and accomplishment? To observe a behavior? To face a key decision that will lead to some kind of insight? You can further determine if the researcher’s  suggestion was intended to address a primary learning goal or secondary learning goal. Once you understand what the learning goal of the researcher is and how important it is to him or her, you can work together to come up with options for other fun and engaging ways to reach that goal. And if the learning goal is secondary, you may be able to negotiate that development resources be focused more on primary learning goals for the game (and more engaging gameplay approaches).

Solution 4: Let the target group decide

If you try the above solutions and the researcher is still persisting on their clearly horrible gameplay idea, it is time to bring in the big guns: members of the target group. Hopefully, at the beginning of the project, everyone agreed that a goal for the game was that it must be appealing and engaging for the target group. Here is what you do if you are very confident that your idea is better than the researcher’s. Provide some nice sketches, storyboards, graphics, gameplay, whatever is feasible that represents the researcher’s approach to the problem and your approach to the problem. Have the researcher present both ideas to the target group to get their reactions. If possible, see if the researcher can get consent from the target users to have the interviews videotaped. This will keep everyone honest and focused on what the target group says.

Look at the videos and discuss the results together. I can’t guarantee you that the target group will support your idea but whatever they say, their words have power. I have found that everyone on the serious game team understands that the target group has some of the highest standards and expectations for an equal balance between a game that is fun and a game that addresses their learning needs. It is very difficult for anyone to go against what the target group says.

Conclusion

When a researcher you are working with seems to fancy themselves as a cutting-edge game designer and you disagree, there are steps you can take to work through this disagreement, further mutual understanding, and end up with good gameplay that supports learning goals. Specifically, you can review the roles and responsibilities of team members, confirm the overall goals of the serious game project, determine the researcher’s intentions behind their suggestions and create other options, and finally, let the target group determine what they like, if all else fails.

Clashes between team members can feel like they are the most difficult challenges in your serious game project. You may feel like you are talking to someone from a different planet at times. But you HAVE to work through the challenges to get to greatness. The genius of any successful serious game project is getting the absolute best out of every team member. It requires persistence and finesse to work through the problems to create a brilliant solution.

Recommended reading:

Fischer, R., Ury, W. & Patton, B. (1991). Getting to yes. 2nd ed. New York: Houghton Mifflin.