Posts Tagged ‘test’

Erfaringer med ‘website optimizere’

fredag, maj 13th, 2011

Jeg får lyst til at dele lidt få erfaringer med at lave test med website optimizere.

Jeg har arbejdet med 3: Google Website Optimizer (GWO), Visual Website Optimizer (VWO) og Optimizely. Sidstnævnte er min nye favorit, grundlæggende fordi:

  1. Måden man oprettet tests er enkel, visuel, brugervenligt (ja!).
  2. Det er supernemt at lave mål (fx tælle konverteringer) – også flere af dem og sammensatte mål.
  3. Hele interfacet virker upåklageligt i firefox 4 (modsat fx VWO) – det er effektivt som værktøj.
  4. Den kode der skal indsættes på websitet er enkel (modsat fx GWO).

VWO og Optimizely har en fordel fremfor Google, nemlig at man kan opsætte testen "direkte på sitet". Jeg skal ikke gøre det i koden, men ser sitet foran mig og kan klikke mig frem til ændringer jeg vil lave. Desværre er VWO's editor ikke så velsmurt og da jeg arbejder ret iterativt (seeing-moving-seeing), så skal jeg åbne og lukke og redigere mange gange, hvilket er tungt tungt tungt i VWO. Det er endnu værre i GWO, fordi jeg kun kan bruge kode. Så jeg skal visuelt rette siden til i et andet værktøj og så kopiere koden over i GWO.

GWO koster gratis, hvilket er umuligt at slå, men er også mere "hakkebræt". Jeg skal indsætte mindst 3 scripts i Googles version – endda forskellige steder, mens jeg i de andre kun skal indsætte 1. Om Googles version er mere effektiv, rent performance-mæssigt, aner jeg ikke noget om.

I Optimizely bruges <div> tags som målepunkter. Det er genialt. Ud over at det virker rigtigt godt, så betyder det også at jeg fx kan markere en hel menu og gøre den til et mål. Det giver rigtig god mening, hvis jeg vil vurdere om brugeren klikker på menuen eller på indholdet. I de andre to værktøjer, oplever jeg det som at jeg skal vælge bestemte elementer eller links.

Optimizely har også lavet en anden genial feature. Nemlig at kan kan indsætte et javascript event et vilkårligt sted på websitet og så kalde det som mål fra sine tests. Jeg kan altså indsætte et event når min kunde putter noget i kurven og så kalde det event fra nye tests jeg opretter. Jeg skal ikke tilbage og rette i det events kode eller oprette event for hver test. En kodestump der kan kaldes alle steder fra. Det er virkeligt godt tænkt.

Det betyder at jeg fx kan køre mine tests rundt omkring på sitet, men altid forholde dem til vigtige overordnede konverteringer, typisk mine salg.

Optimizely viser ikke, som de andre to, resultaterne som grafer. Hvilket jeg egentligt er begyndt at sætte pris på. Graferne er ofte lidt misvisende. Kurverne krydser eller ligger meget tæt og sender nogle signaler der er svære at tyde – så jeg synes man læser sig blind på dem. Nogle gange tolker jeg på graferne, selvom der slet ikke er noget statistisk belæg for det. Optimizely har lavet et enkelt interface, der erfaringsmæssigt er bedre at arbejder med en VWO, selvom sidstnævnte virker mere funky i designet. Men da vi taler om et værktøj, så giver det mening for mig at søge en vis stringens og enkelhed, den kommer en til gode synes jeg.

Optimizely grænsefladen
Optimizelys grænseflade for resultater.

Optimizely er lidt dyrere. Det koster 79$ om måneden hvis man skal op på 20.000 besøg. Det er i den dyrere ende, men ok hvis man arbejder seriøst med et. Ellers har de en lille pakke til 19$ og der bør alle kunne være med. De har selvfølgelig også et 30-dages prøve tid. Er dit site lille og enkelt, så kig på GWO, men er du ikke til kode, så ville jeg kigge på Optimizely.

I VWO har jeg haft en del problemer med at tracke javascript baserede handlinger, fx en formular som blev aktivere af javascript. I Optimizely var det piece of cake. Det er meget sigende. Jeg kørte også en "benchmark" i VWO, hvor jeg testede tre identiske versioner og jeg fik nogle bekymrende store udsving på op til 10%, selvom jeg havde statistisk signifikans på 94% og havde flere hundrede konverteringer. VWO support siger at jeg skal vente på 99% sikkerhed, men jeg synes ikke helt det er det samme de kommunikerer i deres materiale. Så pointen lige her er: Hvis du skal stole på dine data, så skal du vente på et at er statistisk signifikante og er de ændringer små, så tager det lang tid før de viser sig. Det giver sig selv, brugerne reagerer mindre forskellige på små ændringer.

