AB testen

A-B 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?

AB testen optimalisatie

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

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.

AB optimalisatie in patterns

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?

Hoe organisaties en haar gebruikers met elkaar omgaan op het web

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.

In dit artikel wil ik graag wat hoogtepunten van het festival met jullie delen en ik wil dit in drie onderwerpen doen:

• Nieuwe input
• Nieuwe visualisatie
• Nieuwe interface

Nieuwe input

“Bare” skin safe conductive ink

Eigenlijk een simpel idee; inkt die geleid, in zekere zin ook niet heel nieuw. Wat hier wel nieuw aan is, is dat traditionele geleidende inkt over het algemeen erg schadelijk en vol metalen zat en dit een volledig veilige (metaalloze) inkt is die je met water af kan wassen. De maker van deze inkt kan deze ook maken in met verschillende weerstand. Hierdoor kun je een op een volledig nieuwe manier interacteren en op een mooie manier van jezelf een stukje randapparatuur maken.

Air drawing

Ooit, lang geleden, heb ik wat 3d vakken gehad op school, 3d studio max, maya, dat soort dingen. Ikzelf ben hier nooit verder in gegaan omdat voor mijn gevoel dit op een te technische en onlogische manier vraagt om te ontwerpen. Gelukkig kwam ik in Linz de oplossing voor mij tegen; airdrawing. Eigenlijk te simpel voor woorden; men neme een pen met gyroscoop en sensor en je hebt de hardware die in 3 dimensies weet waar de pen zich bevind. We schrijven een stukje software die dit in 3d presenteerd en we zetten een 3d bril op. Vervolgens tekenen maar op je eigen 3d canvas.

Nieuwe visualisatie

Deep space

Deep space is een vorm van een 3d bioscoop maar bedoeld om iets te vertellen in plaats van een film af te spelen. Een verteller/gids gebruikt het scherm om een verhaal te vertellen, in het geval van ars electronica 2 verhalen, 1 van leonardo da vinci’s laatste avondmaal en 1 van de ruimte (vandaar de naam). Dit doet de verteller zo dat iedereen een 3d bril opheeft (en 3d beeld heeft) en met een iPod touch(!) te navigeren door de ruimte en langs het schilderij (of eigenlijk een fresco zoals ik geleerd heb)

Nieuwe interface

De 1e valt een beetje in de categorie “Ik weet niet precies wat ik hiervan moet denken…” Hiroshi Ishiguro heeft een robot gemaakt die een exacte gelijkenis van zichzelf is. Deze robot stond ook tentoongesteld op het festival en kon plotseling duits praten met bezoekers. Naast de robot was het misschien nog wel interessanter om te zien hoe bang mensen van dit schepsel waren.

Kaartinterface

Kaarten zijn hot, wanneer er een google maps achtige interface in een stuk software geplaatst kan worden dan gebeurt het, zeer vaak voegt het naar mijn mening niets toe maar het ziet er wel ‘tof’ uit. Wanneer iemand een google maps interface wil omdat het er tof uit ziet dan zou ik hem of haar zeker uitnodigen om de kaartinterface bij ars electronica te bekijken. Een tafel van 5 bij 3 met de kaart van linz, 4 projectieschermen (en 4 beamers) een boekje en een optische leespen. Het resultaat is een echt vette kaart interface; wanneer je met de pen over de tafel gaat verplaatsen de schermen mee, het boekje gebruik je als het ware om verschillende labels aan te klikken (zoals bij google maps ‘terrain’ of ‘ hybrid’) het boekje heeft echter nog veel meer zoals 1910, 1950, 1980 enzovoorts en bevolkingssamenstelling, diepte, temperatuur, zoveel er werkelijk in een boekje past.

Natuurlijk was er nog veel meer te zien en is dit het sneeuwvlokje op het topje van de ijsberg maar ik hoop dat dit een redelijke impressie geeft van wat er nog meer te zien was…

