- Inleiding
- Ontwerpen, Prototypen, Testen
- Communicatie met de opdrachtgever
- Transitie van concept naar product
- User stories schrijven
- Opbouwen van het product backlog
- Opdracht 5 — Deliverable 1: Definitief Prototype & Eindpresentatie
- Opdracht 5 — Deliverable 2: Projectoplevering
- Opdracht 5 — Deliverable 3: Case study
Inleiding
Nu het onderzoek afgerond is, het concept staat, zijn we halverwege het project. Het is tijd om het concept door te ontwikkelen naar een high-fidelity prototype, wat je aan de opdrachtgever en klant kan laten zien. Om projecten te realiseren gebruiken de meeste ontwerpbureaus en full-service agencies Scrum als projectmethodiek. Scrum is een specifieke uitwerking van een zogenaamde ‘agile’ methode, waarbij je niet stukje voor stukje een product ontwikkelt, maar juist in iteraties. Bij scrum zijn er een aantal afwegingen gemaakt die het lastig maken om in een onderwijssetting exact na te bootsen zijn.
Daarom hebben we ervoor gekozen om niét te gaan werken volgens scrum, maar wel een ‘agile’ aanpak te hanteren, die overeenkomsten heeft met scrum, maar toegepast is op de onderwijssituatie. We werken gedurende de realisatiefase in twee of drie iteraties, afhankelijk van wat er met de opdrachtgever afgesproken is.
Ontwerpen, Prototypen, Testen
De sprints die je gaat doorlopen kenmerken zich door middel van het volgende basisproces:
-
Ontwerpen (Uitwerken)
-
Prototypen
-
Testen
Belangrijk is dat je in de eerste sprint de transitie van een concept naar een daadwerkelijk product gaat maken. Hiervoor kun je verschillende strategieën hanteren. Het is van belang dat je begint vanuit het gebruikersscenario dat je gedefinieerd hebt voor je concept en te kijken of dat je hiermee de volledige user experience zichtbaar kunt maken. Vervolgens kun je het scenario gebruiken om een Product Backlog te gaan maken, een in kleine eenheden opgedeelde user stories, die tezamen het geheel van de experience vormen die je aan het realiseren bent.
Communicatie met de opdrachtgever
Tijdens deze periode is het van belang om de opdrachtgever goed op de hoogte te houden van de voortgang van het project. Zorg er voor dat je je week afsluit met een update aan je opdrachtgever, dit kan gewoon via een message in Teams (of een ander communicatiemiddel dat je hebt gekozen met de opdrachtgever).
Maak een persoon hiervoor verantwoordelijk, maar maak het overzicht gezamenlijk. Dit is namelijk een goed moment om de activiteiten voor volgende week te plannen en de voortgang van het project te bewaken.
Transitie van concept naar product
Om de transitie te maken van concept naar high-fidelity prototype is het van belang om eerst vast te stellen wat het is wat je precies gaat maken. Dit doe je door een Product Backlog te maken. Dit Backlog is vergelijkbaar met een Backlog zoals dat in formele scrumprojecten gebruikt wordt, maar is toegespitst op de user experience van een product, in plaats van de technische realisatie van een product. Backlogs zijn opgebouwd uit ‘User Stories’ en user stories zijn de ‘brandstof’ van ieder agile project. Ze zijn de requirement op basis waarvan er ontworpen wordt, code wordt geklopt, of het project wordt gepland.
Een product backlog met user stories vervangt het ‘projectplan’ en is niet een grote stapel papier waar één keer naar gekeken wordt. Een user story is kort en bondig, het is een titel gevolgd door een paar zinnen waarin je de vereisten voor de realisatie uitlegt.
Een user story probeert zoveel mogelijk het ‘gesprek’ tussen verschillende stakeholders te vangen. Hiermee betekent een user story voor verschillende stakeholders dus ook verschillende dingen:
• Voor de concepter is het een weergave van de vereisten van het product en de zakelijke intenties.
• Voor een visual designer is het een representatie van de productbeleving en het merk en hoe deze in de context van het gebruik overgebracht dienen te worden
• Voor een interaction designer is het een weergave van iets wat een interface nodig heeft (kan hebben).
• Voor de prototypers is het een beschrijving van welke ervaring er in het prototype mogelijk gemaakt wordt.
Omdat je niet veel ruimte hebt om te schrijven, ben je beperkt in wat je kunt vangen. Je wil in een user story juíst die dingen hebben staan die nodig zijn voor het realiseren.
User stories schrijven
In z’n meest elementaire vorm beschrijft een user story voor wie de story bestemd is, wat de story moet doen, en waarom het waardevol is. Hiervoor hanteren we een vast format: “Als een X, wil ik een Y, zodat er een Z”. Dit is om de volgende reden:
Als een… definieert wie de eindgebruiker van de story zal zijn. Hiermee zorg je er voor dat iedere story user-centered is.
Wil ik een… doel bereiken. Wat is het doel dat je wil dat de gebruiker bereikt met deze story? Door toe te spitsen op doelen, realiseer je alleen de dingen die echt nodig zijn.
Zodat er een… Waarom is deze story noodzakelijk? welke zakelijk doel probeer je er mee te bereiken? Waarom kan het de klant iets schelen? Welk doel helpt het hem of haar te bereiken?
Voor het schrijven van user stories gebruik je de persona’s die je gemaakt hebt naar aanleiding van je onderzoek. Doe dit echter alleen als het waarde, detail of context toevoegt aan de requirement. Vaak is de high-level rol (gebruiker) voldoende. Voor generieke requirements zoals bijvoorbeeld een login, is de requirement hetzelfde voor ieder persona. Er zijn echter ook aspecten van een product die specifiek toegespitst zijn op een menselijke behoefte. Daarom kan het handig zijn, als de context er om vraagt om een user story toe te spitsen op één of meerdere persona’s. In het schrijven van een user story wil je vooral de titel en de details vangen.
Ook binnen je user stories zullen er iteraties plaatsvinden. Naarmate het project vordert zullen sommige stories ook verduidelijkt, aangepast, verwijdert of toegevoegd worden.
Wanneer is een user story goed?
Een user story is goed op het moment dat het aan de volgende voorwaarden voldoet:
Een user story is: Onafhankelijk, Onderhandelbaar, Waardevol, Schatbaar, Klein en Testbaar
Onafhankelijk:
Iedere user story moet op zichzelf staan en onafhankelijk van andere user stories in het project gerealiseerd kunnen worden. Dat wil niet zeggen dat ze niet van elkaar afhankelijk kunnen zijn, maar de afhankelijkheden mogen niet complex zijn.
Onderhandelbaar:
Het moet mogelijk zijn voor de verschillende stakeholders in het project om te onderhandelen over een user story. Zo lang een story onderhandelbaar is, hou je flexibiliteit met je team om de user stories te realiseren.
Waardevol:
De user story moet van waarde zijn voor de opdrachtgever en / of voor de eindgebruiker. We hoeven geen bunkers te bouwen die de veiligheid van Nederland garanderen. Ze moeten vooral waarde opleveren voor de mensen die het product gaan gebruiken.
Schatbaar: Het moet voor alle teamleden mogelijk zijn om in te schatten wat het kost om een user story te realiseren, zodat de activiteiten van het team te plannen zijn. De stories moeten in een iteratie passen.
Klein:
Gaat samen met schatbaar, is een story te groot, of zelfs een epic, neemt de onzekerheid bij het team toe of de story te realiseren is. Probeer hierbij ook af te stemmen tussen de ontwerper en de bouwer. Wat voor een ontwerper één wireframe is, kan voor een ontwikkelaar een week bouwen zijn!
Testbaar:
Door te zorgen dat een user story testbaar is kun je goed vaststellen wanneer deze ‘klaar’ is. Iedere story moet een demonstreerbaar resultaat op kunnen leveren.
User stories en User goals
Het is van belang dat je als ontwerper goed vaststelt of een user story ook daadwerkelijk waarde oplevert voor de eindgebruiker. De waarde van een story, wordt alleen geleverd aan een gebruiker als onderdeel van het grotere geheel; het product. Het is daarom van belang dat je bij het realiseren van de stories ook de visie die je voor het project hebt gedefinieerd in je achterhoofd houdt. Om stories te koppelen aan doelen van gebruikers maken we gebruik van het product backlog.
Opbouwen van het product backlog
Van Concept naar Product backlog
Met het scenario wat je voor het gekozen concept hebt gemaakt ga je user stories maken van je product. Ze hoeven op dit moment alleen nog maar titels te zijn. Je bent in dit stadium ben je vooral op zoek naar breedte, niet naar diepte. Ongetwijfeld kom je dingen tegen die ‘epic’ zullen blijken, en die epics verdeel je in een later stadium in kleinere stories. Op basis van de scenario’s die je geschreven hebt, kun je een aantal doelen voor de gebruiker afleiden. Het eerste wat je gaat doen is deze doelen vangen. Hou hierbij rekening met hoeveel keer een doel terugkomt, en het belang van het doel.
Verdeel doelen in primaire doelen en secundaire doelen, zo kun je later vaststellen wat het eerste is wat je gaat realiseren. Vervolgens kun je de doelen opbreken in activiteiten. Hierna ga je een overzicht maken van de taken waaruit iedere activiteit bestaat. Hierbij rangschik je de activiteiten horizontaal, en de taken verticaal.
Als je de doelen voor de eindgebruiker gedefinieerd hebt, ga je daartussen ruimte maken voor de doelen van de klant. Wat zijn de zakelijke doelen die behaald moeten worden met het product? Zijn er dingen die juist benadrukt moeten worden, beveiligd moeten worden of extra aandacht verdienen? Zo wordt gaandeweg de storymap compleet met alle doelen en taken die je nodig hebt om het uiteindelijke product te gaan realiseren.
MVP vaststellen
Als je de volledige backlog gerealiseerd hebt, kom je al snel in de verleiding om te zeggen “dit is wat we allemaal moeten gaan maken.” Maar je wil in de eerste iteratie het minimale product vaststellen. Je gaat dus door de backlog heen en probeert waar mogelijk een zo klein mogelijke waardevolle realisatie te definiëren van het doel. Hierbij probeer je ook vast te stellen hoe belangrijk een story is.
Belangrijkheid vaststellen doen we aan de hand van de volgende criteria:
Behoefte van de klant
Wat als deze feature niet beschikbaar is voor de eindgebruiker? Wat zou er gebeuren? Zou dit rampzalig zijn voor het succes van het product? In welke mate is dit essentieel voor het product dat we gaan realiseren? Als dit later toegevoegd wordt aan het prototype, is dat dan ook goed?
Zakelijke behoefte
Er kunnen een aantal features zijn die noodzakelijk zijn voor de business, maar die totaal niet relevant zijn voor de user experience. Advertenties zijn hier een voorbeeld van. Geen gebruiker die ze mist, maar als het business model van je app er op draait, zijn ze wel essentieel voor het bestaan van je bedrijf.
Onderscheidend
Maakt deze feature je product onderscheidend ten opzichte van de concurrentie? Probeer je hiermee alleen aan te bieden wat de anderen al doen, of kun je je met deze feature echt onderscheiden? Hoewel het verleidelijk is om te doen wat anderen ook doen, is het vooral van belang dat je die dingen doet die voor jouw eindgebruiker noodzakelijk zijn.
Ondersteuning
Ondersteunt de feature de eindgebruiker in het bereiken van zijn of haar doel? Denk aan data-validering, feedback processen en help. Hou hierbij vooral rekening met de context van het gebruik.
Mate van gebruik
Hoe vaak wordt een feature gebruikt in het product? Is het iets waar je af en toe mee bezig bent (denk aan instellingen) of is het een feature die je dagelijks meerdere keren gebruikt?
Snoepje
Is deze feature iets waar je de klant mee betovert? Leidt het gebruik van de feature tot een aangename emotie?
Door aan deze factoren punten te koppelen, en de punten op te tellen, kun je vaststellen wat de prioriteit is van een doel of taak die je gedefinieerd hebt.
Definition of ‘done’
Het is van belang dat je met je begeleidend docent, en het team een duidelijke afspraak hebt over wanneer een story ‘klaar’ is (done). Is ie klaar als het geïmplementeerd is in het prototype? Of is een story klaar op het moment dat je de uitgewerkte story in het prototype hebt zitten en ook nog eens getest hebt?
Maak met je team een ‘definition of done’ en hang die op op de plek van je team in Miro.
Opdracht 5 — Deliverable 1: Definitief Prototype & Eindpresentatie
In week 7 gaan jullie bij je opdrachtgever het eindresultaat van jullie project presenteren en overdragen. Hierbij hoort natuurlijk ook een spetterende presentatie. Met de eindpresentatie laat je zien wat er gedurende de afgelopen periode gerealiseerd is, en wat je nu overdraagt aan de opdrachtgever. Tevens presenteer je de case-film bij deze presentatie.
Randvoorwaarden
De presentatie laat duidelijk zien wat het team gedurende de projectperiode gerealiseerd heeft, en wat er overgedragen wordt aan de opdrachtgever. De presentatie is visueel één geheel en ziet er verzorgd uit.
Deadline
De deadline voor de oplevering van het project valt in week 7 op vrijdag 13 januari om 17:00 en de presentatiedatum in week 7. Je zorgt ervoor dat de presentatie op Teams beschikbaar is, en ook meegeleverd wordt op de oplever-USB-Stick (zie deliverable 2).
Opleveren
Je levert de presentatie op als file in Teams, zowel als PDF en Keynote / Powerpoint document.
Toetsing
De eindpresentatie van het definitieve prototype wordt op de volgende criteria summatief getoetst:
Het eindproduct is origineel en innovatief en er is een duidelijke samenhang tussen het concept en product dat terug te leiden is naar het eigen onderzoek. Het product sluit aan bij zowel doelgroep als opdrachtgever.
Het gerealiseerde prototype sluit in toon en vorm aan bij de visuele identiteit van het merk of opdrachtgever. Er is een verfijnd ontwerp gerealiseerd, en waar nodig zijn visuele technieken gebruikt om complexe informatie op eenduidige wijze te communiceren.
Het proces heeft geleid tot de realisatie van een prototype voor een interactief product dat getest is in de praktijk, testresultaten hebben geleid tot aanpassingen en aanbevelingen.
Het team kan de samenhang tussen onderzoek en product duidelijk aantonen en ontwerpbeslissingen onderbouwen, en gevolgen overzien van de eigen ontwerpbeslissingen.
Het heeft zich ingeleefd in de doelgroep en andere stakeholders, en actief betrokken in het ontwerpproces, heeft goed geobserveerd en daar conclusies aan verbonden ten behoeve van het ontwerp. Het team toont empathisch vermogen.
Opdracht 5 — Deliverable 2: Projectoplevering
Opdracht
Na de presentatie lever je het volledige project op aan de opdrachtgever. Hiervoor gebruik je de bijgeleverde template.
Het project lever je in tweevoud op, op twee USB-sticks:
Waarom twee?
Één voor de opdrachtgever
Één voor de projectdocent
Waarom USB-Sticks in een tijd van Dropbox, WeTransfer, en andere online gigabytes?
Het is voor school van belang dat jullie werk goed gearchiveerd wordt, en het lastige met online storage is dat het vaak effectief werkt… voor een paar weken. USB sticks zijn in dat opzicht voor veel langere tijd te bewaren, en op die manier bevindt het projectarchief zich ook op één plek.
Randvoorwaarden
De oplevering van het project moet aan de volgende voorwaarden voldoen:
-
Aan de hand van de aangeleverde mappenstructuur lever je alle deliverables van het project op.
-
Daarnaast vul je ook je contactgegevens in in het bestand ‘contactgegevens.txt’, zodat, indien nodig opdrachtgevers of andere geïnteresseerden contact met je op kunnen nemen.
Ter volledigheid hier een overzicht:
‘01_Eindresultaat’
Het uiteindelijke prototype wat standalone gebruikt kan worden. Indien er speciale instructies nodig zijn om het prototype te bekijken, dien je deze erbij te beschrijven.
‘02_Projectdeliverables’
Deze map bevat alle deliverables zoals gedefinieerd in de opdrachtomschrijvingen dit zijn:
Kickoff-fase
Workshop Presentatie
Debrief Workshop
Rapportage workshop
Overige materialen
Discovery-fase
Presentatie Discovery fase
Debrief meeting Discovery fase
Onderzoeksverslag
Overige materialen
Ideation-fase
Presentatie Ideation
Debrief Presentatie Ideation
Concepten en Lo-fi Prototypes
Overige Materialen
Realisatie-fase
Prototype V1
Prototype V2
Overige Materialen
Alle subonderdelen (visual designs, wireframes schetsen, tussentijdse presentaties e.d., dienen ook hierbij opgeleverd te worden)
Overdracht-fase
Presentatie Overdracht
Overige Materialen
In de map ‘overige materialen’ kunnen alle materialen opgeleverd worden die wel voor het project geproduceerd zijn, maar geen onderdeel zijn van de standaard deliverables.
‘03_Casefilm’
Bevat alle deliverables die gedefinieerd zijn voor de realisatie van de casefilm, te weten:
De Casefilm (eindresultaat)
Scenario
Storyboard
Moving Storyboard
Moordboard
Shotlist
Deze vormt hiermee ook een deel van de oplevering van de video visualization module.
Deadline
De deadline voor de oplevering van het project valt in de week van de eindpresentaties week 7 op vrijdag 13 januari om 17:00.
Opdracht 5 — Deliverable 3: Case study
Tijdens de laatste assessment van het project presenteer je aan je begeleidend docent een case study waarmee je hem/haar en andere een ‘kijkje in de keuken’ geeft, in de totstandkoming van het project.
Ter inspiratie:
https://onepagelove.com/inspiration
Eerdere jaargangen van IUXD:
Belangrijk is dat de casestudy een aantrekkelijk, beeldend verhaal wordt, waardoor iemand gemotiveerd wordt om meer te weten te willen komen over jullie, je team en het project wat jullie gerealiseerd hebben.
Niet geheel onbelangrijk, wat maakt jullie werk onderscheidend? Zoek een spannende / interessante / uitdagende invalshoek, waarmee je je onderscheid ten opzichte van de andere design-teams in de minor.
Randvoorwaarden
De case study moet in ieder geval de volgende onderdelen bevatten:
Introductie
Beschrijving van de opdracht, de vraag van de opdrachtgever, het onderliggende probleem en de uitgangssituatie.
Werkwijze en werkproces
-
Hoe ben je te werk gegaan?
-
Wat is het proces dat je gevolgd hebt?
-
Welke stappen heb je genomen om het probleem te onderzoeken?
-
Wie waren er allemaal betrokken bij het project?
-
Hoe heb je met ze samengewerkt?
Resultaten
-
Wat is het resultaat geworden van jullie werkwijze?
-
Wat waren de belangrijkste inzichten in het gedrag van de eindgebruiker en de klant?
-
Waar bestaat het concept uit?
-
Hoe werkt het uiteindelijke prototype?
Deadline
De deadline voor de oplevering van het project valt in de week 7 van de eindpresentaties op vrijdag 13 januari om 17:00.
UX Studio 2 - Opdracht 5 Realisatie en Overdracht (incl deliverables) (PDF)