Een stuk waar ik al langer over wil schrijven is (interaction) design patterns tegenover a-b testen. Het eerste deel van dit artikel beschrijft wat AB testen en design patterns zijn en hoe ik deze interpreteer, waarschijnlijk weet je al prima wat AB testen en design patterns zijn en is het tenenkrommend om te lezen wat ik er nu precies onder versta. Sla het eerste stuk dan ook gerust over.
AB testen
A-B testen is een methode om 2 of meer variaties van dezelfde pagina te verdelen over de bezoekers van een website. Je meet of de volgende pagina van je bezoekers je gewenste pagina is. Een practisch voorbeeld. Ik heb een webshop en gebruik productpagina’s om mijn producten aan te prijzen. Van een productpagina maak ik 2 varianten, dus 2 pagina’s van hetzelfde product met dezelfde prijs die in dezelfde winkelwagen gaan. Met AB testen kan ik er voor zorgen dat een gedeelte van mijn bezoekers de ene productpagina (a) zien en een ander deel de andere productpagina (b). Vervolgens vergelijk ik welk gedeelte van de bezoekers van deze pagina’s doorgaan naar het afrekenen op mijn webshop. De pagina met het hoogste percentage is dan de winnaar en na het getest te hebben op voldoende bezoekers hou ik deze variant dan ook.
Interaction Design patterns
Gedeeltelijk zit het al een beetje in de naam: Design patterns vatten patronen in ontwerp. De beste manier om dit uit te leggen is wel om het vanuit een andere hoek te bekijken. Wanneer ik een woonwijk teken kom ik tal van praktische ontwerp uitdagingen tegen. Waar laten mensen bijvoorbeeld hun hond uit, waar kopen mensen hun eten. Maar ook, ik heb een stukje van mijn woonwijk waarbij ik maar een kleine weg aan kan leggen of ik heb geen plek voor parkeerplaatsen. Ondanks dat mijn woonwijk uniek is, zijn deze uitdagingen dat zeker niet dus is het raadzaam om een gelijksoortig probleem ergens anders te zoeken en te kijken hoe het daar opgelost is. Een slimme architect/stedenbouwkundige bewaart dan ook de problemen die hij eerder tegen gekomen is en beschrijft de oplossingsrichting, zo hoeft hij het niet elke keer opnieuw te verzinnen. Misschien nog wel belangrijker is dat je hierdoor klassieke blunders voorkomt. Gelukkig zijn architecten en stedenbouwkundigen slim en doen zij dit al erg lang, leuk is dat het je wel opvalt wanneer dit niet gebeurt en verkeert uitpakt, elke stad heeft wel zijn voorbeelden van blunders. Nu zijn interactie ontwerpers over het algemeen ook best slim dus verzamelen wij ook design patterns, Yahoo! heeft een library aangelegd en ook Martijn van Welie heeft zijn eigen verzameling. Deze patterns geven handvatten van globale site concepten tot detail interactie. Een slimme ontwerper houdt ook zijn eigen patronen bij, helemaal wanneer deze in een specifieke branche of toepassing werkt.
De stelling: patterns vs ab testen
Zeker sinds Google website optimizer bestaat is ab testen voor bijna iedereen toegankelijk. Je ziet dan ook dat er een enorme toename is in AB testen. Dit opzichzelf is natuurlijk ontzettend goed want het stimuleert om doorlopend de webervaring voor de gebruiker te verbeteren. Ook is de professionaliteit van AB testen toegenomen, het is bijna een vak apart geworden. Inherent aan AB testen is dat het achteraf gebeurt. Wat ook erg opvalt is dat AB testen misschien wel té toegankelijk is geworden en hierdoor symptomen van prijs-schieten begint te krijgen. Ik denk dat een goede AB test er een is waar minimaal 1 hypothese wordt getest. De hypothese moet dan wel voorkomen uit een ontwerpproces en feitelijk te onderbouwen zijn.
Design patterns verzamelen, inventariseren en kiezen is een proces wat nu typisch aan het begin van een proces zit. Dit proces is nog maar heel beperkt volwassen en optimaliseert zichzelf niet voldoende. Mijn stelling is daarom ook een vs stelling. Ik denk dat ab testen en design patterns een goede combinatie kan zijn maar waar stop je je energie, moeite, tijd en geld(!) in?
In 1e instantie levert AB testen snel resultaat, je kunt ze snel en makkelijk opzetten en ziet in de statistieken gelijk wat goed en wat niet goed is. Hierbij moet je wel onderkennen dat je optimaliseert in de marge. Je test immers pagina’s en onderdelen van de pagina’s. Door details te testen kun je verzanden in het continue blijven testen van details in een poging om een verkeerde basis te verbeteren.
Design structuur van een website
Wanneer je een bestaande website ontleedt op een ontwerp-manier dan kun je het op de volgende manier zien. Overkoepelend vinden we een concept, hieraan valt als het goed is alles terug te leiden. Daarnaast kunnen we een patronen vinden in het ontwerp, design patterns. Deze patronen komen op meerdere pagina’s voor en de pagina’s bevatten dan weer elementen.
Omdat je testdoel bij AB testen conversie is blijft de optimalisatie uit AB testen beperkt tot pagina’s en elementen. Uiteindelijk optimaliseer je op deze manier wel het pattern op zich maar je zult altijd binnen hetzelfde pattern blijven werken en denken terwijl er best wel eens een pattern kan zijn wat de gebruikerservaring met sprongen verbeterd. Het lastige hierin is dat je dit moeilijk kan kwantificeren omdat veel patterns het niveau van pagina’s en elementen overstijgen. Dit is ongeveer gelijk aan concept testen, je kunt vrijwel onmogelijk meerdere varianten op een concept testen en optimaliseren, simpelweg omdat het concept de samenhang van de hele website is.
Waarom?
Zonder een artikel te willen schrijven toch even want achtergrond informatie. Op een heel basaal niveau is deze afbeelding de manier hoe wij en hoe organisaties met het web omgaan. Eerst communiceerden organisaties met het web en gebruikers met het web. Nu steeds meer communiceren organisaties en gebruikers met elkaar via het web en straks zijn organisaties en gebruikers simpelweg onderdeel geworden van het web, of andersom: is het web een onderdeel van organisaties en gebruikers.
Met dit in het achterhoofd trek je dan snel de conclusie dat het venster tot het web steeds organischer wordt en hierdoor ook niet te vormen voor een vaste periode. Je kunt dan ook niet nu een concept schrijven wat over 2, 3, 4 jaar nog hetzelfde is. De organisatie, het web én de gebruikers veranderen aanzienlijk in deze periode. Het zou dan ook goed zijn wanneer het concept, design patterns, pagina’s en elementen meeveranderen.
Hoe dan? – Inventariseren, analyseren, optimaliseren
Inventariseren
Dit is niet het meest leuke stuk en levert gegarandeerd ook niets op. Inventariseer wat je nu voor patronen gebruikt binnen de site. Het is handig om top down te inventariseren, dus begin groot en werk toe tot de kleinere patronen. Bijvoorbeeld: het is een nieuws site tot aan ik gebruik breadcrumbs Het loont in dit stadium ook om ze te beschrijven binnen de context van de organisatie waardoor ze iets minder generiek en beter toepasbaar worden.
Analyseren
In dit stadium is het van belang om de losse patronen in te delen en verbanden te leggen. Veel patronen zullen een bepaald verband met elkaar hebben en wanneer je deze wil optimaliseren is het belangrijk om te weten welke patronen elkaar beinvloeden. Ook kun je hier KPI’s bij patronen definiëren (omdat je ze op de organisatie hebt beschreven) zodat je latere optimalisatie kunt meten.
Optimaliseren
Op dit punt kun je effectief je patterns gaan optimaliseren. Hoe je dit doet hangt natuurlijk erg van je patronen af maar omdat je ze als patroon hebt beschreven kun je veel leren door te zoeken waar dit patroon nog meer voorkomt. Buiten je eigen branche, land of misschien zelfs buiten het web. Testen kun je kwantitatief doen (doorvoeren en sitebreed de optimalisatie meten) of kwalitatief in bijvoorbeeld en gebruikersonderzoek.
Conclusie
In dit artikel heb ik geprobeerd om je te overtuigen waarom AB testen op de lange termijn niet meer de verbetering brengt die je zoekt en het van belang is om nu design patterns te schrijven voor je website zodat je in plaats van de pagina de gehele gebruikerservaring doorlopend kunt optimaliseren.

Category:




















