Kategori: Usability

Weboptimerings-cyklus

Weboptimering bør være en systematisk og iterativ proces, der altid søger at bekræfte ændringer igennem indsamle data der kvalificerer designhypoteser, forbedringspotentialer og de implementerede designændringer. En måde at etablere og fastholde den systematik er at tage udgangspunkt i en weboptimeringscyklus.

(Modellen er blevet præsenteret på UXcampCPH.org og slides kan findes på slideshare)

I den tid jeg har arbejdet med weboptimering, har jeg hele tiden ledt efter beskrivelser af metode, af proces, af kompetenceudvikling. Jeg vil gerne have svar på spørgsmål som "Hvordan etablerer jeg en systematik omkring weboptimering" eller "Hvilke af mine kompetencer skal jeg arbejde på at udvikle, for at blive bedre til weboptimering". Der er ikke meget af den slags derude. Der findes et par bøger om webanalyse, om landings-side-optimering og om at splitteste. Men som titlerne også anviser, så handler de mest om en specifik tilgang til bestemte dele af den samlede opgave.

Men som faglig "felt" er weboptimering (eller konverteringsoptimering eller CRO eller…) også relativt nyt. Der har fx kun været afholdt to Conversion Conferences og som jobsøgende kan jeg afsløre at det ikke (endnu) vrimler med opslag på den profil.

Nå, op på hesten igen, så laver jeg bare mit eget. Eller, det er ikke helt sandt. Det jeg gør er snarere at udbygge en eksisterende tilgang og strø lidt weboptimering ud over. For det viser sig jo at der er masser af mennesker der har arbejdet med optimering (ja eller af optimering i det hele taget) af websites i mange år. De taler måske om en "UX proces" eller om "forretningsorienterede forbedringspotentialer", men overordnet vil de det samme.

Jo, der er andre der har lavet noget lignende før, fx WiderFunnel, men de fortæller bare så lidt om det, at det kan være ligemeget for os andre. Men senest har jeg noteret mig at der indenfor business management strategien Six Sigma, er en metode der hedder DMIAC, som på mange måder (opdager jeg nu) indeholder de samme trin. Læs fx om det i relation til Web Analytics Maturity Model (WAMM) (hvilket jeg vender tilbage til en anden gang).

Så inden jeg går igang med min variation af en model, så lad mig sige noget om weboptimering, som jeg forstår det. For mig er weboptimering:
 

  • En systematisk, iterativ proces, ikke et "gør som de andre" quick-fix.
  • Helst en in-house strategi, der forener online markedsføring, webdesign, web content og tilsvarende ansvarområder. (Men som også ser på arbejdsprocesser, ledelse, kompetencer, ressourcer, osv).
  • En datacentreret (webanalyse) tilgang, især fordi forholdet mellem besøgende på sitet og værdi af deres handlinger (fx salg) altid vil slulle måles igennem et kvantitativt værktøj (fx Google Analytics).

Der er sikkert flere ting (det er ikke målet her) men de tre områder er ret afgørende.

Jeg noterer mig at foromtalte WAMM, beskriver web analytics som: "The extensive use of quantitative and qualitative data (primarily, but not limited to online data), statistical analysis, explanatory (e.g. multivariate testing) and predictive models (e.g. behavioral targeting), business process analysis and fact-based management to drive a continuous improvement of online activities; resulting in higher ROI."

Indenfor UX eller usability, underviser jeg selv efter en grov opdeling der hedder analyse – design – evaluering. Det er tre overordnede "situationer" i en udviklingsproces. Og skal den proces, kva at vi gerne vil optimere, være iterativ, så er den en cyklus. Så derfor har jeg herunder beskrevet en weboptimerings-cyklus (skal vi kalde den version 1):

Grafik der viser weboptimeringscyklus
Se også de enkelte trin forklaret i min UXcampCPH præsentation på slideshare. Du kan frit bruge materialet hvis du husker at bruge mig som reference. Vil du have grafikken eller slides til dine egne præsentationer eller undervisning, så kontakt mig.

