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.

Den gode Benjamin Gundgaard, der for tiden har fortjent 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 i FDM travel (der hvor jeg arbejder til dagligt). 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 FDM travel 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

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.

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).

Dengang skrev jeg:

"Hvordan nu det. Jo, jeg har en aftale med Post Danmark, online naturligvis, der som iTunes bare trækker beløbet på min konto. Til denne aftale hører en kode, som jeg tydeligt påfører bagsiden af mit brev: OG.L9-2720. Et Voila!

Og hvis jeg nu ikke gider have en konto hos post-konglomeratet, så kan jeg naturligvis lige hente koden via en SMS. Naturligvis. Men hvem gider SMS, der er så håbløst langsomt og tungt."

Men nu er det her, SMS frimærket. Jeg har prøvet det og det er lidt tungt og langsomt, men det virker. Jeg behøver aldrig mere gå i Føtex (eller på posthuset i helt gamle dage) og hente frimærket. Fremtiden længe leve…

Fordi du ikke kan bruge de tal til noget. De er totalt relative. Lad mig give et eksempel:

"Jeg har forøget konverteringsraten med 25%".

For det første ved vi ikke noget om, hvad de 25% dækker over. Hvis jeg havde 20 salg i går og 25 i dag, så er det forøget med 25%. Ikke nødvendigvis imponerende.
Og hvad er det der er forøget? Ofte tales der om konverteringer, men det behøver ikke være mersalg. Det kan også blot være mikro-konverteringer, som tilmeldinger til nyhedsbrev eller bare klik på en søgeknap.

Så forøgelsen i sig selv, om den er 10% eller 200% er ligegyldig. Og der er flere faktorer der spiller ind.

Du kan jo læse lidt på det her: Should I optimize for micro conversions?

Pointen, i denne artikel af Widerfunnel, er at du kan risikere at optimere "lokalt", men samtidigt skade dit salg eller anden makrokonvertering længere nede i salgstragten. Det er en rigtig bitch, fordi du (og jeg) typisk har langt færre konverteringer på makroniveau (altså fx salg) end på mikro (fx søgning på produkt). Nogle optimizere siger 100, andre 200 konverteringer, men er dine variationer i testen meget ensartede kan du risikere at skulle op på langt højere tal.

I eksemplet herunder (sammenklip fra Optimizely), kan du se at jeg har over 800 konverteringer på mig mål, men kun en statistisk sikkerhed på højest 87%. Optimizely selv arbejder som minimum med 95% sikkerhed, og det er jeg altså langt fra. For mange mindre websites er det at have 800 konverteringer rigtigt meget og tager lang tid at indhente. Men alligevel ser jeg ofte personer fra begejstret fortæller om deres forøgelse baseret på 50 konverteringer – det er altså ikke godt nok. Så tag ikke andres tal for gode varer. (Heller ikke mine ).

På samme måde kan man heller ikke sammenligne konverteringsrater i almindelighed. Morten Vadskær fortæller for eksempel altid om hans 9% på kondomaten (der er hak i pladen Morten), men hos mig i rejsebranchen er 9% en umulighed. Lå vi på 9% var vi stenrige. Så de 9% er ligegyldige og siger ikke noget om Morten succes eller dygtighed – i hvert fald ikke i forhold til dit website (med mindre du sælger kondomer). Nu er kunderne måske heller ikke så bange for at brænde fingrene på en pakke kondomer til 25,95, men de er lidt mere forsigtige når det er årets opsparing på turen til Thailand til 40.000. Konkurrence er vist også lidt hårdere i rejsebranchen.

Så skal du lytte til folk der vil fortælle om deres resultater, så spørg hellere til deres metodik, til hvilke erfaringer de kan give videre som er relevante for dit website. Du skal gøre dig dine egne erfaringer. Få fundet dig en optimizer du kan lide at arbejde med, øve dig på at opsætte mål, tjekke om du mener værktøjet er troværdigt: Du kan fx prøve at lave en test med de samme 5 variationer og se hvor længe der skal gå, før alle variationerne scorer lige højt.

Jeg har været igennem et par forskellige værktøjer nu og har fundet min favorit, men selvom jeg kører test med omkring 20.000 besøg om måneden, så føler jeg mig stadig ikke sikker på værktøjet. Stoler jeg ikke på værktøjet, så kan det hele være ligemeget.