Ik onderken 2 verschillende type’s doelen: Gebruikersdoelen en producentendoelen, of misschien nog makkelijker: Consumenten- en Producenten doelen. Wat het verschil is tussen deze 2 lijkt me duidelijk, producent maakt en consument gebruikt.

Doelen

De gebruikersdoelen hangen erg samen met wie de gebruiker is, wie de gebruiker is hangt daarentegen weer erg samen met wat het producenten doel is van het product.

Wat je hier uit kan concluderen is iets waarvan denk ik veel user -noem iets – - noem iets- (user experience manager, user centered designer, user information architect) zijn nekharen overeind gaan staan. Namelijk dat de gebruiker en gebruikersdoelen afhangen van de de producent, de stoffige organisatie, de datzo’s. Dit is juist maar is niet een recept voor een slechte user experience, integendeel. Bovendien is dit vrij te gebruiken, wanneer je zegt, ik begin met de de gebruiker bepalen, dan een producentendoel en dan een gebruikersdoel dan doe je effectief hetzelfde maar in een andere volgorde. Wat belangrijk is, is dat de gebruiker bij zijn doel past, en het doel van de producent bij de gebruiker.

Laten we er van uitgaan dat je het met me eens bent en dit eigenlijk best een goede logica is.  Het producenten doel; je bent geneigd om te denken dat wanneer iemand een website, google/iPhone app, intranet of applicatie wil hij erg goed weet wat hij er mee wil. Ik heb ondervonden dat dit vaak helemaal niet zo is. Wat je vaak ziet is een soort van ‘ik ook’ mentaliteit. Mijn concurrent heeft een iPhone app dus ik wil dit ook. Hierbij krijg je een soort van drogredenatie: mijn concurrent heeft een iPhone app, ik heb soortgelijke doelen als mijn concurrent dus ik wil ook een iPhone app. Op zich een redenatie maar de winst zit hem in het afvragen wat ik wil bereiken voor mijn organisatie met mijn iPhone app.

Hoe kom ik er achter wat de producenten doelen zijn?

Lekker makkelijk antwoord: dat hangt er helemaal van af hoe de producent in elkaar zit. Soms is het stellen van een aantal goede vragen al voldoende, soms een workshop en soms kun je beter zelf de pet van producent op zetten en goed nadenken wat hij of zij met zijn of haar medium zou moeten bereiken. Ik heb ook een artikel geschreven over een valkuil bij het achterhalen van deze doelen.

Waarom is het dan zo belangrijk om deze doelen te achterhalen?

Uiteindelijk zijn het de doelen die de succesfactor bepalen. Maak ze, en streef ze na, het geeft een bepaalde richting aan je project en zorgt er uiteindelijk voor dat je een schone, duidelijk en efficient product maakt.

En de gebruikersdoelen dan?

Ja, daar kom ik nu op. We slaan de stap gebruiker even over want immers daar heb ik al een heel artikel aan geweid. Gebruikersdoelen zijn doelen die je aan de hand van een goede beschrijving van wie de gebruiker is kunt samenstellen. Een voorbeeld van een goed gebruikersdoel is: “De gebruiker wil een vergelijking van de verschillende prijzen van een product bij verschillende aanbieders (kieskeurig)”

Hoe kom ik achter de gebruikersdoelen?

Er zijn een paar goede methode’s om hier achter te komen. Mijn favoriet is natuurlijk weer “veel praten met gebruikers” maar in de echte wereld werkt dit niet altijd zo. Een andere goede vind ik het doornemen van correspondentie, ga eens door de algemene mailbox, neem eens wat post door en luister eens met een spreekwoordelijk half oor mee met mensen die een telefoongesprek aan het voeren zijn, hier komt ontzettend veel verborgen informatie en veelal gebruikersdoelen naar boven. Een andere goede manier is om naar de concurrenten te kijken. Wat doen zij, en wat kunnen hun gebruikers doen. Tevens is het heel waardevol om te kijken naar de content die er nu al beschikbaar is. Deze zegt veel over wat gebruikers zouden kunnen doen.

