Over de afgelopen Jaren hebben we één aspect van onze games steeds belangrijker zien worden. De mogelijkheid om op een betrouwbare manier te kunnen zien hoe de speler interacteert met onze games. Om hierin te kunnen voorzien, bundelen we we onze games vaak met een online dashboard.

In dit artikel gaan we de diepte in over hoe deze dashboards onze games aanvullen. We lopen ook door het ontwerpproces heen die we hanteren om data op de meest efficiënte manier te visualiseren.

Een op maat gemaakt dashboard

Bij de start van de ontwikkeling van een nieuw dashboard, beginnen we met het definiëren van de doelgroep en wat ze uit het dashboard willen halen. Dit is meestal een combinatie van de volgende 5 groepen:

1. De Klant: Om inzicht te krijgen hoe de game ze helpt hun doelen te bereiken en om uit te vinden hoe de game het doet in termen van speler retentie. Het dashboard dient meestal ook om licenties te managen die aan gebruikers verstrekt worden.
2. Het ontwikkelteam: om inzicht te krijgen in hoe spelers interacteren met de game om er zo achter te komen hoe de mate van betrokkenheid van de spelers verhoogd kan worden.
3. De domeinexperts: Om inzicht te krijgen in de resultaten van de game en de impact die het heeft op de spelers om zo de effectiviteit van de game te valideren en te verbeteren.
4. Coaches en trainers die de game gebruiken met hun studenten: Om inzicht te krijgen in de prestaties van individuele studenten en ze persoonlijke begeleiding te geven.
5. De spelers: om uitgebreide inzichten te krijgen over hun eigen gedrag en lessen die ze leren uit de game.

Elk van deze groepen wil antwoorden op verschillende vragen van het dashboard. Maar uitvinden wat deze vragen zijn, betekent ook de juiste vragen stellen aan hen.

De juiste vragen stellen

Tijdens het praten met mensen uit de verschillende gebruikersgroepen, zelfs als ze onderdeel zijn van het ontwikkelteam, blijkt dat ze vaak een duidelijk idee hebben van wat het dashboard zou moeten laten zien. Mensen laten ons vaak kleurrijke taartdiagrammen zien, of verrassen ons met een uitgebreide lijst van data die ze graag willen zien.

Maar wij beginnen liever met ontwerpen vanuit een ander perspectief. In plaats van focussen op data en hoe je deze het beste kan laten zien, vragen we onze gebruikers liever welke doelen ze willen behalen met het dashboard. Als een gebruiker ons vertelt dat ze graag de duur van een sessie willen zien, vragen we ze ‘waarom?’.

Dit leid er meestal toe dat ze uitleggen waarom ze bepaalde data willen zien. Bijvoorbeeld in het geval van de duur van een sessie willen ze heel graag zien of een speler de game leuk vindt. Dit leid er weer toe dat wij aanvullende en soms compleet andere meetgegevens identificeren die kunnen helpen bij het beantwoorden van die vraag.

Om deze doelen en subdoelen te identificeren, gebruiker we het volgende ‘User story’ format.

<Role> should be able to <Feature> so that <Result>.

Door de functionaliteiten op deze manier de documenteren, heeft het ontwikkelteam de creatieve vrijheid om de beste manier te bedenken hoe het genoemde resultaat gehaald kan worden. Hierbij in acht nemende alle kleine details die naar boven komen bij het realiseren van een functionaliteit. Door de rol de specificeren, maken we direct duidelijk welk type gebruiker toegang krijgt tot bepaalde functionaliteiten: een must voor privacy.

Definiëren van de data

De volgende stap in het ontwerpen van onze dashboards is het definiëren van de data die we gaan bijhouden. Wanneer we bepalen naar welke data we willen opslaan, kijken we naar grofweg 2 categorieën: gedrag en prestatie

Het verschil tussen deze 2 categorieën is dat de categorie gedrag omschrijft hoe de gebruiker interacteert met de game, in contrast met de categorie prestatie waarbij wordt omschreven wat het resultaat is van die interactie. Bijvoorbeeld: de duur van een speelsessie is data over gedrag. De hoogste behaalde score in die sessie is data over prestatie.

Het onderscheid wordt belangrijk wanneer je probeert antwoorden te krijgen met deze data, want de data vertelt ons heel verschillende dingen. De hoogste score van een speler zegt ons niet echt iets over hoeveel de speler is betrokken bij de game. Evenzo zegt de duur van een speelsessie erg weinig over de moeilijkheidsgraad van de game.

De combinatie van deze 2 types data, geeft ons de mogelijkheid om interessante vragen te beantwoorden. We hebben bijvoorbeeld beide types data nodig om de volgende vraag te beantwoorden: ‘Hebben spelers die de interesse in de game verliezen ook eerder lagere scores?’. Als dit zo is, kan het zo zijn dat de game te moeilijk is of niet goed uitgelegd wordt. Deze conclusie stelt ons in staat om beter geïnformeerde ontwerpbeslissingen te maken tijdens de verdere ontwikkeling van de game.

The combination of these two types of data allows us to answer interesting questions. For example, we need both types of data to answer the question “Do players who lose interest in the game quickly also have low scores?”. If so, the game might be too difficult or poorly explained. This conclusion would allow us to make more informed design decisions during continued development of the game.

De grootste les hier is dat je idealiter data van beide categorieën wil verzamelen, aangezien je dit nodig hebt om bruikbare conclusies te kunnen trekken waarop gehandeld kan worden.

Meetgegevens verzamelen

