On flowcharts in presentations

Game designers are often called upon to make presentations to their own teams, or to groups of executives overseeing their projects.

Great presentations and the great slideshows that accompany them, these are complex art forms of their own. Like many things, they can be learned but some lucky bastards just have it in their genes. Game design being a lot more complex than most people would like to admit, presenting it often requires a lot of trade-off between accuracy and entertainment. On the one hand, you want to paint a complete and precise picture of your game’s design and rationale; on the other hand, you don’t want to turn this into a two-hour long, dry, overly detailed mental torture made of 150 slides. After all, your audience wants to be made confident that you know what you’re doing, they don’t want to become designers on your team.

Game designers also have to come up with flowcharts. Some projects only require a couple, others seem to be made of flowcharts held together by other flowcharts.

So, not surprisingly, game designers are therefore expected to present flowcharts at one point or another.

flowchart_prez

Game design flowcharts usually fall in one of two categories:

  1. Game loops, mostly representing human processes
  2. Technical flowcharts, mostly representing software processes

Presenting game loops

When you present a game loops, you present the user experience. This represents what the typical users will do, not every detail of every interaction. Because of this, these gain from looking clear, even pretty. Their purpose is not to demonstrate that you’ve carefully thought of every option, but to help somebody understand what the game is about in less than one minute.

My tips for presenting game loops:

  • Make the flowchart easy to get. Give it recognizable shapes, like squares or ovals. Remember that the audience needs to understand the concept at large, not every nuance.
  • Simplify the flowchart. You don’t need to specify every step where the player can change his mind and backtrack. This would turn your flowchart into spaghetti. Again, stick to the typical loop.
  • Make it pretty. If you have more than one loop intersecting, use color-coding and shapes in the background to help your audience distinguish between each process. Get help from an artist too because well-picked colors can make a hell of a difference in many cases.
  • Be prepared for questions about the missing details. Chances are that someone will notice how simple your flowchart is and will want to challenge you on this. Usually, this comes from people who worry about bugs or poorly planned productions but unfortunately there are also times when this is just gratuitous trolling.
  • Know your audience. Depending on who they are, what they like best, be prepared to disregard anything I’ve written here.

Regarding this last point, I know some executives who like to see game designers as masters of an arcane art form that puts them in a category above the rest of humanity. If this is your audience, chances are that they expect to see complex, interweaving flowcharts that make them feel like you have access to a body of knowledge that’s way too complex for most people.

Presenting technical flowcharts

Technical flowcharts are what production teams, and especially software engineers will base their work on. They represent computer processes and how they interface with the users. They are especially useful, even unavoidable, when representing menu navigation. Because these flowcharts are used in production, they have to be 100% accurate and no detail can be overlooked. Therefore, they often look like spaghetti because that’s just how they have to be.

My tips for presenting technical flowcharts:

  • Don’t do it. Whatever you are attempting to communicate, a flowchart with multiple paths will trigger two possible reactions: Instant complete boredom, or careful analysis. In either case, you’ve lost your audience. One guy will start to check facebook on his smartphone, while the other will keep looking for mistakes long after you’re done talking and you’re ready to move on.
  • No, really, don’t do it. No matter how you had planned to breeze through your presentation, someone will ask you to “walk us through this”. You’ll end up describing every possible path, which is a tremendous bore. I said earlier that presentations are an art form; well, narrating every possible path in a flowchart is the equivalent of what that Spanish lady did when she painted over a portrait of Jesus Christ in a church.
  • Present the effects, not the system. Stick to what’s interesting to your audience. Stick to key facts. Instead of presenting a flowchart, present bullet points describing its effects.
  • If you really have to do it, dumb it down. See the rules regarding game loops. Make a “presentation version” of your flowchart that sticks to these guidelines. Make it good looking, straight forward, and easy to grasp.
  • Take it offline. If members of your audience want to see your production files, offer to share them by e-mail or to organize a separate technical meeting. Then, make sure to make the meeting invitation as dry as possible so that only the relevant people will show up.

Example: a login process

fake login flowchart-01

fake login flowchart-02

The two slides above contain the same information. Which is the clearest?

 

Conclusion: Pitch or spec, not both

There are documents meant to pitch ideas and documents meant to give instructions for a production. Make sure to know which is which. In fact, a clear sign that a studio has a dysfunctional design culture is when people outside of the production team get to review the production documents. Pitch documents are meant for anyone and everyone. An HR person from across the globe should be able to read and understand any of them. On the other hand, your production specs are meant for no one outside the production team. If this happens on a regular basis, it’s a very troubling sign of lack of trust. This lack of trust may be warranted or not but either way, it’s a sign of things gone wrong. Depending on your workplace, an unhealthy management of production files may be a sad but unavoidable fact but remember that, as a designer, how you present your work can affect the way people will choose to interact with it.