Waarom beschrijf ik deze doelen dan weer?

Twee redenen: de 1e is dezelfde als de producentendoelen; richting, visie, focus, helderheid, dat soort powertermen. De 2e is heel simpel, om je producentendoel te valideren. Deze 2 hoeven zeker niet hetzelfde te zijn maar ze moeten op de een of andere manier wel verenigbaar zijn (de taak).

Tot zover mijn doelen; alleen taak blijft nog over, deze binnenkort

Het belang van goed testen weer eens aangetoond!

Ps. Spambots waren op wonderbaarlijke wijze wel in staat om een reactie achter te laten… :S

Voor de mensen die geen zin/tijd/verbinding hebben om de hele presentatie te bekijken heb ik hem kort vertaald en samengevat:

Best practises in web form design:

1. Path to completion
   Zorg ervoor dat de gebruiker in 1 lijn van boven naar onder het formulier kan afonden.
   Zorg er voor dat er een duidelijke lijn is in de stappen van het formulier
2. Label uitlijning
   De plaats waar je het label zet voor in inputveld is belangrijk: meestal zijn verticaal uitgelijnde labels beter wanneer een formulier volledig ingevuld moet worden en links uitgelijnd wanneer er maar een aantal input velden ingevuld moeten worden. Voorkom labels in de inputvelden
3. Help & Tips
   Zorg er voor dat de helpteksten relevant zijn. Vermeld waarom je bepaalde informatie vraagt. Een mooie oplossing is het gebruiken van ‘inline helpteksten’ waarbij je de tekst toont wanneer de gebruiker op een bepaald deel van het formulier zit.
4. Directe validatie
   Valideer wanneer de gebruiker een veld invult. Met name voor bv gebruikersnamen. Maar ook wanneer bijvoorbeeld je een verkeerde geboortedatum invult.
5. Primaire en secundaire acties
   Het is belangrijk om de meest belangrijke actie de meest opvallende knop/link te maken in een formulier. Zo voorkom je dat gebruikers op de verkeerde knop drukken
6. Actions in progress
   Laat zien wanneer de gebruiker moet wachten.
7. Errors
   Er zijn goede guidelines om errors te tonen. Laat de error bovenaan de pagina zien op een visueel opvallende manier en spiegel deze visualisatie bij het input veld met de error.
   Zorg er voor dat de gebruiker geholpen wordt om de error te herstellen.
8. Onnodige input
   Probeer zoveel mogelijk input velden te vermijden. Probeer input velden zelf te vullen aan de hand van eerder ingevulde informatie.
9. Formulier indeling
   Probeer de typen informatie te structureren als een dialoog, niet vanuit een organisatie. Spreek de taal van de gebruiker.
10. Gradual engagement
    “Lok” de gebruiker om het formulier in te vullen. Zorg er voor dat een formulier niet als een formulier voelt.

In deze post wil ik een stuk schrijven over wat ik noem het User – Task – Goal model. Ofwel: gebruiker – taak – doel. Waarschuwing, voor veel mensen zal dit een open deuren parade zijn maar ik denk dat het misschien een nieuw inzicht geeft in waar we vaak de fout in gaan als we nieuwe dingen maken.

User

Open deur nummer 1; wie is onze gebruiker. Wat kan hij, wat wil hij, wat weet hij maar vooral; wie is hij (of is het eigenlijk een zij)? Natuurlijk is er (bijna) nooit sprake van 1 gebruiker maar altijd van een groep. Belangrijk is dan ook om van die groep de overeenkomsten te pakken. Ik geloof heilig dat de beste manier om de gebruiker te bepalen is simpelweg door met veel van de representatieve gebruikers te praten. Hierna kun je goed een persona schrijven voor deze gebruiker, of nog beter een aantal persona’s op een aantal verschillende typen gebruikers.

Hier vind je meer over de gebruiker

