Undersøk frafall i kassen med oppgaver, data og feil
Et gjennomarbeidet eksempel kobler sammen en mobil oppgavetest, traktdata og betalingshendelser før en endring i kassen planlegges.
En forskjell mellom påbegynte og fullførte kjøp i kassen viser hvor en undersøkelse kan begynne. En konkret endring krever også det observerte forløpet og relevante tekniske hendelser. Begynn med et lite spørsmål: Hvor stopper en bestemt kjøpsoppgave opp på en smarttelefon?
Fastsett først hva som telles
Definer periode, enhetstype og trinnene i trakten. Sammenlign økter som telles etter samme regler; bestillinger og økter er ulike enheter. Shopifys dokumentasjon skiller også mellom åpne og lukkede trakter. En sammenligning passer bare når innganger og rekkefølgen av trinn behandles likt. Ved bytte av målesystem må du også kontrollere definisjonene før du antar endret atferd.
Et gjennomarbeidet undersøkelseseksempel
En fiktiv nettbutikk for tegnemateriell vil undersøke denne oppgaven: Velg en tegnemappe, oppgi leveringsadresse som gjest, velg fraktmåte og fortsett til betaling. Alle tall og observasjoner i tabellen er oppdiktet; de viser hvordan ulike funn kan ses i sammenheng.
Kilde | Fiktivt funn | Grense for tolkningen |
|---|---|---|
Lukket mobil trakt | 100 økter når kassen; 60 fullfører kjøpet i samme observasjonsperiode. | Forskjellen er synlig, men årsaken er ukjent. |
Etter et ugyldig postnummer står feilteksten utenfor det synlige skjermområdet. | Dette er en konkret hindring i dette forløpet. | |
Betalingskontroll | Det finnes ingen tilknyttet betalingsforespørsel for denne oppgaven. | Det beviser ikke en avvisning fra banken. |
Kontroller først om betalingsregistreringene dekker transaksjonen som undersøkes, fullt ut. Manglende oppføringer kan også skyldes en ufullstendig kobling. Hvis det blir klart at skjemaet stopper før en betalingsforespørsel sendes, løser ikke en ekstra betalingsmetode dette skjemaproblemet.
Se oppgaven på den faktiske enheten
La oppgaven utføres i et egnet testmiljø. Noter enhet, nettleser, tastaturets tilstand og det siste forståelige trinnet. Kan personen se hvilket felt som er feil? Beholdes opplysninger som allerede er skrevet inn? Kan adressen rettes og kjøpet fortsette med valgt fraktmåte?
Betalingskontrollen utfyller observasjonen. Shopify beskriver for eksempel feil fra bankbeslutninger, betalingstjenesten eller nettbutikkens oppsett. En generell melding på skjermen viser ikke hvilket tilfelle som gjelder. Knytt tilgjengelige hendelser til den aktuelle testtransaksjonen i stedet for å telle alle ufullførte kjøp som betalingsfeil.
Gjør funnet til en endring som kan kontrolleres
For eksempelet er neste utkast: Det aktuelle adressefeltet er tilgjengelig, feilen beskrives der med forståelig tekst, og øvrige opplysninger beholdes. W3C forklarer at en automatisk oppdaget inndatafeil skal identifiseres og beskrives med tekst. Den foreslåtte endringen er ikke en fullstendig vurdering av tilgjengelighet.
Gjenta samme oppgave etter gjennomføringen, og se deretter på utviklingen i trakten med de samme definisjonene. Dokumenter også andre endringer, for eksempel i tilbudet eller trafikkildene. En vellykket oppgavetest viser brukbarheten i dette forløpet; den beviser ikke en generell effekt på omsetningen.
Kilder
Les videre
Alle artikler
E-handel med ASES
Nettbutikker, markedsplasser og B2B-portaler