Archive for the ‘Usability’ Category

Split-test og jQuery

fredag, januar 27th, 2012

Splittest er det nye sort, det bliver et godt emne i 2012. Jeg kan allerede mærke det.

Hver gang jeg går til et foredrag om e-handel eller online forretningsoptimering, så bliver der snakket om splittest (eller A/B-test). Lige for tiden er der rigtigt mange der hører om splittest, men ikke helt hvad det er og slet ikke ved hvordan de skal komme i gang. Jeg har købt domænet splittester.dk, blandt andet for at komme det lidt i møde (også fordi der ikke sker noget brugbart på splittest.dk). Mere om det senere (købte det i går).

Men i dette indlæg vil jeg dele nogle andre erfaringer. I dag har jeg lukket 3 tests ned og startet 3 nye. Det foregår som altid i Optimizely. En af de ting jeg efterhånden har forstået er, at Optimizely og jQuery går hånd i hånd.

Nu ved jeg meget lidt om jQuery, så lidt, at det er nemmere hvis du selv googler det. Men det er et "programmeringssprog" der gør, at jeg tage elementer (eller kode) fra den side jeg laver test på og ændre på dem.

Det er faktisk det Optimizely normalt gør bag kulissen, men det bliver først rigtigt lækkert når man selv kan justere på den. Særlig med meget dynamiske sider er det fuldstændigt uundværligt.

Lad mig dog give nogle eksempler.

Benjamin Gundgaard, der for tiden får opmærksomhed med hans e-handelsbog, skriver at det er en god idé at tilføje en forklarende tekst efter "gå-videre"-knapperne i købsflowet i en e-shop. Sikkert nok. Men nu tager jeg jo ikke bare alt for gode vare, så derfor skal det testes. Til dagligt ser knappen således ud:

Jeg vil gerne tilføje en lille tekst efter knappen, så det ser således ud:

Det gør jeg ved at indsætte følgende kode i Optimizely:

$("div#proceedBtn").append('<br><br><span style="color: rgb(50, 50, 50); font-size: 11px; font-family: Verdana,Helvetica,sans-serif;">På næste side:&nbsp;Indtastning af kortoplysninger via sikker forbindelse.</span>');

Det er funktionen append() der er smart her. Med den kan jeg tilføje forskellige elementer til den eksisterende knap.

Vi er også igang med at teste om der er felter vi kan undvære i vores tjek-ud forløb, fx det ekstra telefonfelt. Igen kan jeg med jQuery let fjerne et felt og teste resultatet:

$("div.wtChckMg2 > div:eq(8)").css({"display":"none"});

Jeg kan også lave rimeligt avancerede ting, men der har jeg dog brug for lidt hjælp udefra – enten fra kodehoveder i firmaet eller fra Optimizely's super-supporter Ricky, som tager alle henvendelser helt alvorligt. Lad mig også her give et eksempel.

De sider vi i <et rejsebureau> har til at vise hvilke hoteller vi har, når du søger på en bestemt dato, et bestemt sted og med et bestemt antal rejsende – er meget dynamiske. Hele websiden "lever" i én session og har derfor ikke en fast URL. Jeg kan altså ikke fortælle Optimizely hvilken side den skal se på, for siden eksisterer kun i nuet (eller i den tid sessionen varer). Samtidigt er hele sidens indhold jo dynamisk fordi det er søgeresultater. Så jeg kan kun identificere elementer på siden via deres ID. Det kan være en DIV, det kan være en H1 eller det kan være en css klasse. Men her er jQuery superstærkt. Lad mig beskrive den løsning jeg har lavet med ord:

"Kære jQuery. Tag en overskrift på siden (der fx hedder 'London, Vælg overnatning og fly'). Tag teksten fra den overskrift og træk ", Vælg overnatning og fly" fra. Gem resten i en variabel. For hvert søgeresultat skal du gøre følgende. Tag hotellets navn og tilføj "Med fly til" og sæt derefter overskriften fra variablen og sæt for enden. Når du har gjort det, så sæt lige et link efter ordet fly, til det fly vi har fundet til pakkerejsen. – ps. du skal kun gøre dette på nogle helt bestemte sider".

Det er teksten markeret med rød ramme, der dynamisk tilpasses og indsættes på alle hotel-resultater (klik på billedet for at se det i fuld størrelse). Jeg måler på antallet af brugere der lægger i kurven og antallet der gennemfører købet.

Hvis man skulle forestille sig at lave en lignende ændring i fx Google Website Optimizer, så ville man være ude på dybt vand. Så selv til store dynamiske sites er Optimizely meget fleksibelt og ultra-stærkt (vi har millioner af unikke besøgende). Jeg synes i hvert fald det er blevet meget sjovere at teste, fordi jeg med jQuery har næsten ubegrænsede muligheder for at variere noget kode som jeg ellers til dagligt ikke har adgang til.

Jeg er med andre ord begyndt at programmere igen :-)

Håber det giver dig lidt indblik i split-testens muligheder. Det eneste der skal til er viljen til at teste, resten er dejligt nemt.

/Ole

Fra Google Anlytics til bedre usability?