Taak

De taak is wat de gebruiker naar het doel brengt. Ofwel, als we niet weten wat het doel of wie de gebruiker is, dan kunnen we hier ook geen taak voor maken. Ironisch genoeg ligt hier vaak de focus op. Je snapt de vicieuze cirkel waarschijnlijk al; er wordt een taak gemaakt voor een verkeerde gebruiker of een verkeerd doel en die blijkt vervolgens niet te werken, terwijl de taak goed is. De taak is overigens wel juist hetgene waar in een project zowel een developer als een designer veel invloed op heeft. Wil je staven of hetgeen wat jij ontwerpt of wilt maken klopt bij de gebruiker dan is het verstandig om jouw idee uit te schrijven in de vorm van een scenario om zo te kijken of dit bij de persona (zie user) past.

Doel

Een usability vooroordeel is dat je te veel macht geeft aan de gebruiker, dat de gebruiker de designer is. Of dat de gebruiker helemaal niet weet wat hij wilt, hij heeft er immers niet x jaar voor gestudeerd. Dus kijken of het doel bij de gebruiker past, dat kan dan natuurlijk niet, immers wij zijn de professionals, niet de gebruiker. Het zal je niet verbazen, ik ben het hier natuurlijk volledig niet mee eens. Wanneer de gebruiker zijn doel niet behaalt uit het product is het voor hem (of haar) doelloos. Waarom zou hij het nog gebruiken. Anderzijds hebben de eigenaren van de producten vaak een ander doel dan de gebruiker. Bijvoorbeeld is het ultieme doel van kieskeurig.nl niet dat gebruikers goed hun aankopen kunnen vergelijken maar dat deze gebruikers via kieskeurig doorklikken naar een webwinkel en daar iets kopen. De uitdaging zit hem hier dus in het samenvoegen van:

• Mijn doel
• Het doel van mijn gebruiker
  Tot:
• Ons gezamenlijke doel

Hier vind je meer over doelen

Tot zover in het kort (470 woorden) de introductie van het gebruiker – taak- doel idee. Wordt vervolgd, dat beloof ik!

Oh ja.. Moest je je afvragen waarom ik een potlood heb als avatar bij deze post, ook dat in de volgende (wat een cliffhanger he!)

1. Speelbal
2. Potentieel
3. Professioneel
4. Pubertijd
5. Liefdadigheid
6. Volwassenheid
7. Vergetelheid

1. Speelbal

Hier zou ik ook voor kunnen typen idee. Eigenlijk is een speelbal meer een uitwerking van een idee. Het idee kan heel origineel zijn Last.fm is hiervan een redelijk voorbeeld, amazon.com een nog betere, maar ook gewoon een kloon of uitbereiding van een bestaand idee; hieronder schaar ik graag hyves, facebook en myspace.

Een enthousiasteling of een groep enthousiastelingen beginnen dit idee uit te werken. Deze fase kenmerkt zich door veel fouten in zowel design als techniek. Het kenmerkt zich echter ook door onderscheidend vermogen, je proeft hierbij nog de persoonlijkheid van het idee goed. Het is leuk.

2. Potentieel

Het idee slaat aan en nu blijkt er potentieel te zijn. Hierdoor is het de vrijblijvendheid er vanaf. Het idee moet snel professionaliseren. Hierbij zie je vaak dat de early adopters, de fans, teleurstellingen moeten gaan slikken. Bepaalde features worden weggesneden.

3. Professioneel

De makkelijkste manier om deze fase te herkennen is omdat deze veelal wordt ingeluid door een overname. De website is geen idee meer, de website is een business case. Nu wordt er professioneel gewerkt, zowel op het gebied van design als techniek worden grote verbeterslagen gemaakt omdat er nu grote(re) belangen met de website gemoeid zijn.

4. Puberteit

