Een Design Sprint¶
Intro¶
Hieronder volgt een opzet van een design sprint. Let op: er is geen vast format voor een design sprint. Dit is een verzameling van fases en methodes die je zou kunnen gebruiken tijdens de ontwerpfase van een nieuw product. Je hoeft niet alles te doen, bedenk wat bij jullie proces past en voel je vrij eigen methodes en technieken te verzamelen, zolang je de bronnen maar herleidt en je proces goed documenteert. Verzamel alles wat je tegenkomt; dit kunnen schetsen zijn, een analyse van een game, stakeholder- en user journey maps, maar ook reacties van anderen op jullie werk of input van experts. Alles is onderdeel van het onderzoek en mag een collectie van ruwe data zijn die later verwerkt kan worden tot concrete inzichten voor jullie game.
Een Design Sprint is een iteratief proces, kijk dus niet gek op als je af en toe een stap terug of juist vooruit moet doen.
.
Sprint Doel
Ontwerp een game concept, die je aan het eind van de sprint pitched aan je peers in een presentatie van ongeveer 5 minuten. Presenteer je prototype en leg uit waar de ontwerpkeuzes vandaan komen, of presenteer je proces en de inzichten die uiteindelijk in je prototype te zien zijn.
Voorbereiding¶
Om niet bang te zijn fouten te maken, en niet te streven naar een perfect product maar het onderzoek te zien als een experiment om van te leren, is het belangrijk om de juiste mindset te hebben en open te staan voor de bevindingen die op jullie pad komen.
Understand & Empathize¶
Het is belangrijk de opdracht goed te begrijpen om een goed product te kunnen leveren. Meestal begint dit met een uiteenzetting van de opdracht briefing.
Vragen om te beantwoorden¶
- Wat is een game nu eigenlijk? Wat zijn de onderdelen?
- Wat zijn de technische vereisten van het product?
- Voor wie maak ik het product? In andere woorden, wie zijn de aandeelhouders of meer gebruikt de stakeholders?
- Hoe documenteren we het proces?
Methodes om te gebruiken¶
- Analyseer een vergelijkbaar product (2D Game, 2D Retro Game, jullie eigen Space Invaders) aan de hand van het MDA Framework.
- Lees deze wetenschappelijke paper over Game Design en Game Research
- Maak een Stakeholder Map n.a.v. de opdrachtbriefing
Optioneel:
- Maak een User Journey Map
- Speel een rollenspel om je in te leven in de aandeelhouders
- Analyseer de competitie
Tip
Voor alle onderdelen binnen een Design Sprint geldt: Quick & Dirty! Als het te lang duurt een nieuwe methode te begrijpen zoals het maken van een Stakeholder Map; Timebox het! Scan de bron en zet wat op papier. Het hoeft niet compleet of perfect, als er maar iets is. Het is een startpunt. Overleg samen wat een realistisch doel is: misschien is het 10 minuten, misschien is het een uurtje. Zet een timer en ga aan het werk. Denk na over de complete sprint en schat in hoeveel tijd je per onderdeel mag besteden.
Define¶
Vanuit de nieuw opgedane informatie binnen de understand & emphatize fase is hopelijk kennis ontstaan. Je begrijpt de eisen van de opdrachtgever beter en ook heb je een beter begrip van wie er allemaal betrokken is bij het ontwikkelproces van jullie game. Hoe definieer je de opdracht waar je aan gaat werken? Hoe gaan jullie die kennis inzetten om zelf een nieuw game te ontwerpen?
- Brainstorm over een eigen game aan de hand van het MDA Framework
- Brainstorm uit de losse pols: wat heb je altijd al willen maken? Maak een mindmap op papier.
- Heb je geen idee? Probeer eens een associatie spel
- Maak een inspiratie muur
- Of een moodboard
- Bepaal wat je gaat Prototypen
Maak een lijst van ideeën, zoveel als je wilt.
Ideate through Paper Prototyping¶
Om de ideeën en conclusies uit de define fase om te zetten tot een tastbaar prototype gebruiken we Paper Prototyping. Prototypen op papier is snel en goedkoop; Quick en Dirty. Je loopt zo snel tegen problemen aan en vindt misschien interessante alternatieven voor problemen waar je eerder nog niet aan hebt gedacht. Zolang het maar op papier staat! Ideeën komen pas tot leven als een ander ze ook kan zien en prototypen op papier is de eerste en snelste manier om dat te doen.
- Prioritiseer je lijst aan ideeën volgens de MoSCoW methode
- Oefen met tekenen
- Maak een Flowchart om de lijst aan ideeën om te zetten in logische stappen
- Maak een Wireflow
- Prototype een storyboard
- Nog een uitgebreide mening over paper prototyping en how to
- Prototype!
Zodra er een coherent idee of concept op papier staat, is het handig dit even snel te testen met wat Peers. Introduceer je spel aan iemand in de buurt en let goed op of ze het begrijpen. Je kan ook een scenario schetsen en ze een opdracht geven. Is het nog te moeilijk of te makkelijk? Maak dan een variatie op je papieren prototype en test opnieuw, totdat je tevreden bent.
Interactive Prototyping¶
Als de eerste grove ideeën getest zijn op papier, is het tijd om het prototype tot leven te brengen. Er zijn verschillende tools te gebruiken maar de Software die op dit moment door veel ontwerpers in de industrie wordt gebruikt is Figma. In Figma kan je makkelijk simpele interfaces bouwen en deze interactief maken. Zo kan je bij benadering jullie game prototypen. Let op dat je bepaalde interacties ‘faked’, je bootst ze na zodat ze testbaar zijn, maar je hoeft geen duizend schermen te bouwen om het prototype vlekkeloos te laten werken.
Test¶
Als het interactieve prototype werkt, is het tijd om te kijken of jullie ideeën wel overkomen op anderen. Kijk terug op het design proces en vind testers die dicht in de buurt komen van je stakeholders. Komt het prototype nog overeen met de eisen van de opdrachtgever? Valideer het met je opdrachtgever! Is het prototype duidelijk voor je doelgroep? Valideer het met je doelgroep. Alleen door testen weet je zeker dat je ideeën ook echt bruikbaar zijn.
- Qualitative Usability Testing: Study Guide
- Bekijk deze tutorial over usabilty testing 101
- Testing Paper Prototypes 101
- Usability Metrics: Measuring UX Design Success
Reflect & Define MVP¶
Als alle stappen van de design sprint doorlopen zijn heb je een hoop kennis opgedaan over het maken van jullie game. Nu is het tijd om realistisch te gaan plannen. Wat hebben we geleerd en welke kennis kunnen we meenemen in het definiëren van een MVP? Wat is haalbaar in de ontwikkeltijd die jullie hebben? Wat heb je nodig in het product zodat het echt werkt? Stel prioriteiten. Gebruik hier bijvoorbeeld nog eens de MoSCoW methode voor. Welke functionaliteiten moeten er minimaal in het product om het werkend te krijgen?