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.

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
 

Hvem – er brugeren?

Hvad – er det brugeren gerne vil opnå?

Hvor – er brugeren?

Der er en masse underspørgsmål, bevares, men det er overordnet det vi skal vide for at forstå grundlaget for den interaktion der tager sted.

Nå, jeg må hellere se at komme til fadet. Jeg valgte forleden at tage toget på arbejde og i den forbindelse, opstod et behov for at kende til nogle togtider. Kort fortalt, så bor jeg i Vanløse og kan vælge at tage til Lyngby via Nørreport eller via Flintholm/Hellerup. Men rejsens længde varierer alt efter hvordan togene passer sammen. Enter the Rejseplanens iPhone App.

Så nu har vi et produkt på den ene side og min brugssituation på den anden – vi er klar til at vurdere om produktet er brugbart for mig – yeah!

Jeg ridser lidt op:

Hvem – Mand, 38 år, ret IT-kyndig, stor erfaring med apps, glad for mad, funk og sin kvinde (ja, hvad skal jeg skrive…?)

Hvad – Vil gerne vide om forbindelse er bedst via Flintholm eller Nørreport, vil mere konkret gerne kende togtider på linje E fra Nørreport og linje F fra Flintholm – skiftevis og hele tiden.

Hvor – På farten, sidder i metro over 3G netværk, skal tage beslutningen indenfor 1-2 minutter, samtidigt med togrejse.

Vi kan også se lidt mere på hvordan produktet understøtter denne brugssituation. Rejseplanens app kan finde infotavler, fx med udgangspunkt i Flintholm st.  og de forskellige typer af transport (tog, metro, bus, osv).

Dertil kan app'en gemme favoritter. Begge funktioner indgår i brugs-scenariet, som går som følger:

1) Jeg åbner app'en, vælger "infotavler", indtaster Flintholm st. (der er auto-complete) og siger jeg vil se mulighederne for tidspunktet "nu":

2) Der er rigtigt mange forbindelser på Flintholm st. og da jeg har travlt, kan jeg ikke overskue dem. Der er alle mulige og umulige busser og typer af tog, jeg ikke skal bruge. Jeg skal bare bruge S-togs-forbindelser.

3) Jeg opdager noget der ligner en tragt i brugergrænsefladen og forventer korrekt at det er en mulighed for at filtrere:

4) Skønt! Jeg sorterer og får vist det jeg skal bruge. Nu skal jeg så videre til informationerne fra Nørreport, så jeg kan sammenligne de to muligheder jeg har for min rejse:

5) Jeg går tilbage til søgning og gentager. Igen skal jeg filtrere, hvilket jeg kan acceptere, da mine forbindelser jo kunne være via andre transportformer.

6) I mellemtiden er jeg steget på metroen og er på vej til Flintholm. Nu skal det gå stærkt, jeg skal tage en beslutning. Tilbage og kigge på Flintholm.

7) Efter at have gjort det et par gange, opdager jeg at der er noget der hedder favoritter. Yes! En mulighed for let at skifte mellem mine to muligheder.

Nu leder jeg efter en måde at gøre mine to søgninger til favoritter, men det kan jeg ikke. Nå, jeg dropper det. Tid er penge. Efter lidt tids roden, opdager jeg at favoritter giver adgang til tidligere søgninger. Nu kan jeg finde både Flintholm og Nørreport og sætte søgninger lidt hurtigere igang.

MEN: Eftersom disse placeringer jo ikke er gemt, men snarere "husket", så er mine filtreringer ikke med. Og da der er mange filtre, så tager det ret lang tid, i det rumlende tog, at indstille igen – noget jeg hurtigt bliver mega-træt af.

So there you have it!

Gratis brugertest af rejseplanens app. By real users in real use!

Min pointe her er  – ud over at vise hvordan man kan gå til opgaven og hvordan man kan lære noget af den – at mit brugsscenarie tydeligvis ikke er fuldt understøttet i denne app. Det kunne det være, hvis Rejseplanen havde afprøvet brugssituationen eller analyseret den bedre. Det kan være en prioritering: At den type brug ikke er typisk. Men jeg vil påstå at den mentale model omkring en "favorit", som man kan vende tilbage til, ikke er ordentligt understøttet.

Det har jeg så gjort Rejseplanen opmærksom på. Så ser vi hvad der sker.