Gør det selv

Ligesom med brugertest har jeg det sådan, at du faktisk kan (læs: bør) gøre hele arbejdet selv – ikke købe dig til det udefra. Det er ikke svært at lære og det bliver bedst hvis det er en rolig, langsigtet proces, der følges med de øvrige aktiviteter du har omkring markedsføring og optimering. Det er i hvert fald mit råd. Men modsat brugertest (som jeg fx også har skrevet en bog om og som også er rimeligt let at lære), så er det ikke så let af finde dansksproget, introducerende, hjælpsom tekst om emnet.

Derfor må vi gøre vores egne erfaringer, lære det selv, forstå vores egne tal, relatere dem til vores forretning. Men jeg vil i hvert fald meget gerne dele erfaringer – kender du et godt forum til det?

/Ole

Lad mig starte med hvad de selv skriver:

I denne test har jeg over tusinde der har klikket. Er min konvertering på blot 10%, så har jeg de 100 konverteringer i hus og så har opnået "statistical significance", som det er vist på billedet. Men er det godt nok. Nej, det tror jeg ikke. Det er ikke helt forkert når de fra VWO support sagde at man skal op på 99% i significance, før resultaterne er til at stole på. Men det er ikke problemfrit. Hvis de variationer man afprøver ligner hinanden meget – og det gør de tit når det er små forskelle man tester på (uanset om det er rigtigt eller forkert) – så kan det tage meget lang tid at nå op på de 99%.

Herover ses fx en variation, der har fået 326 konverteringer. Den statistiske signifikans ligger på 73,7%. Som Optimizely også viser visuelt, så er det ikke værd at sætte alle sine penge på. Det tal kan med andre ord vise sig at være meget usikkert og ændrer sig sikkert med tiden. Der skal altså mere tid til, flere konverteringer. Samme tendens ser jeg på projekter med 5.000 besøg. Altså masser af trafik, men stor usikkerhed.

Min erfaring er – fordi jeg ikke er så matematisk velfunderet – at jo mindre ændring, jo mindre forskel mellem variationerne og det originale design, desto længere tid tager det opnå den signifikans.

Samme usikkerhed underbygger at jeg efterhånden er meget tålmodig, når det kommer til at vente på denne signifikans. For jeg kan se hvor meget resultaterne ændrer sig over tid, fra de første tal kommer ind og til at testen ligesom har fundet sig lege. Det er netop det man kan fornemme ud af den grafiske visning på Optimizely:

Kurven flader ligesom ud og forholdet mellem de forskellige version konsolideres.

Men det er stof til eftertanke. Nu er jeg heldig at arbejde et sted hvor jeg kan lave test der får 5.000 besøg på 3 dage. Men havde jeg 10 pr. dag, så er det en lang proces.

Det betyder også at man altid skal være meget forsigtigt med at være for skråsikker med sine resultater. Ligesom at jeg er blevet meget varsom med at læse artikler der siger "Vi skiftede lige en knap og fik 30% flere slag". Som regel er det fordi der er blevet rettet på noget lort eller noget der i forvejen ikke var gennemtænkt. Jeg har meget svært ved at skabe en 30% forbedring på siger der allerede har 80% i engagement (altså 80% besøg resulterede i et klik på siden). Samtidigt så er en stigning fra 5 til 10 salg, jo en forbedring på 100%. Så det lyder hurtigt flot, men det er jo altså MEGET relativt.

Så du kan i nogle tilfælde kopiere hvad andre har gjort, men oftest ikke. Det kan være at din ændring giver positiv forbedring i sig selv, men at du samtidigt fjerner et element som desværre æder selvsamme forbedring.

Så at lave gode tests og få gode resultater – det er i mine øjne stadig en stor udfordring.

/Ole

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.

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?

Usability KPI i en kommune

