Game Career Guide is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Get the latest Education e-news
  • Approaching The Challenges Of Team Design

    - Leszek Gorniak

  • Method #3: Don't give answers, ask questions

    Let's say someone is proposing an additional gameplay mechanics and you think it won't fit in the game. You can say: "This won't work. It breaks ... and ... principles we discussed earlier. It also complicates the ... tutorial and will have unforeseen consequences for the game balance".

    The main problem with that kind of answer is that it might put the other designer on the defensive. In that case, the other designer won't consider your arguments, but instead will focus on proving you wrong and defending the idea (I mentioned "fortifying" around one's ideas earlier). Of course, an experienced designer will cope with such feedback and respond in a more productive way. However, the reaction might also depend on someone's current mood, personal situation and so on. So why take the risk?

    Alternatively, you can respond by asking questions:

    • "Does this mechanics fit in our current design principles?"

    • "How can we adjust the game balance to this mechanics?"

    • "What should we change in the ... tutorial to introduce this mechanics?"

    This approach has two main advantages. Firstly, we put forward a valid problem statement. Defining a problem should always be a first step to solve it. Secondly, we don't put other person on the defensive. On the contrary, we facilitate a team effort in which we all work towards a common goal: looking for answers and either solving the issues (perhaps we will find out that the proposed idea actually fits in) or coming to a conclusion (together!) that the proposed idea won't work.

    For this approach to work, we need to agree that the questions asked are valid. Fortunately, agreeing on that is much easier than agreeing on actual design and implementation.

    This is one of my favorite team design techniques. I call it "question-driven design". By answering more and more questions we get more detailed game framework which we might eventually group into topics and convert into a Q&A style game design document that is quite straightforward and easy to read.

    Practical example: in one of the projects I took part in, we were having some issues with designing a combat mechanics for the prototype. I prepared a one-page list of unanswered questions, such as:

    • What are the possible scenarios of enemy encounters?

    • Do we want to have allied NPCs to fight on our side?

    • Are sneak attacks allowed?

    This approach helped us focus on actual problems and potential solutions and significantly enhanced the creative process.


    For the best results, the above methods should not be treated as separate, as they work most efficiently in synergy.

    They are interconnected, forming emergent relations and dependencies:

    • Asking questions is an effective approach for establishing the design compass

    • We need to listen deeply to see that someone else's design compass differs from ours

    • A clear design compass provides a great baseline for accurate questions

    • Last but not least, asking questions without listening to answers doesn't make much sense...

    As we learn to utilize the synergy of those three methods, we build another, way more important synergy, a team synergy. And, as Henry Ford said, "If everyone is moving forward together, then success takes care of itself."

    Thank you for reading.


comments powered by Disqus