Puberteit is een moeilijke fase, ook voor websites. Plotseling worden ze als volwassen behandelt en komen allerlei licht kinderlijke zaken aan de orde. Privacy, auteursrechten, ethiek.. allemaal vrij nieuwe begrippen voor de website maar hier moet wel rekening mee worden gehouden. Deze fase kenmerkt zich door kritiek uit allerlei hoeken, en met name uit hoeken die niet als ‘doelgroep’ bestempeld worden.

5. Liefdadigheid

Nu komt de grote inhaalslag. De site heeft maatschappelijk belang (en waarschijnlijk in fase 4 maatschappelijke schade toegebracht) Dit is misschien wel de mooiste en beste fase van de website, wat ooit een leuk idee was maakt deel uit van de wereld en maakt de wereld een stukje beter/schoner/slimmer/mooier.

6. Volwassenheid

Wanneer is een site volwassen. Als de site niet meer als .nl of .com wordt uitgesproken (tenzij dit specifiek de bedoeling is; bijvoorbeeld wederom last.fm) en al helemaal als het een werkwoord of zelfstandig naamwoord is geworden; googlen, hyven, heb jij al een linkedIn?

7. Vergetelheid

Treurig, maar dit gebeurt. De site is volwassen en het nieuw is er af. Een nieuwe speelbal is ontstaan en de site wordt vergeten en zelden aan teruggedacht. “Oh ja, CU2, dat had ik ook ja” Het treurige einde van de levenscyclus van onze website.

Whats in it for you? Whats in it for me?

Simpele vragen waarvan je zou verwachten dat je ze gemakkelijk kan beantwoorden maar al te vaak kan ik een van de twee, of beide vragen niet beantwoorden.

Wat kun je dan doen om die neerwaardse spiraal uit de vorige post te doorbreken?

Ik heb hiervoor 6 suggesties

1. Don’t sell it; Fix it or close it

Eigenlijk is het heel simpel, identificeer de spiraal, geef de situatie eerlijk weer en ga niet op zoek naar kleine successen die je hebt geboekt. Gebruik deze successen om de situatie te repareren.

2. Verkleining

Wat je soms helaas zit is dat er een vergroting plaats vindt; ‘werkt het een niet, dan werkt het ander wel’ Het is ook niet makkelijk; je geeft in principe het falen van je portal toe. Verkleining helpt echter wel, waar je eerst 10 users op 20 plekken hebt kun je er beter 8 op 5 hebben.

3. Centraliseer

Dit is het gevolg van verkleining, door zo veel mogelijk plekken samen te voegen voeg je ook gebruikers samen. Een goede tool om het centraliseren te doen is door middel van card sorting. Laat je gebruikers kiezen welke onderdelen goed bij elkaar passen.

4. What’s in it for you?

Als de portal niet gebruikt wordt dan ziet de gebruiker niet in wat zijn meerwaarde hierop is. Is die er niet, dan moet je heel erg goed nadenken over de waarde van jouw portal en waarschijnlijk is dit dan ook het gene wat je op moet lossen. Is die waarde er wel, dan kent de gebruiker deze duidelijk nog niet. Oplossing? Toon de gebruiker wat de meerwaarde voor hem, van zijn input is.

5. Wees zelf de meest actieve user

Dit is eigenlijk wel het minste wat je kunt doen. Geef zelf het goede voorbeeld. Dit kost veel tijd en met name veel doorzettingsvermogen, je zult immers weinig feedback krijgen van jouw inspanningen, sterker nog veelal wordt het nauwelijks tot niet bekeken wat jouw input is. Maar zoals altijd, goed voorbeeld doet volgen… hoe lang dit ook kan duren.

6. Verwijder de clones

Dit plaatje wil ik direct nomineren voor lelijkste illustratie van dit milennium, echter wat ik probeer te illustreren hier is een maf fenomeen.