Jo, så har Optimizely også en anden blæret feature: Man kan se sine resultater live. Har man et site med rimelig god traffik, så er det fedt at sidde og følge udviklingen. Lidt nørdet, men sådan er gamet jo i vores branche. Og så kan man sende andre sine testlinks, også en god feature. Det virker gennemtænk.

Det var lidt hurtige noter fra arbejdsbordet. Jeg vil meget gerne i dialog med andre der arbejder med de her ting på et professionelt niveau. Det er svært at finde sparring og erfaringsudveksling lige her (og indenfor event tracking i GA).

Herunder er et reklamebanner til Optimizely. Det giver mig lidt rabat, hvis du tilmelder dig via det link. Til gengæld er jeg så mere lydhør overfor at hjælpe dig. Deal? ;-)

Optimizely badge

Usability er forandring – Jeg er forandring!

onsdag, juni 16th, 2010

Forandring fryder! Det synes at være et velkendt mantra. Jeg hører ofte ledere der taler om at skabe forandring. Om at udvikle sig. Om modstand mod at udvikle sig, men også om nødvendigheden af det.

På mange måder er det fuldstændigt det samme indenfor usability. Jeg får lyst til at rejse mig blandt kollegaerne og sige højt "Jeg er forandring". Og det er ikke bare fordi jeg er der. Det er fordi forandringen er en forudsætning for at arbejde med usability. Fordi den viden usability skaber, kun er værdifuld hvis den efterfølges af (eller indeholder) forandring.

Eksempel: Jeg laver et test af et element på en hjemmeside. Det kunne passende være www.fdm-travel-dk, som jeg arbejder med nu. Når jeg tester, indsamler jeg en masse viden, om potentielle problemstillinger ved et konkret element. Den viden understøtter en række postulater jeg bruger til at facilitere en designproces, hvorved det testede element forbedres og dermed skaber mere af den værdi der nu engang eftersøges. Hos FDM travel er det konverteringen, at gøre den besøgende til køber af en rejse.

Hvis vi lige læser den proces baglæns, så opdager man at forandringen (her som en design-variant på elementet) bliver et delmål. Så langt så godt. Vi kan også forudsætte, at der står lighedstegn mellem delene: Test = Viden om problemer = Postulater = forslag til re-design = (bedre konvertering) = Værdi. Ok, det lidt forsimplet, men du forstår…

Denne sammenhæng kan man som princip (med sindsro) indtænke i alle usability-processer. Sammenhængen vil altid være den samme, delene vil være forskellige.

En anden interessant pointe er, at man i denne "ligning", forstår de enkelte deles formål, fordi man forstår hvad man skal bruge resultatet af delen til. Det er vigtigt. Det gør potentiel resultatet mere værdifuldt, men det stiller også krav til processen.

Var der ikke denne sammenhæng, kunne jeg ligeså godt droppe at lave testen i første omgang. Men det er netop det der alligevel er tilfældet i mange organisationer.  Der laves usability-arbejde, fx test eller identifikation af brug/brugere – men denne viden får ikke reel indflydelse. Resultatet får ikke den fortjente påvirkning af slutmålet – enten fordi slutmålet er utydeligt, eller fordi der ikke er plads til – forandringen.

Fordi at forandre er oftest også at lave om. Hvad-enten det er på processen eller på produktet. Lave om koster penge. Lave om betyder at ændre andres arbejde. For nogle betyder 'lave om', at rette – og rette betyder at tingene ikke var gode nok i første omgang og det har nogle mennesker (og organisationer og processer) det svært med.

Så derfor er jeg én stor forandring. Fordi det jeg laver, kun er noget jeg laver for at lave om. Forandringen er mit arbejdes berettigelse og derfor skal mine forandringer altid implementeres og bruges.

Derfor skal jeg (og du) altid sikre, at jeg har mandat til at følge forandringen til dørs. Men så skal jeg naturligvis også stå til ansvar for at grundlaget er solidt, validt, dokumenteret – ja, at det holder i retten.

Som allerede antydet gælder det ikke kun produkter – det gælder i særdeleshed også organisationen og processen. Det er derfor Paul Sherman taler om at UX kompetencer implicit er Change Agents (du må selv google det). Fordi at vi altid, når vi først kommer igang, helt typisk ønsker at skabe forandring, søger at udvikle tingene på nye måder (fx ved at arbejde brugercentreret, eller især at få andre til det – se det er forandring!).

Den næste t-shirt ligger klar: I Am Change

P.s. Forandring er et af de hippeste ord indenfor politik for tiden, så lad os hoppe med på vognen. Usability er forandring!