Undersøg frafald i checkout med opgaver, data og fejl
Et gennemarbejdet eksempel forbinder en mobil opgavetest, tragtdata og betalingshændelser, før en ændring i checkout planlægges.
En forskel mellem påbegyndte og afsluttede checkoutforløb viser, hvor en undersøgelse kan begynde. En konkret ændring kræver også det observerede forløb og relevante tekniske hændelser. Begynd med et lille spørgsmål: Hvor går en bestemt købsopgave i stå på en smartphone?
Fastlæg først, hvad der tælles
Definér periode, enhedstype og tragtens trin. Sammenlign sessioner, der tælles efter samme regler; ordrer og sessioner er forskellige enheder. Shopifys dokumentation skelner også mellem åbne og lukkede tragte. En sammenligning passer kun, når indgange og rækkefølgen af trin behandles ens. Ved skift af målesystem skal definitionerne også kontrolleres, før du antager ændret adfærd.
Et gennemarbejdet undersøgelseseksempel
En fiktiv webshop med tegnematerialer vil undersøge denne opgave: Vælg en tegnemappe, indtast leveringsadresse som gæst, vælg levering og fortsæt til betaling. Alle tal og observationer i tabellen er opdigtede; de viser, hvordan forskellige fund kan samles.
Kilde | Fiktivt fund | Fortolkningens grænse |
|---|---|---|
Lukket mobil tragt | 100 sessioner når checkout; 60 afslutter det i samme observationsperiode. | Forskellen er synlig, men årsagen er ukendt. |
Efter et ugyldigt postnummer står fejlteksten uden for det synlige skærmområde. | Det er en konkret hindring i dette forløb. | |
Betalingskontrol | Der er ingen tilknyttet betalingsanmodning for denne opgave. | Det dokumenterer ikke en afvisning fra banken. |
Kontrollér først, om betalingsregistreringerne dækker den undersøgte transaktion fuldt ud. Manglende poster kan også skyldes en ufuldstændig sammenkobling. Hvis det bliver klart, at formularen stopper, før en betalingsanmodning sendes, løser en ekstra betalingsmetode ikke dette formularproblem.
Se opgaven på den faktiske enhed
Lad opgaven blive udført i et egnet testmiljø. Notér enhed, browser, tastaturets tilstand og det sidste forståelige trin. Kan personen se, hvilket felt der er forkert? Bevares allerede indtastede oplysninger? Kan adressen rettes, og kan personen fortsætte med den valgte leveringsform?
Betalingskontrollen supplerer observationen. Shopify beskriver eksempelvis fejl fra bankbeslutninger, betalingstjenesten eller webshoppens opsætning. En generel besked på skærmen fortæller ikke, hvilket tilfælde der gælder. Knyt tilgængelige hændelser til den konkrete testtransaktion frem for at tælle alle uafsluttede køb som betalingsfejl.
Gør fundet til en ændring, der kan kontrolleres
For eksemplet er næste udkast: Det berørte adressefelt er tilgængeligt, fejlen beskrives dér i forståelig tekst, og de øvrige indtastninger bevares. W3C forklarer, at en automatisk opdaget indtastningsfejl skal identificeres og beskrives i tekst. Den foreslåede ændring er ikke en fuldstændig vurdering af tilgængelighed.
Gentag samme opgave efter gennemførelsen, og se derefter udviklingen i tragten med de samme definitioner. Dokumentér også andre ændringer, eksempelvis i tilbuddet eller trafikkilderne. En vellykket opgavetest viser brugbarheden af dette forløb; den dokumenterer ikke en generel effekt på omsætningen.
Kilder
Læs videre
Alle artikler
E-handel med ASES
Webshops, markedspladser og B2B-portaler