Experimenteren is leuk, leerzaam en levert vaak ook nog eens extra omzet en/of een betere gebruikerservaring op. Er is alleen ook een keerzijde die vaak nog onderbelicht blijft: het effect van het experiment op de rest van de organisatie en – niet te vergeten – de klant / bezoeker op je site.

Professor in witte jas

Het effect is niet zo groot wanneer je weinig experimenteert of hele kleine wijzigingen op de site aanbrengt (maar dat is logisch). In eerste instantie is er dan ook niet de noodzaak om veel te communiceren over je experimenten. Sterker nog: het is ook wel leuk om met iets te experimenteren waarvan niemand op de hoogte is. Ik zie direct een professor in een witte jas voor me die in een kelder van een kasteel met allemaal buisjes en pruttelpotjes proefjes aan het doen is. Niemand weet wat hij doet, sterker nog, de meeste mensen weten niet eens dat hij daar aan het experimenteren is.

Vrouwen veranderen in kikkers (onee!)

Een eenzame professor in een kelder kan alleen voor problemen zorgen als zijn experimenten anderen ‘raken’, als er bijvoorbeeld één experiment alle vrouwen in het kasteel in kikkers laat veranderen. Dat merk je. En daar ben je niet blij mee. Ditzelfde geldt ook voor de experimenten die wij uitvoeren op onze sites. Er worden dingen aangepast waar niet iedereen blij mee zou kunnen zijn. Denk bijvoorbeeld aan mensen die houden van structuur. Die elke dag op dezelfde manier over je site surfen. Die haten je als je de site gaat aanpassen. En ze gaan je nog meer haten als je de site heel vaak aanpast of als ze vanaf verschillende computers verschillende versies zien.

Echte kikkers

Enkele echte problemen waar je als webanalist/professor voor kunt zorgen zijn:

• Bezoekers / klanten / medewerkers denken dat er ‘iets’ fout gaat omdat er verschillende versies van één pagina in omloop is en melden dit als een incident.
• Bezoekers / klanten bellen met een vraag over een pagina die de medewerker aan de telefoon niet ziet.
• Ontwikkelaars die aan de site werken moeten een wijziging doorvoeren op een pagina en herkennen de oorspronkelijke pagina niet meer (in het verzoek staat een andere pagina / andere layout / content).
• Beheerders zien op verschillende pc’s verschillende versies van pagina’s en vermoeden dat er een fout op de server zit.
• Redacteuren die teksten aan moeten passen, zien de oorspronkelijke tekst niet en kunnen de tekst die zij zien niet vinden in het content management systeem.
• Bezoekers / klanten die elkaar willen helpen kunnen misverstanden (en uiteindelijk ruzie) krijgen omdat ze allebei denken dezelfde pagina te zien.

Informeren, maar hoe?

Idealiter zou je geen van bovenstaande problemen willen hebben. Hoe ga je hiervoor zorgen? Sommige problemen bevinden zich binnen de organisatie, anderen weer erbuiten. Ik zal enkele mogelijke oplossingen aandragen die ervoor kunnen zorgen dat jouw experimenten tot minder misverstanden en problemen leiden.

Zet een logo / keurmerk op de site waaruit blijkt dat er op dat moment een test op de pagina draait
Eigenlijk een hele eenvoudige en logische oplossing als je kijkt naar de problemen. Iedereen wordt op de pagina geïnformeerd en er kan geen discussie zijn of de test wellicht al is afgerond of dat er nu wel of geen test draait. Daarnaast zou je aan het icoon / keurmerk ook functionaliteit kunnen hangen waarmee je de pagina in de standaardversie toont. Nadeel van deze oplossing is dat bezoekers zich bewust kunnen zijn van het feit dat ze aan een test deelnemen en wat invloed op je resultaten kan hebben. Wanneer ze ook kunnen switchen naar de standaardversie kan dat ook effect hebben (het zegt overigens ook wel iets over deze variant wanneer dit gebeurt). Je zou er ook nog voor kunnen kiezen om op elke pagina deze functionaliteit aan te bieden, waarbij je pas na het gebruiken van het icoon kan zien of een pagina onderdeel is van een test. Zo informeer je wel, maar niet direct, enkel als de bezoeker er om vraagt.