Weboptimeringscyklussen har 7 trin

1) Symptom – For at optimeringprocessen ikke skal være tilfældig, bedste mand bedste bud eller gætværk, så udspringer den af noget i vores forretning som angiver et optimeringspotentiale. Det kan være salgstal, det kan være en trend vi ser i Google Analytics, det kan være resultater fra en brugertest, det kan (og skal være) alt muligt. (Det skal siges at denne cyklus også kan startes af at, vi selv identificerer områder vi tror på kan optimeres).

Symptomet er en reaktion på et noget der kan optimeres.

2) Næste skridt er at opstille teser for hvad symptomet er et udtryk for. Vi kan kalde det vores forklaringsmodel. Det er i modellen angivet med italic hvor der skal en menneskelig kompetence til at løse den opgave. Det er ikke noget vi kan måle eller teste, der skal vi simpelthen tænke os om. Teser kan anvise om det er teknologi eller design der driller. Der kan være mange forskellige grunde til dårlig performance, ligesom at det kan være en kombination. Forklaringsmodellen indeholder bud på hvad problemet kunne være, for det er sjældent givet på forhånd.

3) Tredje skridt er at kvalificere teserne, få svaret på om der er noget at komme efter. Her er igen flere muligheder for indsigt. Vi kan grave i vores webanalyse-data, vi kan lave rocker-test af ting, vi kan kigge på online værktøjer eller på anden måde komme lidt ned i problemstillingen på det konkrete sted på sitet.

4) Så er tiden moden til at stille løsningsforslag. Det vil typisk sige re-design. I weboptimerings-ånden, giver det ikke mening blot at implementere et design og så tro på at det løser problemet. Vi kender ikke nødvendigvise svaret på problemet, så vi opstiller derfor i stedet et par kvalificerede bud.

5) I skridt 5 tester vi på de bud. Det foregår typisk i en splittest, direkte på websitet, med rigtige brugere der igennem deres handlinger, viser os hvilket design der bedst afhjælper det oprindelige symptom.

6) Går alt som det skal, så har vi derefter en "vinder". Et design der klarer sig bedst i splittesten. Det design implementerer vi naturligvis.

7) Og er vi rigtigt seje, så kan vi også måle på implementeringen, sådan at vi genbesøger kilden til det oprindelige symptom og sikrer os at vi faktisk fik den ønskede forbedring. Det sidste trin er svært at arbejde med og kan også være let at ignorere, men skal jeg være tro mod denne cycklus, så er et vigtigt aspekt at vi ikke forudsætter at vores design virker, men at vi altid måler på det.

Så er vi klar til at starte igen.

Der er mange forskelligartede kompetencer i denne cyklus og den kræver også organisatorisk ressourcer, fokus og samarbejde for at vedligeholde. Det er ikke let. Men på papiret synes jeg den giver god mening, primært fordi alt andet reelt set vil være ad-hoc eller bare lidt tilfældigt.

Fodnote:
"A model is a schematic and simplified  representation of a more complex reality.  What is included or abstracted stems from hypothesis about what’s essential or not. A model is a generalization of what we think we understand about a concept." Reference.

En organisatorisk udfordring i weboptimerings-processen

Model der viser udfordring ved eksisterende optimerings-paradigme

Der er en interessant udfordring indenfor weboptimering eller konverteringsoptimering, som jeg mener det er værdifuldt at undersøge lidt nærmere.

Lad mig tage udgangspunkt i min oplevelse af den typiske virksomhed der gør forretninger online. Det behøver ikke direkte være e-handel, men kan også være en af de mange andre virksomheder der sælger deres produkter online. Disse virksomheder har typisk en online marketing manager. Vedkommende har igennem en årrække arbejdet med at forstå, forbedre og pleje en række trafikkilder. Det er typisk Google Adwords, Affiliate marketing (kampagner og bannere), det er nyhedsbreve og det er til dels søgemaskineoptimering. Har manageren været god til sit arbejde, har disse trafikkilder givet en stadig stigende strøm af besøgende til websitet.