Wanneer gebruikers een nieuwe methode gepresenteerd krijgen voor het uitvoeren van hun taken gedragen ze zich bijzonder natuurlijk. De weg van de minste weerstand. In dit plaatje kan je zien dat de nieuwe methode van het uitvoeren van taken veel makkelijker is dan de oude methode, echter het aanleren van deze nieuwe methode duurt initieel langer dan de oude. Gevolg, gebruikers blijven de oude methode gebruiken.

Dit fenomeen houdt mij al lang bezig, hoe doorbreek je dit. Heel eerlijk heb ik hier nog geen sluitend antwoord op; dingen waar je aan kunt denken zijn, visueel aantrekkelijker maken van een nieuwe methode, leuker maken en belonen voor het aanleren van de nieuwe methode.

Echter in het perspectief van dit verhaal zou ik zeggen. Haal de oude methode weg en verplicht gebruikers de nieuwe te gebruiken. Dit kun je geleidelijk doen maar waarschijnlijk is het beter om alleen de nieuwe methode te gebruiken. De nieuwe methode in dit geval, onze user generated content portal.

user content deadlock

“oja.. en we willen ook user generated content”

Dat zou een manager kunnen zeggen die niet al te veel van nieuwe media af weet. En daar begint voor mij de portal – content deadlock. We maken een portal voor user generated content en daardoor wordt de portal interessant voor bezoekers, hierdoor krijgen we meer user generated content en wordt de portal nog interessanter voor bezoekers en ga zo maar door. Dat moeten we hebben!

Echter een platform zorgt niet voor user generated content. De naam zegt het al, users zorgen voor user generated content.

Zelf zie ik het ook gebeuren. Een intranet waar ik veel op actief ben (overigens niet bij mijn klant ) wordt slecht gebruikt. Er zijn talloze blogs, wiki’s fora’s waar veelal 1 bericht op staat. “Welkom op het forum”  “Dit is de 1e post van het blog!” “welkom bij de sharepoint wikipagina’s” En hierbij gebeurt precies het omgekeerde van wat je wilt. Er is wordt nauwelijks user generated content gecreëerd, hierdoor is het niet interessant voor bezoekers, hierdoor wordt er nog minder user generated content gecreëerd en is het nog minder interessant voor bezoekers. De portal sterft een langzame dood.

Nu wordt het voor mij interessant. Hoe komt het dat de gebruiker zich niet geroepen voelt om content te schrijven? Symptomen zijn makkelijk te vinden: “we kunnen niets vinden op het intranet” [Hoe kun je iets vinden wat er niet of nauwelijks is?] “Het visual design is niet aantrekkelijk” [user generated content.. verbeter dit] “Medewerkers snappen het nut niet”. Al deze redenen zijn surface redenen maar het antwoord ligt niet in het verbeteren van deze symptomen. Het antwoordt ligt aan de opzet van het platform.

“Think big, start small, scale fast” De grootste fout die gemaakt kan worden is door een compleet lege portal neer te zetten om te vullen waarbij de structuur al helemaal is voorgedefinieerd. Immers de leegte regeert. Begin klein en maak je geen zorgen over de structuur. Die structuur definieeren de gebruikers aan de hand van de content die ze schrijven.

Schrijf zelf. Schrijf zoveel je kan en schrijf vooral alles ongeacht de kwaliteit. Je wilt laten zien dat iedereen meedoet, laat iedereen meedoen en niemand afschrikken door je showcase van je onwijze schrijftalent (hier ben ik vast een mooi voorbeeld van…)

Denk aan de 9 10 drives for user generated content zoals ik deze heb beschreven overgeschreven op de design by fire conferentie.

Denk aan de gebruiker. Naast de drives voor deze gebruiker heeft de gebruiker ook behoefte aan functionaliteiten en wellicht ook behoefte aan het weglaten van bepaalde functionaliteiten.

Denk… Wanneer je een idee hebt voor user generated content, gooi het weg, begin opnieuw, wees vooral creatief.

“jeetje wat een verhaal.. laat die user generated content maar zitten”

In de volgende post, wat ik geprobeerd heb om de portal – content deadlock te doorbreken