Innhold
Denne artikkelen dukket opprinnelig opp i nummer 216 av .net magazine - verdens mest solgte magasin for webdesignere og utviklere.
Da magasinet .net ble lansert på nytt, med et nytt design og mer regelmessig oppdatert innhold, var et krav at det nye nettstedet bedre skulle presentere artiklene for å oppmuntre til gjennomklikking. Men hvilket format ville være best?
En typisk tilnærming er bloggstilen, der du har en lineær liste over de nyeste artiklene. Det kan være et miniatyrbilde, en overskrift og en kort beskrivelse av artikkelen. Teamet var imidlertid interessert i å bruke et rutenettoppsett som var mindre teksttungt, og som potensielt ville være lettere å skanne over.
Det var der vi i Nomensa kom inn. Vi hadde allerede gjort noen brukervennlighetstester på tidlige trådrammer på hjemmesiden, og kunne være ganske sikre på at folk ville være fornøyd med rutenettet. Oppsettet skal oppmuntre til skanning og gjøre beslutninger enkle, resonnerte vi. Et rutenettoppsett tar mindre loddrett plass, og som alle vet, leser ikke folk på nettet uansett. Det grafisk rikere rutenettet burde være en slam dunk, ikke sant?
Det var en fittende følelse av at det kanskje ikke var det, så vi trengte å finne et svar. Å spørre folk skulle egentlig ikke hjelpe her; det er ikke et spørsmål om preferanse, det er et spørsmål om ytelse. Det er også et tilfelle der å be noen om å tenke på deres preferanser, kan endre det.
Vi trengte en kvantitativ metode som ville spore mange mennesker og vurdere deres beslutninger for to forskjellige versjoner. Så vi bestemte oss for å bruke A / B-testing av to forskjellige visninger, listen og rutenettet.
Det neste trinnet var å bruke Google Analytics til å se hvilken som helst forskjell mellom liste- og rutenettvisninger. Det er en spesiell funksjon i Analytics som gjør den til en utmerket følgesvenn for GWO: avanserte segmenter.
Å bruke et avansert segment er som å filtrere analysedataene på en bestemt variabel. Det er mange alternativer. Det kan for eksempel være lurt å se bare økter som kom fra Twitter, eller bare økter som varte i mer enn to minutter. Deretter kan du se avvisningsfrekvenser, tid på nettstedet, gjennomsnittlige sider og alle vanlige beregninger.
Sporing med Analytics
Segmentene vi ønsket å lage var basert på destinasjonssiden folk ville se, så vi kunne bruke de samme URL-ene som vi brukte for optimaliseringsoppsettet. Ett segment ble opprettet for standardvisningen, der nettadressen til destinasjonssiden bare var en skråstrek. Det andre segmentet var for den alternative visningen, som ligger hjemme / hjemme / liste.
Etter en dag hadde vi mer enn 600 personer i hver tilstand, og for hvert numeriske mål i Google Analytics var det ingen signifikant forskjell. Etter alt dette oppsettet, så det ut (ved første øyekast) at det ikke var noen forskjell. Så så vi på de viktigste navigasjonsstiene fra destinasjonssiden. Når du ser på rutenettet, ble de mest populære neste sidene delt jevnt mellom hovednavigasjonen og lesing av en artikkel. For listevisningen vil flere velge en artikkel enn å se på navigasjonen.
Det var ingen stor forskjell, men det var 15 prosent større sjanse for at folk ville velge en artikkel fra listevisningen. Til sammenligning mottok alle standardvisningen på den populære opplæringssiden, og effekten var borte.
Spennende, men det er vanskelig å vite hvor mulig det er å generalisere den effekten. Det ville hjelpe å vite hvorfor listevisningen oppmuntret til artikkelvisninger, så vi vendte oss til en mer kvalitativ metode.
Øyesporing
Eye tracking er populært i brukerundersøkelser, og gir direkte innsikt i hvor folk leter. Det har vært noen kontroverser i UX-samfunnet om nytten av øyesporing, spesielt når den brukes som standard. I mange tilfeller vil en standard brukervennlighet gi det samme svaret som et oppsett med øyesporing, så det er vanskelig å rettferdiggjøre de ekstra utstyrskostnadene.
For .net-nettstedet prøvde vi å forstå hvordan folk skannet designet, slik at øyesporing kunne gi noen viktige ledetråder.
Testoppsettet var kort og søtt. Hver deltaker ble bedt om å se på den nye .net-magasinets hjemmeside og velge en artikkel de vil lese. Halvparten av deltakerne ble først vist listevisningen, før de gjorde den samme oppgaven på rutenettet. Det andre settet med deltakere ble først vist rutenettet.
Øyesporingsbildet viste rutenettet på hjemmesiden, og i utgangspunktet ga dette ikke mye veiledning. Vi kunne fortelle at teksttitlene fikk de aller fleste blikk, men dette var det samme for både rutenett- og listeversjoner.
Forskjellen var tydelig bare når du så blikkløypene bygge seg opp. Med flere deltakere ble det tydelig at skanning av listen var mer forutsigbar, vanligvis en om gangen.
Når folk skannet rutenettversjonen av hjemmesiden, var ikke bestillingen det velkjente 'F' mønsteret. Du kan forvente at folk skanner rutenettet fra venstre til høyre, rad for rad. Det faktiske mønsteret var mye mer spredt, noen ganger gikk det ned i midten og forgrenet seg til begge sider.
Det er flere mulige forklaringer på dette mindre forutsigbare blikkmønsteret. Det kan være at:
- Folk er rett og slett mer vant til den lineære versjonen, derfor er de mer vant til å skanne presentasjonen
- Den lineære karakteren til listeversjonen er betydelig lettere å skanne
Spiller det noen rolle at folk tar en tilfeldig tilnærming til å skanne nettversjonen? Kanskje ikke
for alle nettsteder, men artiklene er nøkkelen til at folk besøker .net magazine. Hvis det er større sannsynlighet for at folk kommer til en artikkel når listevisningen er tilgjengelig, er det en viktig faktor for hjemmesiden og seksjonssidene.
Med flere deltakere kan det hende at innholdet styrer folks blikk. For eksempel kan bestemte søkeord eller bilder trekke flere oppmerksomhet. En annen mulighet er at det er områder med lite trafikk fra et skanningssynspunkt. Den fjerde og sjette artikkelen (andre rad til venstre og høyre) ble ikke sett på så mye som den femte artikkelen.
Svaret
For å gjøre en generell påstand om nytten av rutenettoppsett, må vi kjøre denne testen med mange flere deltakere og bruke en randomisert innholdsbestilling. For formålet med nettstedet .net magazine kan vi imidlertid være ganske trygge på å si at å bytte til en listevisning vil øke antallet mennesker som går direkte til en artikkel.
Det er imidlertid en advarsel. Når et nettsted er live og brukes regelmessig, bygger folk opp vaner i
hvordan de bruker det. Facebook er trolig det mest kjente eksemplet, der endringer i grensesnittet fikk brukerne til å klage og til og med sette opp online-kampanjer om endringen. .Net-nettstedet har vært live siden mars, så det kan være at folk har blitt vant til gjeldende visning.
Noen av tilbakemeldingene fra brukervennlighetstestingen antydet at folk vil velge layoutstil, så det nye .net-nettstedet har alltid gitt valget om å bytte layoutstil med ett klikk.
Jeg er ikke bekymret for et tilbakeslag, men det vil være interessant å se hvor mange som lager en
bevisst valg om det.
A / B-testing med Website Optimizer
Googles Nettstedoptimerer (GWO) lar deg sette opp enkle A / B-tester, eller mer komplekse multivariate tester. Det er tider når det er behov for multivariat testing, for eksempel å utarbeide den mest effektive bestillingen for tre eller flere elementer på en side. For å sammenligne en listevisning med en rutenettvisning er A / B-eksperimentstilen imidlertid perfekt.
For å sette opp A / B-testing med GWO trenger du tre ting:
- En startside, vanligvis den nåværende eller standardsiden du har nå.
- En alternativ side, som varierer på en måte som du tror vil påvirke brukerne.
- En sluttside, som GWO vil bruke til å beregne konvertering.
Når du har konfigurert eller identifisert disse sidene, kan du legge dem inn i GWO, og det vil gi deg tre blokker av JavaScript å inkludere på hver side.
Det er viktig at du kan legge til JavaScript øverst i kildekoden til hver side, fordi det er mekanismen for å tilordne folk til de forskjellige forholdene.
Når en bruker treffer startsiden, tilordner JavaScript dem tilfeldig til en av vilkårene, A eller B. Hvis brukeren er tilordnet B, blir de videresendt umiddelbart til
alternativ side.
NB: Hvis en bruker ikke har JavaScript aktivert eller blir fjernet underveis, teller de ikke med i resultatene eller statistikken. Deretter starter du eksperimentet, og folk begynner å bli tildelt hver versjon av siden. Det du forventes å gjøre er å vente på tilstrekkelige konverteringer til at den blir statistisk gyldig. I dette tilfellet har vi imidlertid ikke en sluttside for konvertering fordi det er et artikkelside i stedet for en bestemt reise - hvilken som helst artikkel er bra! Vi måtte legge inn en sluttside i GWO, men vi trenger ikke bruke konverteringsberegningen.