En kommune i hovedstadsområdet ønsker helt overordnet at sætte sig en række mål for brugen af kommunens digitale services – alt fra antal henvendelser i borgerservice om barsel til antallet af downloads af bestemmelser omkring sygefraværsregler. Behovet udspringer primært fra tankegang (tror jeg) omkring at styre fremdrift igennem måling – altså en form for ledelsesstrategi. Det betyder at kommunens afdelinger skal definere en række KPI'er – målepunkter på deres ydelser – og på et mere systematisk niveau kunne afgøre om der sker fremdrift på baggrund af de aktiviteter og initiativer/projekter der sættes i søen. Det giver sikkert alt sammen udmærket mening.

Webafdelingen i pågældende kommune står nu overfor en udfordring, om ikke andet, så som kompetence på det digitale område og ansvarlig for at hjælpe resten af organisationen på vej: Hvilke målepunkter skal der opstilles (på vegne af hele kommunens online servicestruktur) og hvordan skal disse måles?

Jeg blev inviteret til at give lidt input, gennemgå et par måder at måle på usability og tage en diskussion med nogle af medarbejderne omkring hvordan de skulle bevæge sig fremad i den proces. Her er i korte træk hvad vi talte om:

Første trin er at beslutte hvad der skal måles på. De enkelte afdelinger har nogle svagt definerede ønsker og forskellige politiske prioriteter, men trænger til at kigge på to ting: Den ene er at få defineret hvad der skaber værdi for kommunen (eller afdelingerne) og den anden er at undersøge hvad der skaber værdi for brugerne. Værdi kan være at have færre borgere der ringer til kommunen og i stedet selvbetjener sig til svar/løsninger. For begge parter er dette en nemmere og hurtigere løsning = værdi. Målet er selvsagt at skabe mere af den værdi for kommunen, ved at forøge værdien for borgerne (det er jo en slags essens af det arbejde med usability).

Hvordan kan den værdi så måles? Det kan være gennem helt almindelig statistik, altså besøgstal eller lignende. Både på den online del, men også på presset på telefoner og email. Uanset hvordan vi skaber den viden, så vil den blive et udgangspunkt, det vi med fint kan kalde for et benchmark. Der vil også blive behov for nogle tilgange til at teste/måle, hvordan brugen udvikler sig, efterhånden som vi re-designer vores digitale services.

Fra den viden kan man også forsøge at skabe nogle usabilitymål. Et usabilitymål kan indeholde en beskrivelse af hvem der skal kunne hvad og i hvilken grad, samt naturligvis et niveau der skal opnås. Så kan kommunen fra test til test, vurdere om der er fremdrift.
En begrundelse for at tale om usabilitymål og for at se på andre tilgang en at kigge på brugs-relateret statistik, er at fx besøgstal og bouncerate%, ikke siger noget om hvor svært brugerne har ved fx at forstå regler eller love. Der skal andre metoder til.

Tre måder at måle på brugen

Den typiske tilgang er at lave brugertests. At stille repræsentative brugere repræsentative opgaver og tage bestik af hvordan det går. Det giver masser af input til at forbedre de digitale services, men der kan være en udfordring omkring at måle på disse tests. Uden måling kan vi ikke arbejde med målepunkter. Men til en start kan man sagtens få tal ud af brugertests, fx den procentvise gennemførelse af testopgaver, antal klik eller den tid det tager at løse opgaven (alt efter typen af test).

En anden tilgang kan være at gå mere digitalt til værks. Her kommer kommunen lidt til kort, fordi der ligger en række tekniske begrænsninger for hvilke værktøjer der må implementeres på kommunale hjemmesider (hvilket jeg personligt synes er bullocks). Men hvis vi lige ser bort fra det, så kunne en tilgang være hændelses-sporing.

I Google Analytics hedder det også Event Tracking. Det er et spændende og relativt nyt fænomen. Fordelen er at der kan opstilles hele specifikke handlinger online, som tælles og opsummeres i Googles Analytics interfacet. Det kan være klik på bestemte elementer, udfyldning af felter, downloads eller alt muligt andet. Det giver mulighed for at komme lidt mere i detaljen end blot sidevisninger og besøg. Det giver også mulighed for at måle på handlinger der foregår på den enkelte side eller opsamle sammensatte handlinger, som man fokuseret ønsker at tælle.

Denne metode giver ikke indblik i hvorfor brugerne handler som de gør, men prøver i stedet at fokusere på at tælle ønskede handlinger, som et symptom (eller målepunkt) på kvaliteten af brugen.

