Start with the purpose, not the format

A common first thought is “we want a card game” or “something like a well-known board game”. The format matters, but it comes later. First, write down what should happen once people put the game down. Should they remember a message? Start a conversation about a topic? Practise a particular kind of decision? Get to know each other at an event? Define one main purpose for the initial brief. Too many equally important goals can make development harder.

Describe the players and the setting

The same content calls for a different game for primary school pupils, for employees at a workshop and for visitors at a trade fair. Note the age or role of the players, how many will play at once and how much time they will have. Describe the setting too: a classroom table, an exhibition stand, a meeting room or a living room at home. Will a facilitator run the game, or will people open the box on their own? These details often shape the rules more than the topic itself.

Show what you already have

If you have materials, attach them: learning objectives, texts, questions, your visual identity, or an existing game you would like to adapt. Say who in your organization approves the content and who will review it for accuracy. That makes it clear from the start which parts of the content you will provide and which parts the game developer will create.

Quantity, timing and constraints

The approximate number of copies affects materials, packaging and how the game is produced, so write it down even if it is only an estimate. Give the date by which you need the game and the reason for it, such as an event, the start of a school year or seasonal gifts. Add any constraints: language editions, accessibility for players with different needs, preferences about materials, or your organization’s rules on gifts.

How you will know the game works

Instead of promising an effect, set out signs you can actually observe. Do players understand the rules without a long explanation? Does a round fit the time you have? Does the conversation after the game touch on the topic that matters to you? You can check criteria like these while testing the prototype and improve the game based on what you see.

What a completed brief might look like

An illustration, not a completed client project: a company wants a cooperative game for onboarding employees. Four colleagues would play at a table for around 20 minutes. The aim is to discuss three everyday work situations. The company supplies examples and appoints a content reviewer; the developer proposes rules and a prototype. Quantity and timing are not yet confirmed. The first test checks whether instructions are clear and whether the discussion addresses the chosen situations.

A short template

  • Purpose: what the game should achieve or communicate.
  • Players: who they are and how many play at once.
  • Setting: where they will play and how long a round can take.
  • Materials: what you already have and who approves content.
  • Quantity and date: a rough estimate is enough.
  • Constraints: languages, accessibility, materials, organizational rules.
  • Signs of success: what you want to notice during and after play.

The brief will keep growing during development, and that is fine. What matters is that the first conversation starts from a shared understanding of the purpose.