Einstein zei:
“Insanity: doing the same thing over and over again and expecting different results.”
Ik gebruik deze quote soms in presentaties om illustreren hoe organisaties vaak te statisch met hun website omgaan. Alle resources worden geïnvesteerd in het bouwen van de website die vervolgens 2 jaar lang amper verandert. In die twee jaar wordt wanhopig geld gestopt in bannercampagnes en andere waardeloze externe vormen van online marketing.
Maar echt beter worden de resultaten niet, en na 3 jaar wordt geconcludeerd:“Het Is Tijd Voor Een Redesign!”. We gaan usability onderzoek doen! Alles moet anders en beter! Of nog erger: We gaan eerst een compleet nieuwe site lanceren, en daarna usability onderzoek doen want de huidige site is ZO SLECHT dat we die niet eens willen onderzoeken!
En hierover gaat de Wet van Timmerman (enige bescheidenheid is me vandaag even vreemd 😉 ):
Insanity: Iets compleet anders doen en hopen dat je leert van de verandering.”
Ik zal proberen uit te leggen wat mijn wet inhoudt, en waarom hij zo belangrijk is voor de ontwikkeling en verbetering van websites.
Chaos in web analytics en KPI’s
Wat er na zo’n redesign traject volgt: chaos. Alle analytische gegevens veranderen doordat de webpagina’s en de links ertussen veranderen. Als er al KPI’s (Key Performance Indicators, de cijfers waar je op stuurt) waren kunnen ze niet meer vergeleken worden met de vroegere cijfers. En vaker wel dan niet wordt de (her)implementatie van Analytics niet goed gedaan, er worden bijvoorbeeld onderdelen of pagina’s vergeten.
Onduidelijke invloed van onderdelen van de website op de resultaten
Eigenlijk de grootste reden voor het optekenen van mijn Wet van Insanity: Je weet niet welke onderdelen van de “verbeterde” website verantwoordelijk zijn voor het succes, of het falen. Simpel gezegd: je leert er niks van, dus je organisatie wordt er niet beter van. Ik probeer vaak uit te leggen dat het succes van een website niet wordt bepaald door de website, maar juist door de organisatie. Als de organisatie niet beter wordt, is een redesign niks meer dan paarlen voor de zwijnen, of een aap met een gouden ring.
Om even in de spreekwoorden te blijven: Meestal wordt met een redesign ook de baby met het badwater weggegooid.
Mea Culpa: Ben ik medeverantwoordelijk voor het stoppen van Skoeps?
Ik heb dit vorige zelf mogen meemaken bij het redesign van Skoeps eind 2006. Skoeps ging toen al niet zo goed en is inmiddels opgeheven. De mensen achter Skoeps kenden mij van usability werk dat ik voor de Volkskrant en NRC had gedaan, en ze wilden graag snel een opfrisbeurt voor de website omdat er een grote marketingcampagne aan zat te komen. Belangrijkste doelen waren het creëeren van een meer overzichtelijke homepage en het verhogen van conversies als het insturen van een Skoep en het embedden en doorsturen van Skoeps.
Ik heb toen een nieuw interactie ontwerp gemaakt en dat samen met een goede designer (die inmiddels ook het nieuwe Usarchy redesign heeft gedaan) binnen een week tussen kerst en oud & nieuw 2006 in elkaar gezet. We waren er zelf erg tevreden mee. Feedback van iedereen om ons heen, Skoeps mensen incluis, was zeer positief. Een maand later ging de opgefriste Skoeps live.
…pageviews per bezoeker ging met 10% tot 20% omlaag. […] oorzaak of oplossing hebben we nooit kunnen achterhalenResultaat: het aantal pageviews per bezoeker ging met 10% tot 20% omlaag, en de andere KPI’s veranderden niet significant. (Sk)Oeps! Dagen graven in de Google Analytics gegevens gaf ons allerlei clue’s over wat er aan de hand kon zijn, maar een harde oorzaak of oplossing hebben we nooit kunnen achterhalen.
Er was simpelweg teveel veranderd om goed te kunnen zien wat het effect was alle losse veranderingen van het redesign. Ik denk dat er zowel positieve als negatieve factoren inzaten, die elkaar deels in balans brachten en in het geval van de pageviews per bezoeker dus negatief uitpakten. Ook wordt vaak vergeten dat de website maar 1 van de factoren is die van invloed is op online conversie. Wellicht is gewoon een bepaald maximum percentage van de bevolking ge&iul;nteresseerd in het uploaden van Skoeps, en hadden we die al bereikt.
In lijn met mijn gevoel over Hyves denk ik dat de afname van chaos in dit geval zorgde voor minder doorkliks. Bezoekers konden waarschijnlijk beter de voor hen interessante Skoeps vinden, maar werden minder afgeleid/verleid om op andere dingen te klikken.
Grotere webprojecten hebben een grotere faalkans
Misschien wel een eigen wet waard: hoe groter het webproject, hoe groter de kans op falen. Vorige week gaf ik een workshop bij een grote nieuwswebsite, waarbij alle deelnemers het met me eens waren dat er heel veel moest veranderen in de site.
Ik heb ze op het hart gedrukt dat een groot redesign nu net niet was wat ze nodig hadden. Sterker nog: de grootte van het initiële project en de hoge doelen die ze zichzelf bij de eerste lancering gesteld hadden, konden wat mij betreft wel eens verantwoordelijk zijn voor de tegenvallende resultaten.
Als ze zich nu weer in een enorm project storten, blijft de kwaliteit van het totaal waarschijnlijk achter. Je hebt simpelweg niet genoeg geld en goede mensen in huis om zoiets in een keer te doen. De concurrerende nieuwssites hebben jaren gedaan om te komen waar ze nu zijn, dat haal je niet in een paar maanden in.
Je kunt beter focussen op het stap voor stap verbeteren van onderdelen waarvan je denkt dat ze veel invloed hebben op je KPI’s. Tegelijk was er het besef hoe moeilijk het is om losse onderdelen van een website te veranderen, alleen al door technische beperkingen van het bestaande platform. Je krijgt dan de paradox dat je je technische platform helemaal omgooit, maar aan de voorkant nog slechte dingen laat bestaan. Dat is de enige manier om de factoren te isoleren die van invloed zijn op de resultaten.
Wat moet je dan wel doen?
Met de billen bloot! Niet voor niets gaan websites tegenwoordig eerst in “BETA” voordat ze officieel gelanceerd worden. Auto site Zomoto is een voorbeeld: de ex-directeuren van Funda zetten vrij snel een enigszins werkend prototype online om te leren van de reacties. Enkele maanden later was het al tijd voor een versie 2, nog voordat bekend werd of ze met de eerste versie een Usability Award zouden winnen.
Ik hanteer dezelfde taktiek met mijn opleidingen site Eduhub. Die staat al maanden live en elke week komen er onderdelen bij. Wij weten wel waar we naartoe bouwen, een prototype is allang klaar. Maar onze prioriteiten bepalen we naar aanleiding van huidige resultaten en feedback van gebruikers. Zo hebben we al geleerd dat de basale features die we nu bieden, voor veel mensen al voldoende zijn om een opleiding te vinden. Het filteren, bewaren en vergelijken van opleidingen bouwen we dus pas nadat we ons gefocussed hebben op het importeren van nog veel meer opleidingen en trainingen waarmee we een compleet aanbod krijgen.
Bij een redesign is het dus vooral van belang dat je losse onderdelen eerst test in bijvoorbeeld een A|B test. Je verandert een onderdeel en laat dat nieuwe ding aan slechts een deel van je bezoekers zien. Vervolgens kijk je of die bezoekers zich anders gedragen en op welke manier.
Dit traject is absoluut niet makkelijk en soms zelfs paradoxaal. Maar ik geloof, door schade en schande wijs geworden, dat het de enige manier is naar succes op internet.
Deze wet is nog in beta!
Feedback op mijn “wet” is van harte welkom. Ik weet zeker dat er veel aanvullingen mogelijk zijn, en natuurlijk ook uitzonderingen of aanmerkingen. Kom maar op! Ik zou hypocriet zijn als ik veranderingen niet zou verwelkomen 🙂
usarchy.com 
Je wet is nogal vaag..
Iets compleet anders doen en hopen dat je leert van de verandering.
Compleet anders, dat is wel erg grondig, en hoeze leren van de verandering? van het proces van veranderen, of van de uitkomst van de verandering? En wat wil je dan leren.
Insanity: Totaal herdesign in de hoop oude doelen wel te bereiken?
Maar omdat nog maar wat over Zomoto te typen, wat ik daar geleerd heb, is wellicht dat de gebruiker niet perse wil wat het handigste is, maar wat hij/zij het meest gewoon is.. Een revolutie in verandering werkt daarom ook zelden..
De gebruiker is er niet ‘klaar’ voor, en gaat maar weer snel terug naar de oude vertrouwde concurrent. Vaak genoeg zit ik echter nog in meetings waar gezegd wordt, “het maakt me niet uit wat de rest van de wereld doet, wij gaan het compleet anders doen, het is tijd voor vernieuwing.” Waarop ik dan maar zachtjes probeer te zeggen, dat concurrent zelden dom zijn, en dat er meestal goede redenen zijn waarom dingen zijn zoals ze zijn..
Ik vind de gedecentraliseerde A|B test/bouwmethode van Amazon wel interessant (lastig om te vinden, iedere zoekopdracht levert vooral boeken op, wellicht dat iemand anders nog een artikel daarover weet)
LikeLike
@Sjors: Zeer interessante post over A/B testing @Amazone.
…
LikeLike
(SK)Oeps, Hierbij de link nogmaals.
AB testing at Amazon and Microsoft
LikeLike
Gister een training van Omniture bijgewoond. De trainer gaf een voorbeeld van een A/B test. Het was een klassiek voorbeeld van testen om het testen, maar niet wetende wat je test. Hij gaf aan dat ze in een redesign de zoekfunctie een andere plaats hadden gegeven. Als succes event werd de revenue en aantal orders op de website gemeten :-s…. Het voorbeeld wordt aangepast ;-).
Mijn boodschap dus: inderdaad testen op losse onderdelen, maar ook vooral in de gaten houden dat causale verbanden gelegd kunnen worden door de juiste succes events te meten welke aan de veranderingen toe te kennen zijn.
LikeLike
Check crazyegg punt com, daar kun je heatmappies krijgen, ik neem aan, dat je het al kent 🙂
LikeLike
Dag Ruben,
Wederom een goed artikel. Ik ben het persoonlijk eens met je stelling om minimale stapjes te nemen en daarvan het effect te meten in plaats van hele grote stappen en niet weten welke aanpassing nou precies een positief of negatief effect heeft.
Echter valt me wel op dat de sites die ik onder handen neem vaak zo verouderd zijn dat een re-design onontwijkbaar is.
LikeLike
Sjors: Als ik vaag ben, hier de “definities” achter mijn “wet”:
Compleet anders is inderdaad grondig, maar dat is wat er bij een redesign gebeurt. Zomoto is wat dat betreft tegelijk een slecht voorbeeld, want het nieuwe design is geen evolutie maar een revolutie, dus ze kunnen onmogelijk weten aan welke veranderingen de (evt) verbeterde resultaten liggen.
Leren van verandering: ik bedoel “hetgeen veranderd is” (duh? :))
En wat je wil leren: je wilt weten wat het effect van de verandering is, zodat je het kunt repliceren en er andere conclusies uit kunt trekken.
Wat je zegt over vernieuwing en aansluiten bij het bestaande: 100% mee eens. En ik vind: als de gebruiker het “handiger” vindt en jij niet, is het toch handiger. In “handig”, of laten we zeggen usable/gebruiksvriendelijk, zit namelijk ook het leren/herkennen verscholen. Als je iets eerst moet leren moet de learning curve heel plat zijn, of de verbetering enorm en aantoonbaar en begrijpbaar groot. Mee eens?
Wat bedoel je met gedecentraliseerd ivm Amazon?
Camiel: top thanks voor de link. Ik heb deze en deze papers in mijn toread map staan, en het artikel Working Backwards van Amazon’s CTO Werver Vogels gelezen. Kern: eerst eeen faq en persbericht schrijven voor de launch, dan het product documenteren, en het daarna pas bouwen.
Verder werd gelinked naar dit aardige artikel over A|B testing.
Er wordt verder gelinked naar een superlang interview met Jeff Bezos bij Harvard Business Review, maar dat is afgesloten voor niet betalende subscribers. Iemand een idee hoe we dat toch kunnen lezen, ziet er interessant uit.
Yvonne: aardig voorbeeld inderdaad van A|B testing gone haywire 😀 Hoewel die test nog best kan werken als je hem een paar maanden laat lopen misschien?
Jurgen: Ik ken je gevoel, heb het zelf ook vaak meegemaakt dat ik samen met een opdrachtgever concludeerde dat een redesign toch de eerste stap moest zijn. Aan de andere kant denk ik dat dat vaker wordt geconcludeerd dan nodig is, puur omdat het de makkelijkste weg is…
LikeLike
Dag Ruben,
Vaak kom ik website als deze tegen (http://www.westfalengassen.nl/start/index.php). In deze gevallen zeg ik: Re-design.
Zou jij het bij dit voorbeeld anders aanpakken?
LikeLike
@ Ruben: ook dan weet je niet of de succes events direct toe te wijzen zijn aan de verplaatsing van de searchbox. Het enige succes waarmee mijn inziens een causaal verband gelegd kan worden is het aantal keren dat de zoekbox gebruikt wordt. Maar de trainer zag dat nu ook in;-)
LikeLike
Pingback: bligg.be
Ha, om nog maar even op Amazon terug te komen, (en volgens mij komt deze info uit een presentatie van Werner Vogels Eday 2006) Amazon zou niet zo zeer redesign centraal aanpakken met een redesign team, maar op allerlei fronten allerlei projecten hebben lopen, en die dan onder een beperkt aantal gebruikers willekeurig testen. Om maar eens een voorbeeld te geven, het zou dan kunnen dat je ergens op de website zomaar oranje ipv gele sterretjes tegen komt, of dat je een ranking van 1 tot 10 kunt geven (om maar eens wat te verzinnen) Maar dat je dit verder niet ziet terug komen. Amazon krijgt dan direct feedback door dat ze het kunnen vergelijken met een situatie waarin de verandering niet aanwezig is/was. Maar wellicht heb je daarvoor de enorme aantallen van Amazon nodig?
(ps. je duh was terecht denk ik, maar sinds ik de lezer ben en jij de schrijver, is mijn vraag altijd meer terecht 😉
LikeLike
Leuk onderwerp. Eens met bijna alles. Toch…
Zie Gordon Ramsay: Oorlog in de Keuken. Als je weet wat wel en wat niet werkt, kun je wel eerst heel lang gaan testen met die frikadel op het papieren bordje in dat winderige frietkot zonder verwarming, maar is dat niet zonde van de tijd (en het geld)? Ik denk dat de opdrachtgever in dit geval graag (extra) betaalt voor de kant en klare expertise om het eens anders aan te gaan pakken. En als je je presenteert als ervaren chef, moet je weten hoe je bepaalde bochten afsnijdt.
Again, zie Gordon Ramsay. Ga op bezoek als klant. Bekijk de kaart. Bestel wat lastigs. Doe het veldwerk in het dorpje, of die stad. Spreek met huidige en potentiele klanten. Voel medewerkers en directie eens aan de tand. Vervolgens moet jouw ervaring en visie voldoende zijn voor een goed plan. Wat mij betreft ten minste. Testen welke van de huidige gerechtjes nu wel of niet verkopen, bij wie en waarom, split testing op die appelmoes met of zonder kers… Door te sec analytisch te werk te gaan, kun je in veel gevallen ook je doel voorbijschieten denk ik.
Then again: lees het verhaal over McDonald’s (Behind the golden arches). Het gouden recept van die keten is eindeloos finetunen, naar bovenstaand model.
De wet moet mischien voorzien in een paar subs voor bepaalde typen klanten?
LikeLike
Ha vanmorgen bedacht ik zomaar wat ik bedoelde met mijn opmerking. Nu is mijn Nederlands absoluut niet mijn sterkste kant, maar leren van de verandering, dat slaat dan toch op het proces van veranderen? Wat je dan zou kunnen leren is bv, veranderingen doorvoeren vereist bijzonder veel geduld en vergaderen. Terwijl leren van het veranderde, leren van de nieuwe situatie betekend? Edoch, geen idee of dat correct is, maar dat bedoelde ik er mee. /genoeg gezever
LikeLike
Ik ben blij dat je RSS-feed vandaag stuk was. Zo heb ik dit artikel nog eens een keer voorbij zien schieten. Fijn stuk. Ben bang dat het toch niet gaat aanslaan bij de meeste klanten. Je wet is geschikt voor bedrijven met een lange adem, waar een web-afdeling werkt met mensen met lange termijn visie. Geduld is volgens mij niet de meest in het oog springende eigenschap van de meeste web-managers. De meesten springen van project naar project, met als gevolg dat eerder voor een redesign wordt gekozen (grote stappen, vlug thuis) dan stapje voor stapje naar een optimaal resultaat.
LikeLike
Pingback: Usability mythe #4: Usability onderzoek geeft het antwoord - Usarchy
Pingback: 3 Recessie-proof Usability Principes - Usarchy
Pingback: Het verschil tussen conversie optimalisatie en usability - chapter42.com.com
Pingback: Het verschil tussen conversie optimalisatie en usability - chapter42.com