En tredie tilgang kan være at lave A/B eller multivariant test, hvor forskellige variationer af en hjemmeside, eller dens elementer testes live op mod hinanden. Det er også et område under stor udvikling, som har en vis iboende evidensbaseret styrke, fordi man direkte kan måle hvordan forskellige designs klarer sig.

Det kan gøre på mange måder, fra at teste en enkel sides evne til at skabe flere most-wanted-actions, til at vurdere om en hele sekvens af sider får flere brugere til at gennemføre et bestemt forløb. Om det bruges til e-handel eller til regler for sygedagpenge er som sådan underordnet.

Hvad skal vi måle på?

Så lang så godt. Tre forskellige tilgange som har hver deres styrker og svagheder, som til dels kan minimeres ved at afvikle dem sideløbende. Men også tre tilgange som alle har som forudsætning, at man ved hvad man vil måle på.

Så den største opgave, også for omtalte kommune, er at definere: Hvad vil vi måle på og hvilke mål skal vi sætte for brugen?

Kommunen valgte at starte med at indsamle viden. Lave brugertest og spørgeskemaer, for at få et indtryk af den nuværende brugs-situation(er).

Men kommunen er blot et eksempel. Samme behov opstår i denne tid naturligt i mange andre virksomheder, hvor ledelsen meget gerne vil have bedre styre på fremdrift og værdi af alle de digitale services. Men ikke bare værdi som besøgstal eller antal klik – også værdi som kvalitet i brugen – fordi den kvalitet i stigende grad er en afgørende faktor i virksomhedens strategi.

/Ole Gregersen

I går deltog jeg i UXbookclub i København, en lille klub jeg kun kan anbefale. Vi talte (efter at have talt om Donald Normans nyeste bog) om at sælge usability til de uindviede. Gammel diskussion, som blusede op i går, på baggrund af Normans gentagne henvisning til de klassiske problemstillinger, om ikke at inddrage brugere osv osv. Vi troede den var død, men den lever i bedste velgående – (ok, måske alligevel ikke den store overraskelse).

Jeg meldte lidt højrøstet ud at, man skal vende organisationer og virksomheder ryggen, som ikke prioriterer brugerorienterede designprocesser og usability, fordi det er en grotesk kamp op ad bakke – de skal have lov at sejle deres egen sø. Det er i høj grad min egen tilgang, efter at have arbejdet i sådan en virksomhed. Men jeg fik også lidt af en nåhr-ja-oplevelse, fordi det viste sig at andre deltagere i bogklubben, faktisk finder selvsamme udfordring interessant. Og det kan jeg sådan set godt forstå. Uden at jeg dog tror at det løser noget eller ændrer meget (men den tager vi en anden gang Ole – dit mavesure gamle fjols, sagde hunden).

Nå, men i den snak sagde en anden deltager: "Vi er grundlæggende brugernes advokat".

Det er et udsagn jeg i princippet er enig i og som jeg selv har brugt mange gange. Pågældende person vil med garanti kunne uddybe udtrykket – men hvis jeg ser på det isoleret, så må jeg indrømme at jeg egentligt synes det er misvisende og potentielt farligt at bruge det som udgangspunkt – eller som forklaringsmodel.

Lad mig prøve at begrunde det: Helt grundlæggende laver vi jo ikke brugervenlige hjemmesider og applikationer for brugernes skyld, vel?
Vi laver dem, som forretning, for vores egen skyld. Oftest for at tjene (eller spare) penge. Det er fordi vi tror på, at kvalitet i brugen giver øget værdi, så vi eftersøger den kvalitet. Derfor bør vi argumentere ud fra helt grundlæggende investeringsmæssige overvejelser omkring hvorfor vi synes at produktet skal være effektivt. Det er fordi at brugerne så kan løse flere opgaver, hvilket gør produktet mere værdifuldt, hvilket – osv, osv. – eller lignende sammenhæng.

Forskellen ligger altså i begrundelsen. Og det er sundt at vende den på hovedet, både for os usabilitykompetencer og for dem vi kommunikerer med.