Vanuit het oog van de gebruiker is het dashboard dat wat je ziet in je browser wanneer je op de inlog knop drukt. In werkelijkheid bestaat het volledige systeem uit drie verschillende delen:

1. De game integratie: Het verzamelen van meetgegevens begint bij het meten. Dit lijkt misschien vanzelfsprekend en eenvoudig, maar het blijkt meestal een stuk ingewikkelder dan gedacht. Wanneer gewerkt wordt aan dit deel van het dashboard, moeten we er zeker van zijn dat de integriteit van de data gewaarborgd wordt, terwijl internetverbindingen onstabiel of afwezig zijn voor langere tijd. Om dit op te vangen, slaan we statistieken lokaal op het apparaat van de gebruiker op totdat er een mogelijkheid is om het naar de server te sturen. Om het nog ingewikkelder te maken, willen onze gebruikers ook op verschillende apparaten kunnen spelen. Meestal lossen we dit probleem op door slechts 1 actieve sessie toe te staan en de gebruiker automatisch uit te loggen van de oudere sessie.
2. De backend: Wanneer het dataverkeer de server bereikt, moet het worden gevalideerd en geschikt worden gemaakt voor opslag in een database. Deze problemen zijn al eerder opgelost, dus zoeken we naar een bestaand framework die ons hierbij kan helpen. We hebben eerst verschillende opties onderzocht voor het opslaan en presenteren van game meetgegevens, zoals Unity Analytics. Maar deze frameworks laten meestal niet genoeg maatwerk toe, werpen twijfels op over privacy vanwege de locatie van hun servers en zijn vaak niet gebruiksvriendelijk genoeg voor onze klanten. Uiteindelijk hebben we gekozen voor Laravel, een gevestigd lichtgewicht framework met veel algemene toepassingen voor web development. Dit helpt ons bij de standaard handelingen die we moeten uitvoeren voor het ontwikkelen van het dashboard, zonder dat onze creatieve vrijheid wordt gelimiteerd. We zijn erg tevreden over deze keuze en hebben nog geen moment heroverwogen.
3. De frontend: dat wat mensen eigenlijk zien wanneer ze interactie hebben met het dashboard. Een interessant feitje: Bovenop het presenteren van meetgegevens over game gebruik, verzamelen we ook meetgegevens over het gebruik van het dashboard. Vergeet niet dat sommige van eerdergenoemde gebruikersgroepen (zie: ‘Een op maat gemaakt dashboard’) vooral interactie met de game zullen hebben via het dashboard. Gebruikers van het dashboard moeten net zo’n boeiende ervaring hebben als de spelers van onze spellen. In de toekomst is het iets waar we graag op willen uitbreiden: Onze dashboards zijn eigenlijk vooral functioneel op dit moment, maar ze voelen nog niet zo boeiend als de games die we maken voor onze eindgebruikers. We denken dat we meer kunnen bereiken als het daadwerkelijk leuk is voor onze domeinexperts om deze dashboards te gebruiken.

Privacy by design

We hebben allemaal de e-mails gekregen die expliciete toestemming vragen voor het toesturen van nieuwsbrieven: de AVG is hier en blijft hier. We zijn altijd zeer bewust bezig geweest met het waarborgen van de privacy van gebruikers, vooral vanuit technisch oogpunt. Maar het moeten  voldoen aan alle eisen van de AVG legt hier nog eens extra de nadruk op.

Eerder in dit artikel hebben we gesproken over de voordelen van het vragen aan klanten waarom ze bepaalde data willen zien. Het stellen van deze vraag is niet alleen een goede manier van ontwerpen, het helpt ook met het aankaarten van privacy issues van onze gebruikers.

Tuurlijk kunnen we onze klanten precies laten zien waar en wanneer individuele gebruikers onze locatie gebaseerde spellen hebben gespeeld, maar hebben ze deze informatie echt nodig? Vaak zijn onze klanten vooral geïnteresseerd in het verzamelen van data: ze willen snel en op grote lijnen conclusies kunnen trekken voor alle spelers of voor een subset van de spelers. Het stellen van de waarom vraag helpt niet alleen bij het duidelijk maken hiervan, maar het stellen van deze vraag is ook nodig voor de basis van dashboard privacy policies.

Conclusie

Meetgegevens zijn de basis voor het maken van gegronde beslissingen. Wanneer je focust op wat je gebruikers willen bereiken met deze meetgegevens, geeft dit je ruimte in het ontwerp en het bedenken van creatieve oplossingen voor een doelgericht ontwikkelproces.

Ons hergebruik van een lichtgewicht web framework voorkomt dat we het wiel opnieuw moeten uitvinden. Ook brengt dit kant-en-klare oplossingen en voordelen zoals veilige authenticatie en een snelle backend ontwikkeling.

Door alle type gebruikers een dashboard aan te bieden, geven we ze de mogelijkheid om interactie te hebben met en te reflecteren op de complete spel gebaseerde oplossing. Voor sommige van deze gebruikers zal het dashboard zelfs de primaire manier van interactie zijn.

We verwachten dat dashboards een duidelijke toegevoegde waarde hebben voor onze meeste toekomstige producties. We zoeken continu naar uitbreidingen van de basis functionaliteit om ze net zo leuk en effectief te maken als onze games.

Wil je eens met ons praten over de mogelijkheden van serious games en het verzamelen van meetgegevens? Of heb je toevallig voorbeelden van leuke manieren om efficiënt meetgegevens te tonen aan gebruikers? Dan horen we graag van je!

[sc name=”newsletter-signup-NL”]