I mellemtiden må jeg så igennem alle disse unødige trin, med mindre det med vanen viser sig at være hurtigere blot at starte søgningen forfra hver gang.

/Rejsende OnkleOle

Velkommen til brugertest.nu
 - der tilbyder at man kan stille testopgaver, som så formidles til "brugere", der løser de testopgaverne og kvitterer med en video med testerens stemme og optagelse af hvad der foregik på dennes skærm. I realiteten samme data som man ville få hvis man selv lavede en brugertest. Det primære i produktet er, at brugertest.nu formidler opgaverne og har fast tilknyttede testere de kan trække på.

Det gøres efter eget udsagn både billigere og nemmere end hvis man selv gøre det.

Brugertest.nu tilbyder også at gøre mere af det beskidte arbejde med at lave testopgaver og fortolke på resultaterne – hvilket er nok så interessant.

Prisen er fornuftig, man kan godt gøre det billigere selv, men skal de jo også betale husleje, udstyr og lave lidt profit, så passer det nok meget godt.

Det umiddelbare indtryk
Jeg synes afgjort det har sin berettigelse, hvis man er opmærksom på hvad man får og hvad man ikke får. Jeg synes det placerer sig et godt sted mellem den professionelle kommercielle brugertest (hvad enten den er intern eller pr- konsulent) og så den helt hjemmegjorte test, som fx Steve Krug eller jeg selv agiterer for i vores bøger. Til gengæld synes jeg ikke der er tale om et reelt alternativ til den brugertest, hvor en usabilitykompetence (fx mig selv), udfører en test in-house eller for andre. Det skal jeg prøve begrunde:

Lad os først kigge lidt på selve testen. Det er værd at huske på, at det afgjort største arbejde ved en brugertest er forarbejde og efterbehandling af testene. Selve testen, altså afviklingen, er den mindste del. Det kører som regel bare på skinner og kan gøres meget billigere (Jeg plejer at "betale" testere 400,- for 1.5 time, mens brugertest.nu skal have 500,- for 20 minutter).

Er det pengene værd?
Brugertest.nu tilbyder at lave for/efter-arbejde – uden at jeg ikke rigtigt kan gennemskue kvaliteten af denne og ikke har noget reelt at hænge den op på – for 10.000. Altså kan jeg få hele testen for 12.500. Det er da en fin pris. Men jeg har set nogle af de store kanoner, tilbyde noget lignende for 25.000. For den lille biks er de ekstra 12.500 sikkert mange penge, for større forretninger er det pebernødder, i relation til vigtigheden af at resultaterne – og særligt de re-designs de kan medføre – og for den betydning de kan have for omsætningen.

Med andre ord: Vil du føle dig mere sikker på at få en testleder med 200+ brugertests under huden til at fortælle dig hvor problemerne ligger end nogle relativt ubeskrevne blade der tester med nogle brugere du ikke rigtig kender?

Handling, ikke holdning
De test-eksempler brugertest.nu viser på deres hjemmeside emmer af  holdninger fra testerens side. Hvis man studerer lidt usability-teori, eller blot læser Jakob Nielsen, vil man se at holdning ikke har meget værdi. Det handler om handling. Hvis brugerne sidder og ævler om hvad de synes, så lærer du ikke noget. Tager du det for gode varer, så er du ikke blot inkompetent til at tolke resultaterne, men du skyder dig også i foden. Derudover har du ingen mulighed for at spørge ind til det der sker, hvormed du bliver mindre klog på det meget vigtige: Hvorfor?  – med mindre du er heldig at testpersonen selv begrunder.

Nuvel, man kan se at testeren rent faktisk er blevet bedt om at fortælle om sitet, men det tager lang tid og til 500,- pr. 20 minut, så er det nogle dyre minutter. Problemet er altså at de der laver opgaverne, skal vide hvad de gør: Der er stor fare for crap-in/crap/out.

Og hvad gør du hvis testeren ikke rigtigt får løst opgaven eller løser den på en måde du ikke kan bruge til noget. Betaler man så? Du kan ikke moderere undervejs, så du må bare håbe på det bedste.

