Vurder skjemaer gjennom en hel oppgave
En fiktiv sammenligning viser hva som er åpent etter designgodkjenning: retting, inntastede data som beholdes, og bekreftet mottak.
Et skjema kan se forståelig ut i en designgjennomgang og skape ekstra arbeid når en inntasting rettes. Godkjenningen bør derfor angi hvilken del av forløpet som faktisk er vurdert, og hvilke spørsmål som er åpne.
Samme forespørsel, ulike forløp
Tabellen beskriver antatt oppførsel i to fiktive prosjektskjemaer. Startvisningene ser like ryddige ut. Begge angir telefonnummer som frivillig; personen vil sende en forespørsel som gir mulighet for oppfølgingsspørsmål via e-post.
Kontrolltilfelle | Versjon A | Versjon B |
|---|---|---|
Telefonfeltet er tomt | Behandles likevel som obligatorisk ved innsending. | Forblir frivillig. |
E-post er ufullstendig | Bare rød ramme, ingen hjelp til retting. | Forståelig feiltekst med vei til feltet. |
E-post rettes | Det allerede innlagte prosjektmålet forsvinner. | Prosjektmålet beholdes. |
Overføring er ubekreftet | Suksess vises straks etter klikket. | Mottaket vises som fortsatt ubekreftet. |
En gjennomgang bare av startvisningen avslører ikke forskjellene. Utseende og oppførsel under oppgaven må derfor vurderes sammen. W3C WAI behandler eksplisitt tilbakemeldinger ved felt og om resultatet av innsending som deler av skjemaforløpet.
Skill observasjon fra funksjonskontroll
GOV.UK beskriver brukertester med konkrete oppgaver og klare, nøytrale instruksjoner. Her kan målet være: «Send en prosjektforespørsel slik at teamet kan nå deg via e-post.» Man observerer om personen når målet, hvor vedkommende nøler, og hvilken hjelp som trengs. Instruksjonen røper ikke hvilken knapp som skal velges etterpå.
En forberedt funksjonskontroll undersøker i tillegg ufullstendige inntastinger og manglende serverbekreftelse. Den kan vise om verdier beholdes. Et teknisk gjennomspilt feiltilfelle er ikke en observasjon av faktiske brukere. De to typene funn svarer på ulike spørsmål.
Hva tidlig designgodkjenning kan vise
Et visuelt utkast hjelper med tidlig vurdering av ordlyd, informasjonshierarki og nærhet mellom hjelp og felt. Er ikke forløpene bygget, kan en klikkbar prototype gjøre retting forståelig. Serverens aksept må da markeres som en antatt tilstand.
Ved senere godkjenning er hele veien til bekreftet mottak viktig, inkludert avtalte feiltilfeller. Et tydelig godkjenningsnotat angir derfor den undersøkte oppgaven, den siste bekreftede tilstanden og åpne punkter.
Kilder
Les videre
Alle artikler
Design og UX med ASES
Brukeropplevelse, grensesnitt og merkevare