Vi fremhevet Microsoft Clarity som et produkt bygget med praktiske brukseksempler fra den virkelige verden i tankene, av ekte produktfolk som forstår utfordringene selskaper som Switas står overfor. Funksjoner som «raseriøse klikk» og JavaScript-feilsporing viste seg å være uvurderlige for å identifisere brukerfrustrasjoner og tekniske problemer, noe som muliggjorde målrettede forbedringer som direkte påvirket brukeropplevelsen og konverteringsfrekvensen.
Hypotesedrevet testing
Hypotesedrevet testing er en strukturert tilnærming til eksperimentering der hver test begynner med en eksplisitt, falsifiserbar påstand som forutsier at en spesifikk endring vil gi en spesifikk, målbar effekt på brukeratferd, vanligvis innrammet i et format som: fordi vi observerte bevis X, tror vi at endring av Y vil resultere i utfall Z, målt med metrikk M innen en definert tidsperiode. Dette skiller seg kraftig fra ad hoc-testing, der variasjoner prøves basert på generell intuisjon eller lånt beste praksis i bransjen uten en klart artikulert grunn forankret i bevis spesifikt for det faktiske nettstedet eller produktet som testes på det tidspunktet. Noen team krever videre at hver hypotese navngir det spesifikke brukersegmentet den gjelder for, siden en endring som hjelper førstegangsbesøkende på mobil, kanskje ikke har noen effekt, eller til og med en negativ, på tilbakevendende desktopkunder som allerede vet nøyaktig hva de kom for å gjøre.
Denne disiplinen er viktig fordi den tvinger et team til å rettferdiggjøre en foreslått endring med eksisterende bevis før de bruker ingeniør- og designressurser på å bygge og kjøre en test, noe som forbedrer den totale seiersraten for et eksperimenteringsprogram betydelig over tid og gjør resonnementet bak både suksesser og fiaskoer gjenbrukbart for fremtidig arbeid andre steder i produktet. En test som bekrefter eller motbeviser en hypotese basert på tidligere data, for eksempel et varmekart som viser at brukere overser en viktig handlingsfremmende oppfordring fullstendig, produserer en læring som generaliserer til andre sider som viser lignende mønstre, mens en test basert utelukkende på en ubundet kreativ idé, selv når den tilfeldigvis vinner, ofte produserer et resultat som er genuint vanskelig å forklare eller anvende andre steder i produktet.
I praksis opprettholder hypotesedrevne testprogrammer vanligvis en løpende etterslep av hypoteser generert fra flere kilder samtidig, inkludert analysedata, varmekart og øktopptak, brukerintervjuer, kundesupporttemaer og konkurranseanalyse av lignende virksomheter i samme kategori. Denne etterslepet prioriteres ved hjelp av et poengrammeverk som ICE, som rangerer hver hypotese etter potensiell innvirkning, tillit til underliggende bevis og enkel implementering. Når hypotesen er prioritert, operasjonaliseres den til en A/B-test med en klart definert primær metrikk, en minimum detekterbar effekt og en nødvendig utvalgsstørrelse beregnet på forhånd, og testen kjøres deretter til den når statistisk signifikans, vanligvis et konfidensnivå på 95 prosent, i stedet for å bli stoppet tidlig basert på et tiltalende, men for tidlig mellomresultat.
En vanlig misforståelse er at en hypotese rett og slett er en beskrivelse av hvordan varianten vil se ut, for eksempel at vi vil gjøre knappen rød, snarere enn en begrunnet prediksjon som kobler eksisterende bevis til et forventet atferdsutfall. En riktig formulert hypotese angir alltid den underliggende oppfatningen om brukeratferd som designendringen spesifikt er ment å teste og validere. En annen betydelig fallgruve er å behandle en tapende test som en fiasko i den overordnede prosessen snarere enn som et gyldig og genuint verdifullt læringsutbytte i seg selv, siden en hypotese som motbevises av reelle brukerdata fortsatt eliminerer en feil antagelse og omdirigerer fremtidig innsats mer produktivt enn å aldri ha testet ideen i det hele tatt, et viktig kulturelt skille som erfarne CRO-utøvere jobber hardt med å integrere i klientorganisasjoner over tid.
Innenfor en CRO I konsulentbransjen er hypotesedrevet testing driftsmodellen som nesten alle klienteksperimentprogrammer er strukturert rundt, siden den gir et forsvarlig, reviderbart spor som forbinder et observert problem med en foreslått løsning på et målt resultat. Dette sporet er viktig både for å rettferdiggjøre den pågående investeringen i et kontinuerlig testprogram for skeptiske interessenter og for å bygge en institusjonell kunnskapsbase som øker betydelig i verdi etter hvert som flere hypoteser testes, forbedres og enten valideres eller definitivt avkreftes i løpet av påfølgende testrunder på tvers av produktet. Over tid blir denne akkumulerte oversikten over validerte og motbeviste hypoteser en av et konsulentfirmas mest verdifulle eiendeler, siden den lar nye eksperimenter utformes med fordelen av alt som allerede er lært, i stedet for å starte fra et blankt ark hver gang.
Switas sett på