Umodereret tænkt-højt
Så er det bare problemet omkring at tænke-højt i almindelighed. Forsøg viser tydeligt at brugerens opgaveløsning bliver mærkbart forandret af at der samtidigt skal tænkes højt. Det tager længere tid og testerne har en tendens til at rationalisere, altså logisk begrunde det de gør. Der er totalt say/do konflikt i spil. Netop derfor er fx eyetracking blevet populært, hvor testeren efterfølgende begrunder sine handlinger retrospektivt.

Som jeg kan se det, har vi som kunder ingen måde at vide hvem der tester vores website. Pudsigt nok lægger brugertest.nu op til at kunder efterfølgende graduerer (rater) testerne. Det er interessant nok. Hvad er en god tester? Den der fandt flest problemer? Den er kommer igennem flest ting? Den du bedst kan lide at høre på? Jeg har aldrig før hørt om at man på den måde eksplicit vurderede testernes kvalitet, men jeg lærer gerne hvorfor.

Konstruktivt kritisk
Heldigvis synes jeg (næsten) ikke de lover mere end de tilbyder. Vi ved alle at det er fornuftigt at teste, vi ved også at det kan være et stort arbejde at sætte op og vi ved hvad det er vi bliver tilbudt af denne service. Jeg har ikke rigtigt behovet selv, men som jeg sagde ovenfor, så har produktet som sådan sin berettigelse – jeg vil dog mene at man skal købe analysen med før at det giver mening.

Ps. skulle du i stedet være interesseret i at få en erfaren usability-specialist til at lave en times identifikation af dit websites problemer, med grundlag i rigtigt mange test og års erfaring som både underviser, tester, specialist og interaktionsdesigner, så skriver du bare en mail til mig

Disclaimer: Jeg er blevet gjort opmærksom på, at det ser lidt "underligt" ud at jeg kritiserer en service og så afslutter med reklamere for mig selv som produkt. Lad mig starte med at sige at det egentligt var ment som drillerier/provokation. Jeg er ikke en modydelse til brugertest.nu, jeg er ikke usabilitykonsulent, jeg lever ikke af at lave ekspertvurderinger og tage kunder fra brugertest.nu.

Jeg har nogle meninger om brugertest.nu som går meget på metoden, på hvad brugertest.nu "lover" sine kunder og på værdien af produktet. Hvad jeg selv går og roder med at projekter og hvad jeg ellers tjener penge på, er irrelevant i den sammenhæng og bør ikke (eller kan ikke med fordel) læses ind i den kontekst.

Jeg er også blevet beskyldt (indirekte) for at bruge grimme metoder, fordi jeg har kontaktet brugertest.nu's kunder og spurgt om jeg må se deres testvideoer. Det måtte jeg af ubegribelige årsager ikke. Det er så faldet brugertest.nu lidt for brystet. Jeg synes nu det er reelt nok, det er jo ikke statshemmeligheder, men blot almindelige brugere der fortæller om deres oplevelse på sitet – jeg kunne jo bare spørge min mor…

Kunderne sladrede så til brugertest.nu – og brugertest inviterede i stedet til at jeg prøvede produktet selv (sådan næsten gratis). Det vil jeg så blogge om i nærmeste fremtid. Men lad mig sige det således: Jeg blev ikke skuffet

/Ole

Til gengæld publiserede selvsamme Nielsen sit nyhedsbrev Alertbox samme uge og jeg synes faktisk at materialet var så godt, at det nu bliver en del af pensum. Nielsen siger ikke noget nyt, tværtimod, han siger det samme han har sagt i mange år, men han siger det bare godt og kort.

Så jeg vil gerne benytte chancen til at linke til hans indlæg om Interviews.

Jeg synes hans pointe omkring kravspecifikationer er uendelig god – også fordi jeg er tilhænger af argumentation der taler til  – hvad skal man kalde det – logikken, rationalet, den sunde fornuft…

Fordi mennesker ikke kan sige noget brugbart om hverken deres erfaringer med brug – eller omkring deres fremtidige brug, men kun om den brug der foregår i nuet, ja så giver det heller ikke mening at specificere brugen på forhånd. Fordi der deri ligger selvsamme modsætning, at sige noget om en brug der ikke foregår i nuet – og ikke er designet med forståelse af det.

Men snyd ikke dig selv, læs hans indlæg, Det er hurtigt gjort og du kan bruge argumentationen resten af dit liv, overfor andre og overfor din egen forståelse af hvorfor du arbejder med UX, HCI, usability eller lignende…

Så nu er det også pensum.

/Ole

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!