Tanker om usability

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

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.