Een goed briefingdocument voor een serious game ontwikkelaar bevat minimaal zes elementen: een heldere probleemomschrijving, een concrete doelgroepanalyse, meetbare leerdoelen, technische en platformvereisten, een realistisch budget en een planning. Zonder deze bouwstenen kan een ontwikkelaar geen gefundeerde inschatting maken van scope, aanpak of haalbaarheid. In dit artikel beantwoorden we de meest gestelde vragen over het opstellen van een sterke game briefing, zodat je goed voorbereid het gesprek ingaat.
Welke informatie heeft een serious game ontwikkelaar nodig om te starten?
Een serious game ontwikkelaar heeft bij de start minimaal vier soorten informatie nodig: de aanleiding en het probleem dat de game moet oplossen, de doelgroep die de game gaat gebruiken, de gewenste leeruitkomsten en de randvoorwaarden op het gebied van budget, platform en planning. Hoe concreter deze informatie in het briefingdocument staat, hoe sneller een ontwikkelaar een passend voorstel kan uitwerken.
Een briefingdocument is niet hetzelfde als een volledig uitgewerkte specificatie. Het is een startpunt voor het gesprek, geen eindpunt. Toch geldt: hoe meer context je aanlevert, hoe minder tijd er verloren gaat aan achterhaal- en verduidelijkingsgesprekken. Denk aan de organisatorische context, bestaande leertrajecten waar de game op aansluit, en eventuele eerdere ervaringen met digitale leeroplossingen.
Praktisch gezien helpt het om je briefing te structureren rond drie vragen: Wat is het probleem? Voor wie lossen we het op? En wat beschouwen we als succes? Die drie assen geven een ontwikkelaar direct houvast bij het inschatten van de benodigde aanpak en complexiteit.
Hoe omschrijf je de doelgroep in een briefingdocument?
De doelgroep in een briefingdocument voor een serious game omschrijf je aan de hand van drie dimensies: wie ze zijn (rol, achtergrond, opleidingsniveau), wat ze al weten of kunnen (beginpositie), en in welke context ze de game gaan gebruiken (zelfstandig, klassikaal, op de werkvloer). Een vage omschrijving als “medewerkers” of “studenten” is onvoldoende voor een ontwikkelaar om goede ontwerpkeuzes te maken.
Concrete doelgroepinformatie heeft directe invloed op de spelervaring. Een game voor mbo-studenten in de zorg vraagt een andere toon, een ander tempo en andere game mechanics dan een game voor ervaren HR-professionals. Hoe specifieker je de doelgroep beschrijft, hoe beter de game kan aansluiten op hun belevingswereld en motivatie.
Voeg ook toe wat de doelgroep lastig vindt of waarom het huidige leeraanbod tekortschiet. Dat geeft de ontwikkelaar inzicht in de barrières die de game moet doorbreken. Informatie over digitale vaardigheden, beschikbare tijd en de mate van intrinsieke motivatie is eveneens waardevol.
Hoe formuleer je heldere leerdoelen voor een serious game?
Heldere leerdoelen voor een serious game formuleer je als meetbare gedragsveranderingen, niet als abstracte kennisdoelen. Een goed leerdoel beschrijft wat een deelnemer na het spelen doet anders dan ervoor, niet alleen wat hij of zij weet. Gebruik werkwoorden als “past toe”, “herkent”, “neemt beslissingen over” of “reageert adequaat op” in plaats van “begrijpt” of “kent”.
Het onderscheid tussen kennisdoelen en gedragsdoelen is cruciaal voor game-ontwerp. Een game is bij uitstek geschikt om gedrag te oefenen in een veilige omgeving. Als je leerdoelen alleen gaan over kennisoverdracht, is een serious game misschien niet de meest effectieve of efficiënte oplossing. Een goede ontwikkelaar zal je hierop bevragen.
Beperk je tot drie tot vijf kernleerdoelen per game. Meer dan dat leidt tot een versnipperd ontwerp waarbij geen enkel doel echt diepgang krijgt. Formuleer ook hoe je succes wilt meten: via scores in de game, gedragsverandering op de werkvloer, of een combinatie van beide?
Wat zijn de technische en platformvereisten die je moet vermelden?
In een briefingdocument voor een serious game vermeld je minimaal op welk apparaat en in welke omgeving de game gespeeld wordt (browser, tablet, smartphone, pc), of de game offline beschikbaar moet zijn, en of er integratie nodig is met bestaande systemen zoals een leerplatform of leerlingvolgsysteem. Deze technische randvoorwaarden bepalen in grote mate de architectuur en daarmee de ontwikkelkeuzes.
Denk ook aan toegankelijkheidsvereisten. Moet de game werken op oudere hardware? Zijn er specifieke eisen rondom privacy en gegevensopslag, bijvoorbeeld vanwege AVG-wetgeving? Voor organisaties in het onderwijs of de zorg zijn dit geen bijzaken, maar harde vereisten die vroeg in het proces helder moeten zijn.
Vermeld ook of de game meertalig moet zijn, of er specifieke huisstijlrichtlijnen gelden, en of de content na oplevering door de opdrachtgever zelf aanpasbaar moet zijn. Hoe meer technische context je aanlevert, hoe realistischer de inschatting van doorlooptijd en complexiteit zal zijn.
Hoe beschrijf je budget en planning in een game briefing?
In een game briefing beschrijf je budget en planning door een indicatieve bandbreedte te noemen voor het beschikbare budget en een harde deadline of gewenste opleverdatum te vermelden. Je hoeft geen exact bedrag te noemen, maar een indicatie helpt een ontwikkelaar om de scope realistisch te houden en geen voorstel te maken dat structureel buiten bereik ligt.
Budget voor een serious game wordt bepaald door meerdere factoren: de complexiteit van de game mechanics, de hoeveelheid content, het aantal benodigde iteraties, de technische infrastructuur en de mate van maatwerk. Door in je briefing te beschrijven welke van deze elementen prioriteit hebben, geef je de ontwikkelaar ruimte om slimme afwegingen te maken.
Voor de planning is het belangrijk om niet alleen de gewenste opleverdatum te noemen, maar ook de beschikbaarheid van interne stakeholders. Serious game ontwikkeling is een co-creatieproces. Als interne reviewers moeilijk bereikbaar zijn of besluitvorming traag verloopt, heeft dat directe invloed op de doorlooptijd. Vermeld ook of er harde tussentijdse mijlpalen zijn, zoals een congres, een studiejaar of een interne lancering.
Welke fouten maken organisaties het vaakst in een serious game briefing?
De meest voorkomende fouten in een serious game briefing zijn: een te vage probleemomschrijving, het ontbreken van meetbare leerdoelen, een onduidelijke doelgroep en het niet vermelden van technische randvoorwaarden. Een tweede veelgemaakte fout is het beschrijven van de gewenste oplossing in plaats van het probleem, waardoor de ontwikkelaar geen ruimte heeft om creatief mee te denken.
Veel organisaties starten een briefing met “we willen een game over onderwerp X” zonder te beschrijven welk leerprobleem dat onderwerp veroorzaakt. Dat dwingt de ontwikkelaar tot aannames die later tot misverstanden leiden. Een sterkere insteek is: “Onze medewerkers maken structureel fout Y in situatie Z, en we willen dat zij na de training beslissing A nemen in plaats van beslissing B.”
Een andere veelvoorkomende valkuil is het betrekken van te weinig of juist te veel stakeholders bij het opstellen van de briefing. Te weinig leidt tot een document dat niet gedragen wordt door de organisatie. Te veel leidt tot tegenstrijdige eisen en een briefing die probeert alles tegelijk op te lossen. Zorg voor een duidelijke eigenaar van het document en een beperkt aantal beslissers.
Wat is het verschil tussen een briefing en een programma van eisen?
Een briefing beschrijft het probleem, de context en de gewenste uitkomst vanuit het perspectief van de opdrachtgever. Een programma van eisen beschrijft de functionele en technische specificaties waaraan de oplossing moet voldoen. De briefing is het vertrekpunt voor het gesprek; het programma van eisen is het resultaat van dat gesprek, opgesteld in samenwerking met de ontwikkelaar.
In de praktijk verwarren veel organisaties de twee documenten. Ze leveren een briefing aan die al vol staat met gedetailleerde technische eisen, of ze leveren een programma van eisen aan dat zo open is dat een ontwikkelaar er geen kant mee op kan. Beide uitersten vertragen het proces.
Een goede werkwijze is om te starten met een heldere, beknopte briefing van twee tot vier pagina’s. Op basis daarvan voert de ontwikkelaar een verkenningsgesprek, waarna gezamenlijk een programma van eisen wordt opgesteld. Wij hanteren hiervoor een gestructureerde aanpak in de Power-up fase, waarbij we samen met de opdrachtgever een gedeeld mentaal model bouwen voordat de eerste technische keuzes worden gemaakt. Dat voorkomt dat je een uitgebreid document opstelt op basis van aannames die later niet blijken te kloppen.
Heb je hulp nodig bij het opstellen van je briefingdocument of wil je sparren over de aanpak? Neem gerust contact met ons op. We denken graag vrijblijvend met je mee over hoe een sterke briefing eruitziet voor jouw specifieke situatie.