For os selv ligger der et fokus som vi ofte glemmer, nemlig fokus på hvordan den værdi der "skabes i brugen" kan plansættes og målrettet kan måles og opnås. Jeg kommer desuden selv ofte til at springe usability-målene over, fordi det er lidt svært og tungt at opsætte og måle på deres gennemførsel. Det er i mange situationer en rigtig stor udfordring, men igen fordi hele tilgangen til IT-udvikling har et andet forståelses-fundament.

Skal jeg fortælle mine chefer om glæden ved usability, så lytter de til gengæld mere til mig, hvis jeg kan omsætte antal tilmeldte til nyhedsbrevet til værdi og arbejde struktureret på en fremgang – end hvis jeg taler om "brugervenlighed", "brugernes advokat", "de stakkels brugere", "de onde ingenører", "det skal være let at bruge", osv.

Begrundelsen i værdi, i kroner og ører, har direkte hul igennem hele vejen op og ned gennem forretningen. Samtidigt er det lidt en varm klud i hovedet på dem der ønsker at gøre usability til noget humanistisk, fodformet ammestue-arbejde, fordi argumentet om øget værdi (som oftest) er stenhårdt. Derudover tvinger det sig ind over alle andre opgaver i udviklingsprocessen og kan, hvis det bliver en drivende kraft/prioritet, pludseligt vende rollerne helt på hovedet.
Se det er der fandme noget ved kan jeg godt love dig! (ahem, got carried away, sorry).

Problemet er ofte at mange i organisationen ikke kan forholde sig til "brugernes advokat", på andet end et emotionelt, menneskeligt niveau – men det er bare ikke den verden de lever i, når der skal foretages hårde økonomiske prioriteringer – der hvor den godhjertede usability dør en brutal og på mange måder velbegrundet død, som en slap merudgift

Og lad mig slutte med at sige at det er skønt, at arbejde i et miljø hvor den grundlæggende forståelse af usability er indlejret i projektets grundpræmis. Nuvel, det er let at sige når jeg arbejder med e-handel. Der giver det lidt sig selv i en virksomhed som FDM travel.

Men jeg ville ikke tage fejl af at det faktisk lidt er en trends inden for web-usability, som med rette kunne sprede sig til andre dele af IT-verdenen. Jeg har allerede fået flere henvendelser fra organisationer, der gerne vil have møbleret lidt om på deres syn på udviklingsprocessen.

Denne gang har jeg en skarpladt skyder med i ærmet, hvor jeg før havde en sød bamse.

En konvertering (til den der ikke ved det) er når man forvandler en besøgende på sit website, til et salg (som oftest). 'Konverteringen' går som sådan på alle mulige handlinger man gerne vil have sine brugere til at udføre, men det er typisk noget der udløser en eller anden form for værdi.

Denne nye verden  – både ny for mig, men også lidt ny som felt – er interessant for mig, fordi jeg oplever dem som et møde mellem usability og markedsføring. De personligheder (kendisser) der findes indenfor usability, genfindes ikke direkte i CRO-verdenen og omvendt. Og slet ikke i Danmark.  

Derudover er der tydeligt også tale om to helt forskellige traditioner. Usability er efterhånden et modent felt der står på skuldrene af psykologien, HCI, interaktionsdesignet  – ja på hele den fantastiske udvikling vi har været igennem med computere i det hele taget.

Jeg er ikke så meget hjemme i fagligheden (hvis der er nogen) omkring CRO. Men det kommer tydeligt fra markedsføring, som undervejs er blevet til online markedsføring i venskabet med bl.a. søgemaskineoptimering (SEO).

Et godt bud på hvad der foregår indenfor CRO er Conversionconference.com, hvor jeg også selv deltager i år. I programmet vil man opdage, at der indgår psykologi, oplevelsesdesign, søgemaskineoptimering, markedsføring, design og usability.

I det danske CRO miljø er der meget støj i form af selvfed reklame for egne ydelser og ”linken-til-hinanden”. Når man lærer lidt om at placeringen på Google også handler om hvor mange der linker til ens egen side, så forstår man godt at CRO-folket bruger det meste af tiden på at linke rosende til hinanden SEO-optimerede tekster. Men stor faglig eller menneskelig dybde har det ikke altid

