The state we’re in
1e Colloquium
De eerste bijeenkomst met mede-afstudeerders en begeleidende docenten was voor ons de gelegenheid om ons concept voor te leggen. Het doel wat wij voor ogen hadden was het voeren van een inhoudelijke discussie over het concept en de visie die wij in het voorgaande traject hadden vastgesteld.
De presentatie hadden wij opgedeeld in visualisaties. Dit leek ons een sterke methode om ons concept uit te leggen. Hier volgt een opsomming en korte toelichting van de schermen die wij gepresenteerd hebben.
Aan de hand van ons marktonderzoek trokken wij de volgende conclusies:
- De systemen die inzichten vergaren zijn niet toegankelijk (complex in gebruik, duur om te implimenteren of duur om aan te schaffen).
- De systemen die toegankelijk zijn geven geen inzichten en zijn beperkt in personalisatiemogelijkheden.
- De systemen die uitmuntende personalisatiemogelijkheden ondersteunen zijn zeer lastig te implementeren en bovendien erg duur.
Bij het uitvoeren van de design sprints hebben we gebruik gemaakt van een theorie zoals omschreven op de website van Huge inc. Voor ons was het creëren van inzichten in de doelgroep van een online dienst lijdend. Aan de hand van deze inzichten kan een beheerder namelijk steeds beter inspelen op de wensen van zijn of haar bezoeker.
Met al het voorgaande onderzoek en de conclusies die wij hier uit konden trekken hadden wij onderstaande fasering samengesteld. Het doel van deze fasering was het vaststellen van een werkwijze waarbij het product snel in gebruik zou kunnen worden genomen. Deze fasering is inmiddels ook aangepast. Hier over later meer.
Naast deze project inhoudelijke informatie wouden we ook graag meer vertellen over de “Design Sprint” werkwijze van Google. Omdat deze werkwijze de projectgroep in staat stelt om snel prototypen te maken en deze te testen leek ons dit een methode die perfect aan sloot op ons project.
Nabeschouwing colloquium
Het werd ons tijdens de bijeenkomst duidelijk dat de presentatie zoals wij die hadden opgezet niet de gewenste reactie te weeg bracht. Waar wij hoopte een inhoudelijke discussie te kunnen voeren over ons concept werd het gesprek overwegend gebruikt om een poging te wagen alles uit te leggen. Omdat we alleen konden spreken over ideeën en nog niet in staat waren om hier concrete voorbeelden van te geven bleef het hier ook bij.
Door de conceptuele aard van de presentatie werd feedback gegeven waarbij veelal out of the box werd gedacht, terwijl wij een fase hadden bereikt waarin wij ons concept wouden gaan uitwerken in een testbaar prototype. De conclusie die wij hier uit hebben getrokken is dat wij bij het volgende colloquium het over een totaal andere boeg willen gooien met betrekking tot de informatie (en de wijze waarop) die gepresenteerd wordt.
Voortzetting
Uitwerken concept in prototype
Om ook voor onszelf een beter beeld te krijgen bij de toepassing van ons concept in een beheersysteem zijn we de volledige flow uit gaan werken. Hier hebben wij extra aandacht besteed aan gebruiksvriendelijkheid (ook voor beheerders die nog nooit een dergelijk systeem hebben gebruikt) en het creëren van inzichten.
Hier onder een kleine greep uit het ontwerpproces, beginend met de schermen van de “Create goal” flow.
De schermen hier onder zijn onderdeel van de “Goal list” en “Insights panel”.
Bij de laatste iteratie slag hebben we geprobeerd de informatie dusdanig op te splitsen en toe te lichten dat deze ook voor leken begrijpelijk is. Dat heeft tot het volgende resultaat geleid:
Het prototype is klikbaar gemaakt in Invision. Deze kan hier bekeken worden.
Aanpassingen concept
Toen het prototype in onze ogen afdoende uitgewerkt was om gepresenteerd te worden hebben we deze voorgelegd aan de medewerkers bij Lab Digital. De voornaamste feedback was dat het een grote opdracht zou zijn om al deze schermen nog tijdens onze stageperiode in een werkend systeem te verwerken. Dit was een gegeven waar wij ons bewust van waren. De fasering die wij gecreëerd hadden alvorens het opstellen van dit prototype was hier ook op ingericht.
Meer inhoudelijke feedback was dat wij in onze flow veel rekening hielden met de beheerder, maar niet genoeg met eventuele content editors. Omdat deze taken in veel gevallen wordt opgesplitst is het belangrijk dat er vanuit het perspectief van beide functies wordt gekeken naar de meest logische flow voor ieder. Als antwoord hier op hebben we er voor gekozen om de hiërarchie van ons concept bij te schaven. Links staat de originele variant en rechts de verbeterde.
Zoals te zien is ligt het segment meer centraal in de flow. Bovendien laat deze aanpak toe om meerdere vormen van personalisatie aan 1 segment te verbinden.
Uitsluiten MVP
Doel van de MVP is om de basis neer te zetten voor ons concept, de eerste fasering van het personaliseren toepassen en beheerders ermee aan de gang te kunnen laten gaan. Door deze aanpak willen we meer inzicht krijgen in de werking van ons concept in een praktische situatie.
De reden dat wij dit technisch uitwerken is omdat wij niet de juiste reacties uit non-technische prototypes hebben kunnen halen. Dit heeft volgens ons een aantal redenen: het is lastig voor de geteste gebruiker om een achtergrond te verbeelden en de gebruiker ziet geen resultaat terug van de acties die zij ondernemen. Met het technische prototype willen wij een context genereren en gebruikers echt digitaal aan de gang laten gaan.
De MVP bestaat uit drie onderdelen; een segment bouwer om segmenten aan te maken, een pagina varianten systeem waarbij elk segment een eigen variant gebaseerd op de normale pagina kan krijgen en de module “Wagtail Experiments” om het “verkrijgen van inzichten” in een versimpelde vorm te implementeren. In onze ogen is dit de minimale functionaliteit vereist om ons concept te testen.
Ons doel is om binnen 4 weken deze MVP uitgewerkt te hebben als functioneel prototype. Deze willen wij dan gaan toepassen op labdigital.nl om echte testcases te maken.
Voor de MVP hebben we de volgende schermen geselecteerd. Hier en daar zijn kleine aanpassingen gedaan.
Voorbereiden ontwikkeltraject
Voor het ontwikkeltraject hebben wij 4 weken van ons project gereserveerd om hier op te gaan zitten. Deze hebben wij in 2 sprints ingedeeld waarbij wij gaan werken aan de “segment bouwer” en het pagina variatie systeem.
De twee sprints zijn als volgt ingedeeld:
Sprint 1
Segment bouwer
- Front-end view aanmaken
- Wagtail admin hooks aanmaken om in menu te komen
- Modal schermen aanmaken
- Gebruikers op request meten en aan een segment vastmaken (met middleware doen?)
- Request sessions aanpassen om segment van de gebruiker te bewaren
Pagina varianten
- Pagina’s kunnen kopieren voor gesegmenteerde varianten
- Pagina variant opzoeken en weergeven als gesegmenteerde gebruiker deze opvraagt
Sprint 2
Segment bouwer
- Rules toevoegen en meetbaar maken
- Tijd rule aanmaken en meetbaar maken bij request
- Referral rule aanmaken en regex meetbaar maken
- Visit count rule aanmaken en meetbaar maken
- Segmenten aanpasbaar en verwijderbaar maken
Pagina varianten
- Segment kunnen koppelen aan een pagina variant
- Variant pagina’s verstoppen op de navigator
- Pagina varianten kunnen verwijderen
Voorbereiden testfase
Om de testfase voor te bereiden gaan wij onze prototype draaien op een live website waarbij wij een aantal personalisaties gaan toepassen om deze te testen. Dit om meer inzicht te krijgen op de effectiviteit van de soort regels die wij aanmaken.
Daarnaast hebben wij een test site waarmee wij met gebruikers weer actief playtests gaan doen. Het doel is om de gebruikers na te laten denken over het aanmaken van segmenten en het bouwen van een stukje personalisatie.
Gebaseerd op de resultaten van de testfase gaan wij aan de slag met het verbeteren van ons concept en het realistisch maken van de iteratieslag die een beheerder zou kunnen doorlopen, namelijk het verbeteren van de gemaakte personalisaties.
