Unless you’re making a game for yourself and no one else, you’ll have to present your ideas to other people. In many cases they’ll be decision makers like clients, publishers, or teammates. Presenting works in progress or pitching new ideas can, and should, look very different depending on who you’re presenting to. Knowing who your audience is can make or break your pitch.

Getting super technical and using industry jargon is going to scare someone like a client who doesn’t have a lot of game knowledge, and can slow down the process. But glossing over details and only showing finished work is going to raise red flags for experts trying to make informed decisions.

It’s not a good use of development time to constantly be making and re-making different versions of presentations. Luckily there are a few things you can easily and quickly adjust based on the audience that make a huge difference.

References

It’s always helpful to have references, no matter who you’re talking to. The trick is finding common ground. If you’re working with people who play a lot of games this will be easy. You can say “It’s like the stamina system in Breath of the Wild” and they’ve got it. But not everyone is going to know all of your references.

Try to have a conversation specifically to find your common ground before presenting anything. I’ve worked with many people who tell me they have no game knowledge and won’t be able to discuss games with me, only to find out that they loved The Sims as a kid and still play Candy Crush. That’s more than enough for me to be able to say “We’ll fake the timer, the way a full day is only about 5 minutes in The Sims.” or “We want it to feel more satisfying, like how the bursts pop out when you make a good match in Candy Crush.”

The references don’t always have to be game related either. Even if you’re working with people who would understand all your game references, sometimes you don’t want to draw the comparison. Try adding some that aren’t as one-to-one, but are still very common. For example, I’ve used things like “You can scroll through options, like when you’re looking for something on Netflix.”

Images

Images are pretty mandatory, no matter who you’re talking to. Not everyone can visualize well, or does it in the same way. It’s too easy to talk past one another believing you’re on the same page.

You don’t need to have a beautifully rendered image every time you present an idea. In fact that can often get in the way. Many times I’ve made a detailed mockup, and then the entire meeting was taken over talking about the details of color or fonts that weren’t important at all. Using images from your references will often work just as well, but if you can’t find just the right thing,try making a simple wireframe. Use gray scale. Only add detail to the parts you want to talk about. Anything that people can point at while talking will be a huge help.

It’s not just what images you’re using that makes a difference, it’s how you talk about them. With someone more experienced you might be able to show them an image, point to one or two things, tell them what to ignore, and they’ll be set. But if you really want to make sure the other person understands, walk them through it. Give them a scenario and speak everything you’re doing out loud. For example,

“I’m in the middle of a fight, I take damage, now my eyes are going to move from the middle of the screen where my character is, up to the corner here so I can check my damage and then back down”.

That example might seem super basic, but think about how you can use it. You might be having a conversation about how much UI is too much clutter on the screen, or about how often a feature is actually used. Concrete examples with your images can make something click, or open the door for a much more productive conversation.

Options

When multiple people are involved in making a final decision, it can get messy. How many options you present and the way you present them should be tailored to how many deciders you have and their backgrounds.

If you’re working with a small group who are all very familiar with the possibilities and scope of the project, you can present lots of options and it can be a more fluid conversation. If you’re working with a larger group, or with people who aren’t as familiar with the development process, you’ll want to lock down the conversation a bit. This isn’t to shut them out, but to make the conversation more productive. In my experience, the magic number is three. Try to name each option, even if it’s only “Option 1”. The names make it easier for people to communicate and give each option a weight and sense of importance. You don’t want it to seem like you’re just throwing ideas at the wall.

No matter who you’re talking to, be honest about your own thoughts. You don’t have to say “I hate Option 2, if you pick it I’ll be mad.” Though depending on the audience you can. It’s very helpful for most people to hear your thought process. Think of it as showing them all the experiments you ran. For example, “Option 1 is what my first instinct was, then I made Option 2 to explore another direction. Option 3 is closer to Option 1 but without the secondary feature.”

If you have a strong opinion and really want them to pick a certain option, you can tell them! You just need to walk them through your thought process clearly. People can tell when you’re only showing options because you have to, and it doesn’t feel good. Without seeing multiple options how would they be able to have your level of certainty? You don’t want anyone to feel bullied.

Changing just these few things about how you present your ideas can make a huge difference in how you pitch or review goes. Just remember, you’re working with your audience, it only makes sense to accommodate them in the best way you can. You just might want to send them our blog on how to give a productive critique before the meeting.