mandag, oktober 10th, 2011

Den 4. oktober have jeg i SIGCHI.dk regi, arrangeret 3 oplæg under titlen "Fra Google Analytics til bedre usability". Steen Rasmussen fra IIH Nordic og Chrilles Wybrandt fra Misura.dk og jeg selv, talte om hvordan Google Analytics (GA) kan bruges til at skabe bedre websites. I dette indlæg vil jeg gentage mine egne vigtigste pointer, samt sætte lidt flere ord på.

Men først vil jeg sige, at selvom arrangementet rent praktisk var en succes og deltagelse god, så mener jeg ikke rigtigt vi fik svaret på spørgsmålet om, hvordan GA kan bruges til at skabe bedre usability.

Det er måske også grunden til, at jeg gerne vil uddybe her – ikke for nødvendigvis at give et konkret svar, men mere for at sige hvorfor jeg (der trods alt kalder sig usability specialist) synes det er svært – men også interessant – at stille et tilfredsstillende svar.

Hvis du har lyst, kan du se mit oplæg på youtube her:

Link til kommenterede powerpoint slides.

Her kort indlæggets hovedpointer:

Afdækkende/problemsøgende – bekræftende/kvalificerende
For mig er den primære brug af GA: Enten at afdække problemstillinger, altså at identificere steder hvor "det gør ondt" – eller at kvalificere ændringer, altså at se på udviklingen i data, for at vurdere om en designændring har givet den ønskede virkning. I de to dele ligger der ikke selve forbedringen og det er måske en af grundene til at det ikke er GA, men andre processer, der bruges til at skabe bedre usability.

Effekt, effektivitet, tilfredshed
Er jo de tre overordnede dimensioner af brug, som de er beskrevet i ISO-definitionen for usability (9241). Min pointe her er, at vi ikke kan bruge GA til at måle på tilfredsheden, ligesom at det sjældent virker frugtbart at se på de data, der kan bruges til at måle på effektiviteten, fx brugerens tidsforbrug, antallet af sider de kigger på eller antallet af klik. Tilbage bliver "effekt", der primært handler om hvorvidt brugeren kan gennemføre sin opgave. GA kan bruges til at vurdere, hvor langt brugeren kom på vej mod et givent mål, hvordan det end er defineret. Det helt typisk den type viden jeg selv henter fra GA.

Det store webanalyse spørgsmål: Hvad vil du gerne vide
Jeg opfordrer til at du slukker din computer og spørger dig selv: Hvad er det du gerne vil have svar på. Få det formuleret, inden du igen drukner dig selv i tal og grafer der fiser op og ned. Som i alle andre projekter, er det vigtigt at have de rigtige briller på inden du går i gang. Det gælder i særdeleshed også i GA. Formuler det som helt almindelige spørgsmål: "Hvor mange af de brugere der kommer til vores site via forsiden, klikker på billedet øverst på siden?".

De gode svar er relative = du skal bruge mål og konverteringsrater
Det har hjulpet mig at se helt afgrænset på forholdet mellem to elementer i GA. Fx mellem to sider (lad os sige forsiden til en underside) eller en side og et mål (som defineret i GA) eller en side og en hændelse (også kaldet event). Rigtigt mange spørgsmål går på hvordan en sådan konverteringsrate ser ud, forholdet mellem en indgang og et mål. I e-handel tales der meget om konverteringsrater og købstragt og lignende, der på en måde er en række sider/hændelser i rækkefølge, hvor man følger frafaldet undervejs mål et slutmål. I den slags arbejde er mål og proces ret tydeligt formuleret, men alle andre kan også få glæde af at formulere mål for deres site. Det kan være svært for fx websites der mest handler om information/kommunikation, men jeg mener nu alligevel det med fordel kan gøres. Kun derved kan man klarere få et sammenligneligt billede af hvordan bestemte dele af ens site "performer".

Dashboard og event tracking
Der er to steder i GA som jeg trækker frem her. Dashboarded, som man i den nye version af GA kan lave mange af, kan bruges til at: Kommunikere resultater og prioritere ting man vil holde øje med – de af dine kollegaer der ikke bruger GA så tit, kan med fordel gå ind der og se de tal de lige har brug for. Du kan selv bruge det til at holde fokus på de ting der er vigtige for din rolle. Det er let at lave rapporter og præsentere dem på dashboarded. Et glimrende værktøj.

Event tracking har jeg skrevet om tidligere. Det korte budskab her er, at det giver mulighed for at opsætte og styre nogle forsøg, hvor du kan måle på udvalgte elementer på dit website (også ting som ikke er sidevisninger) og bruge disse tal i sammenhæng med alle de andre dejlige tal i GA. I min præsentation taler jeg om tracking af video og hvordan jeg kan give min kollega nogle enkle bud på hvordan hans video-elementer klarer sig (ikke at det direkte er usability, men eksemplet viser hvordan GA kan bruges til at mål på brugen af bestemte dele af sitet).

På det sidste slide  (i videoen altså) opsummerer jeg bare nogle pointer fra ovenstående.