I lidt større virksomheder sidder der en specialist på hver af disse områder, og hvis ikke så kører manageren det selv eller får et bureau til det. Den gruppe medarbejdere fokuserer primært på at skabe trafik til websitet. Oftest ved de ikke så meget om at optimere på selve sitet, men som regel er det også et resultat af, at de har travlt med at optimere på deres trafikkilder. Et ugentligt nyhedbrev eller et trimmet Adwordskonto er fast arbejde. Det er den gruppe kompetencer der er tegnet øverst i modellen ovenfor.

Udover online marketing manageren har virksomheden også en eller flere medarbejdere der søger for indholdet på selve websitet. De hedder typisk webredaktør, content manager, web manager, online koordinator eller noget andet (i modellen kalder jeg det webdesign under en betegnelse). Denne gruppe tager sig af at opdatere websitet. Det er både af teknisk og indholdsmæssig karakter. Nogle gange er det en samlet gruppe der holder styr på websitet, andre gange er det en web-afdeling der varetager opgaven for en række interessenter i organisationen – og disse interessenter bidrager måske også selv med indhold.

Udfordringen er grundlæggende, at disse to grupper (online marketing og de der skaber indholdet) ikke har samme mål, ja de bliver oftest målt på noget forskelligt. De kommer gerne fra en forskelligartet baggrund eller kultur og de kender ikke hinandens mål og opgaver særligt godt.

Online manageren holder godt nok nogle møder med webredaktøren, for hun vil gerne have bedre sammenhæng mellem hendes Adwords kampagner og websitets landingssider. Men hvad brugeren gør derfra, det er hun ikke involveret i. Webredaktøren kender kun overfladisk Adwords kampagnerne og ved fx slet ikke hvad der foregår i affiliate netværket. På den anden side ved online manageren ikke specialt meget om brugerne, fordi de data hun kigger på er helt ryddet for indsigt i den faktiske brug af websitet.

Så langt så godt. Jeg kan påpege, at de to grupper med fordel kunne tale mere sammen og at konverteringsoptimering netop handler om at samle de besøgende op fra trafikken og få dem til at konvertere på sitet. Men udfordringen stikker dybere end det tror jeg.

Ovenstående tilgang er meget udbredt og har som sådan været succesfuld i en årrække. Men måske er det paradigme om man vil, under forandring. Det er fx efterhånden en udbredt forståelse, at mere og mere trafik ikke nødvendigvis giver flere og flere konverteringer. Måske har vi fået udenlandske konkurrenter, der tromler vores Adwords og SEO forspring. Nu skal der noget mere på bordet, for at kunderne konverterer hos os. Nu skal vi være endnu skarpere på at give brugerne en relevans og værdi – og den skal være unik hos os.
Skal den online virksomhed blomstre i de kommende år, vil der igen være behov for at modne organisationen.

Skal virksomheden udnytte det optimeringspotentiale der ubenyttet gemmer sig i, at brugerne trækkes ind i butikken på én måde og behandles på en anden når de handler, så skal de to grupper i højere grad arbejde sammen. Konverteringsoptimeringen bliver en overordnet tværgående proces. Og når virksomhederne typisk står et andet sted i dag, så bliver det også en modenhedsproces, hvor virksomheden på mange niveauer skal tænke anderledes.

Men her bliver det svært. Både fordi virksomhederne skal omdefinere en del af den online forretning. Der skal måske også nye kompetencer til. Der skal afsættes ressourcer til den tværgående proces og forståelse. Der skal laves best-practice og businesscases. Der skal i grad etableres en optimeringscyklus og en datacentreret tilgang (webanalyse) til denne, noget der i sig selv er en ret stor udfordring. Ja, måske skal vi have endda ny generation af ledere til i den digitale forretning?

Det vil vise sig.

/Ole Gregersen

Split-test og jQuery

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.

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