Booking.com koppelt het sessie ID aan elke pagina. Onderaan elke pagina zie je de eerste 5 karakters van je sessie ID, genaamd referentie-ID. Booking.com zou dit reference ID kunnen vragen aan de bezoeker wanneer hij of zij belt, Booking.com zou dan wellicht de sessie van de bezoeker kunnen bekijken, om zo geen problemen te krijgen met verschillende content. Ik heb geen idee of dit de waarheid is, maar het is geen gekke oplossing.

Geef iedereen toegang tot je experimenteersoftware
Door iedereen toegang te geven kan iedereen inzicht krijgen in de experimenten die live staan (behalve de bezoeker van je site). Dit kan het probleem deels oplossen. Het is een reactieve manier van het verkrijgen van informatie. Collega’s zullen pas na het zien van een verschil gaan controleren of er ook daadwerkelijk een experiment draaiende is. Daarnaast bevatten de meeste pakketten geen autorisatiebeheer, waardoor iedereen dezelfde rechten krijgt, waardoor experimenten door iedereen aan te passen zijn. Dit is niet wenselijk.

Begin een maillijst
Start een maillijst van alle belanghebbende en stuur een dag (of aantal dagen) voordat je een experiment live zet de informatie richting iedereen in de lijst. Hiermee houd je iedereen op de hoogte, behalve de bezoeker.

Social media / blog
Start een blog waar je al je experimenten aankondigt en wellicht behandelt en / of gebruik bijvoorbeeld Twitter om over al je experimenten te communiceren richting je klanten / bezoekers en interne medewerkers. Hiermee geef je complete openheid (wil je dat?) over waar je mee bezig bent, alleen ben je wel afhankelijk van de liefde voor lezen / social media van de bezoeker / klant / medewerker. Wederom een vrij reactieve manier.

Deel alles op het intranet
Intranet is een mooi medium om niet alleen de aankomende experimenten te tonen, maar ook om afgeronde experimenten te evalueren zodat iedereen ook weet wat het effect is geweest van de experimenten die zijn uitgevoerd. Nadeel: het is reactief en de bezoeker wordt niet bereikt.

Organiseer (maandelijkse) sessies waarin je experimenten toelicht
Ongeveer gelijk aan het delen op intranet, met als voordeel dat de belanghebbende ook vragen kunnen stellen en input kunnen leveren voor volgende testen. Daarnaast is een sessie / presentatie een leukere / interactievere manier om kennis te delen dan enkel via mail of intranet.

Sluit je interne organisatie uit van experimenten
Door je interne organisatie uit te sluiten van de experimenten voorkom je in het begin stadium veel vragen. Bijkomend voordeel is dat je experimenten niet ‘vervuild’ worden met data van interne medewerkers. Nadeel is dat de bezoeker van je site wel de experimenten ziet en daar vragen over kan stellen aan bijvoorbeeld collega’s van de klantenservice. Daarom is het uitsluiten alleen geen goede oplossing, je ontkomt er niet aan de organisatie ook te informeren over de experimenten.

Zorg ervoor dat de standaard versie altijd op te vragen is
Dit punt is eigenlijk al behandelt in het ‘icoon/keurmerk’ stuk, maar het is ook los daarvan goed om het aan te bieden. Je zou bijvoorbeeld met een URL parameter, bijvoorbeeld; ?versie=standaard, door kunnen geven dat de standaardversie van de pagina opgevraagd moet worden. De parameter is achter elke URL te plakken, waardoor je iedere URL in de standaardversie kunt opvragen.

Maak een roadmap voor een kwartaal waarin je alle testpagina’s opneemt
Dit is altijd goed om te doen. Je kunt veel experimenten al forecasten (bijvoorbeeld op productcategorie of product of sectie van de site). Hierdoor geef je de interne organisatie al een beeld van wat je van plan bent en zijn je collega’s niet direct verbaasd als er verschillen optreden. Deze oplossing is vooral goed voor de bewustwording, het je ervan bewust zijn dat experimenten altijd, op elke pagina uitgevoerd kunnen worden.

En nu?

De enige oplossing die redelijk generiek is, is de oplossing met het keurmerk/logo/referentie-ID, ik zou me kunnen voorstellen dat testpakketten deze functionaliteit aan hun software gaan toevoegen, of dat de WAA hier met een oplossing komt. Voor de overige aanbevelingen zal gelden dat iedere organisatie de beste oplossing voor die organisatie zal kiezen. Ik ben benieuwd of de genoemde problemen bij jou spelen en ik zou dan ook graag willen weten hoe je deze problemen ondervangt, of, wanneer de problemen zich nog niet voordoen, hoe je ze gaat voorkomen.