Fra GA til bedre usability?
Her til sidst vil jeg blot tilføje, at jeg tror min vigtigste pointe er at GA er et værktøj der indgår i den cyklus der altid opstår omkring usability: Der afdækkes nogle problemer, der opstilles designforslag, der måles på de designs, der implementeres og måles måske igen for at overveje en ny iteration. Som jeg startede med at sige, så indgår GA for mig i at afdække og kvalificere.

Dog kan man blive meget god til at identificere problemstillinger, hvilket jo næsten er det samme som at identificere problemer i en brugertest. Hvis vi med større sikkerhed kan sige hvor problemet er, så kan vi tage den viden med når vi skal undersøge hvorfor.

Er det så det samme som at gå fra GA til at vide hvad man skal ændre på sitet? Nej, det er det ikke. Dertil skal heldigvis stadig bruges en menneskelig kompetence, sammen med andre værktøjer, både online og offline. Men GA er stadig et godt værktøj i den proces og det giver mening at undersøge og øve sig I at udvide den del af værktøjskassen.

Jeg arbejder dagligt på at blive bedre til at bruge GA til den opgave og jeg kommer til at lave flere SIGCHI arrangementer om emnet. Håber du vil være med. Husk at SIGCHI er på både facebook og Linkedin og at vi meget gerne hører fra dig med ønsker og erfaringer.

Konverteringer nede i tragten: Det klistrer til brugeren?

mandag, september 26th, 2011

En af de ting der er lidt tricky ved hele optimerings-ræset er at konverteringer på den side du tester, kan have betydning for brugernes handlen på andre sider. Helt typisk kan en optimering et sted i "købs-tragten" have betydning hele vejen ned gennem tragten. Eller med andre ord: Optimering er ikke kun lokalt – fra en side til en anden – men er med til at sætte en stemning, give begreber, antyde, skabe forventning eller hvad man nu vil kalde det.

De seje konverteringsdrenge, det kunne fx være Craig Sullivan, har styr på (eller foregiver at have styr på) hvordan optimeringer på fx en landing-page, giver de bedst mulige konverteringer hele vejen fra de forskellige version af design brugeren ser, til brugeren foretager makro-konverteringer, altså den afsluttende endegyldige konvertering (som jo typisk er salget).

Han viser det således:

Læs punkterne under billedet, så forstår du hvad han prøver at beskrive (vær opmærksom på at han var "vendt" tallene og taler om damage assessment).
Ok, ingen tvivl om at det er virksomheder med en høj "konverterings-optimerings-modenhed" der kan præstere den slags. Men jeg vil gerne prøve at vise hvordan noget lignende opstår i de test jeg selv laver.

Her har jeg prøvet at indsætte nogle elementer der har givet forbedret konvertering på 4% på en anden siden (husk lige at læse min svada om at disse tal er relative og at du derfor ikke kan bruge dem til at sammenligne med dit eget projekt). Helt naturligt tænker jeg at disse med fordel kan indsættes flere steder og trække de samme forbedrede konverteringer.

Efter en kort periode kan jeg aflæse disse tal i Optimizely:

Øverste graf er et udtryk for hvor mange konverterer på den side jeg tester, altså mikrokonverteringen. Trenden ser indtil videre god ud, selvom den statistiske usikkerhed er for lav. Hvad er endnu mere interessant er grafen derunder. Den viser hvor mange der har lagt et produkt i kurven, altså det trin der kommer efter. Her slår ændringen også igennem, selvom der ikke er nogle ændringer på den side. Den hurtige konklusion er at ændringen på 1. niveau hænger ved hos brugeren. Ja, hvis jeg troede på tallene, så ser det ud til at det giver endnu højere konvertering.

Jeg har altså et værktøj som kan give mig overblik ned gennem vores købstragt, selvom det naturligt tager meget længere tid at få troværdige resultater, jo længere ned i købstragten brugeren kommer (ja, brugerne falder desværre fra…).

Nu er der så gået et par dage og jeg kigger på resultaterne igen:

Øv, nu ser billedet anderledes ud. Jeg er i minus! Og den statistiske usikkerhed er faldet til under 10% – der er altså lang vej igen. Linjerne i den nederste krydser endda hinanden, så resultatet er ikke ligefrem entydigt.

Hvad lærer jeg så af det:

  1. Ændringer i design har indflydelse længere end blot på den side hvor testen gennemføres.
  2. Man skal tage mål for statistisk usikkerhed alvorligt, data ændrer sig undervejs.
  3. 200 konverteringer (eller lignende tal) behøver slet ikke være nok, der er andre faktorer i spil.
  4. Meget trafik er ikke i sig selv garant for entydige resultater – jeg har 7.000 pageviews på min testside om dagen, men det tager mig alligevel uger at få et statistik troværdigt resultat.
  5. Er det her jeg skal blære mig med at den her side har en engagement% (altså brugere der klikker på noget, modsat bounce rate) på 90%.

Nå ja, den her artikel siger at man slet ikke skal optimere for mikro-konverteringer.

Nu lader jeg denne test køre en tid mere, så kan jeg fortæller hvordan det så går (fortsættelse følger).