Det grænser til rygklapperi når fx SemAward.dk – hvori langt de fleste af de navne man møder, når man søger på emnet optræder – giver sig selv præmier for ”fantastiske artikler”. Prøv for sjov at holde øje med tweet-strømmen på den side. En uendelig række af henvisninger til ”de andre på holdet” uden nogen meningsbærende relevans for dig som bruger overhovedet.

Ligesom indenfor usability kan man (med rette) lade sig forblænde af andres fantastiske resultater og de mange nye spændende online værktøjer. Men ligesom indenfor usability, så er disse ting sekundære. Det er processen, tilgangen, vejen til målet, der er interessant.

Så jeg griber straks i egen barm og forsøger mig med en form for model over en proces jeg selv tror på.  Målet er konverterings-rate-optimering, men midlet er velkendt indenfor usability – ja eller måske rettere indenfor videnskabsteori i relation til den videnskabelige undersøgelse (her er jeg på dybt vand, men det var også kun en reference…).

I en cirkulær eller iterativ proces kan vi se følgende opgaver:

1)    Identificere problemstillinger
Oftest baseret på tal hentet fra fx Google Analytics eller andet analytisk værktøj, men det kunne også være fra en brugertest eller en ekspertvurdering – eller bare faldende salgstal.

2)    Opstille tese eller forklaringsmodel
Hvorfor tror vi at denne handlen fra brugerne foregår. Her gætter vi, for vi ved det selvsagt ikke. Det kan være vi gætter på noget i designet, noget i websitets struktur, noget i performance, whatever.

3)    Kvalificere tese
Fordi vi ikke ved hvilken tese der holder vand, efterprøver vi dem. Det kan være ved at indsætte nye målepunkter eller lave nye tests der stiller skarp på problemet i sammenhæng med tesen.

4)    Opstille løsningsforslag
Nu er problemet identificeret, måske er vi endda modige nok til at sætte nogle (usability)mål som vi søger at opnå. Nu kan vi lave designforslag der søger at afhjælpe problemet eller til at øge konverteringen.

5)    Måle på løsningsforslag
Der kan være flere forskellige løsningsforslag og vi ved ikke hvad der fungerer bedst eller bare hvad er fungerer. Derfor må vi teste. Det kan være brugertest, men endnu bedre er de kvantitative og rimeligt empiriske optimeringstest (fx A/B test), hvor vi samtidigt kan sammenligne og måle på vores designforslag.

6)    Implementering
Vinderforslaget implementeres!

7)    Opfølgning
Løste vi problemet? Steg konverteringen og kan den stige mere?

8)    Forfra – vi er aldrig færdige…

Skal du ikke også lige have det på tryk:

Se i denne model kan man smide et eller flere trin ud (dog ikke valgfrit), så længe vi forstå at det har konsekvenser. Jo mere vi har optimeret på vores hjemmeside, desto farligere bliver det at smide trin ud, fordi vi kommer ud på ukendt territorium (hvilket ligesom er modellens grundpræmis).

Du kan trække på din usability-kompetence på alle trin (juhuu!), ja jeg vil mene at du står langt bedre rustet end så mange andre. Du kan stille kvalificerede spørgsmål til brugen, til designet, til interaktionen, til målemetoder og til kvalitet i det hele taget. Men det er nok også fordi det modellen til forveksling ligner en iteration i en brugerdrevet designproces.

For den øvede usability-kompentence, er det nye at have en systematik omkring alle de empiriske målinger, de stærke online værktøjer – som fx Google Website Optimizer, Visual Website Optimizer og Optimizely.

En af de vigtige opgaver er, at være opmærksom p,å hvor meget der er at hente/tjene i relation til hvor meget tid/penge man bruger på det – lad os kalde det return on investment .
I trin 1 vil man naturligt vælge det oplever giver størst tab/størst gevinst. Det vil man sende videre ind modellens cyklus. Men det er ikke altid nemt at svare på hvilke ændringer der vil give størst effekt. Det kan man ikke vide på forhånd, men jeg tror på at man kan opøve en fornemmelse – hvis ikke, så fanger metoden det og man må starte forfra i sin cyklus

Lad os prøve det og se hvad der sker.  Desværre synes jeg MEGET der mangler et godt sted at diskutere de her ting, på dansk. Hvis du kender et godt sted, eller gerne vil være med til at starte et. Så kontakt mig.

/Ole