En prototype kan se ferdig ut i en presentasjon og fortsatt svikte i det øyeblikket noen prøver å bruke den. Knappen reagerer med mus, men ikke med finger. En horisontal flate kan dras på desktop, men låser seg på mobil. Overgangen ser riktig ut når den spilles automatisk, men stopper når brukeren avbryter den halvveis.

Dette er en type feil jeg har møtt flere ganger i interaktive web- og prototyparbeider den siste tiden. De har én ting til felles: Problemet er ikke først og fremst hvordan skjermen ser ut. Problemet ligger i atferden mellom skjermene.

En skjerm er ikke en interaksjon

Det er lett å vurdere et digitalt design som en serie stillbilder: startside, produktvisning, meny, modal, bekreftelse. Men brukeren opplever ikke produktet som en mappe med skjermer. Opplevelsen består av handlinger og respons.

Hva skjer når fingeren treffer elementet? Hva skjer dersom bevegelsen starter, men ikke fullføres? Kan brukeren gå tilbake? Beholder grensesnittet riktig tilstand etter en feil? Fungerer den samme handlingen med mus, finger og tastatur?

En prototype som bare viser sluttpunktene, kan derfor være nyttig for visuell vurdering, men den tester lite av selve interaksjonen.

Det visuelle kan skjule tekniske feil

En animasjon kan være jevn når den kjøres som en forhåndsbestemt sekvens. Det betyr ikke at den fungerer når brukeren styrer tempoet.

I et faktisk grensesnitt må systemet håndtere avbrudd. En bruker kan dra litt og slippe, bytte retning, trykke to ganger, rotere telefonen, åpne menyen midt i en overgang eller starte en ny handling før den forrige er ferdig.

Hvis prototypen bare er kontrollert gjennom den perfekte sekvensen, oppdages slike problemer sent.

Derfor prøver jeg å skille mellom to typer gjennomgang:

  • visuell QA: typografi, kontrast, avstand, hierarki og komposisjon
  • interaksjonskontroll: input, respons, tilstand, avbrudd, feil og overgang mellom handlinger

Begge er nødvendige. De avdekker forskjellige problemer.

Mus og finger er ikke samme test

På web kan samme grensesnitt brukes med mus, styreflate, finger, penn og tastatur. MDNs dokumentasjon om Pointer Events beskriver nettopp behovet for en felles modell som kan håndtere flere typer pekerinput.

Det betyr ikke at alle inputformer oppfører seg likt.

En mus kan bruke hover-tilstander. En finger har ikke samme mulighet. En musepeker er presis. En finger dekker en større del av skjermen. På mobil konkurrerer horisontale drag og swipe-bevegelser ofte med vanlig scrolling og nettleserens egne bevegelser.

W3Cs veiledning om ulike inputmetoder understreker også at brukere kan bytte mellom måter å styre grensesnittet på, og at funksjonalitet ikke bør være låst til én kompleks gest.

I praksis betyr det at et interaktivt element bør prøves på den faktiske enheten, ikke bare i en desktop-forhåndsvisning som simulerer mobilbredde.

Dra og sveipe trenger alternativer

Interaktive konsepter bruker ofte drag fordi det føles direkte. Man flytter et kort, drar i en tidslinje eller skyver mellom produkter.

Men drag er en mer krevende handling enn et enkelt trykk.

WCAG 2.2 har et eget kriterium for dra-bevegelser. Når en funksjon krever at noe dras, skal den som hovedregel også kunne utføres med en enkelt peker uten selve dra-bevegelsen, med mindre bevegelsen er nødvendig for funksjonen.

Det gir en nyttig designregel også utover tilgjengelighet: Hvis swipe er den eneste måten å komme videre på, bør man spørre om brukeren også trenger piler, knapper, punkter eller en annen tydelig kontroll.

Alternativet gjør ikke nødvendigvis opplevelsen mindre elegant. Det kan gjøre interaksjonen mer robust.

Test overgangen, ikke bare start og slutt

Når et element transformeres fra én tilstand til en annen, er det fristende å kontrollere bare at startbildet og sluttbildet ser riktige ut.

Men mye av kvaliteten ligger i mellomfasen.

Jeg ser særlig etter:

  • om retningen på bevegelsen er forståelig
  • om elementer beholder en logisk romlig sammenheng
  • om teksten flytter seg uten å kollidere med innholdet
  • om en avbrutt bevegelse finner tilbake til en gyldig tilstand
  • om neste handling kan starte før forrige animasjon er ferdig
  • om redusert bevegelse eller en enklere variant bør finnes
  • om interaksjonen fortsatt gir mening uten animasjonen

Det siste punktet er viktig. Bevegelse kan forklare hvordan to tilstander henger sammen, men funksjonen bør ikke bli uforståelig dersom den reduseres eller ikke spilles som planlagt.

Produktet finnes også mellom hovedskjermene

Det samme gjelder tilstander som sjelden havner i en pen designpresentasjon.

Hva ser brukeren mens innhold lastes? Hva skjer når noe mangler? Hvordan ser en tom liste ut? Hva skjer når handlingen lykkes, eller når den ikke kan fullføres?

I et nylig arbeid måtte jeg eksplisitt legge inn bekreftelser, feiltilstander og andre mellomtilstander etter at hovedflyten allerede så ferdig ut. Det er et godt eksempel på hvorfor en komplett prototype ikke kan vurderes bare ut fra hovedskjermene.

De mindre attraktive tilstandene er en del av produktet.

En enkel interaksjonskontroll

Før jeg kaller en interaktiv prototype ferdig, er dette en mer nyttig kontroll enn å spille gjennom den samme idealflyten én gang:

  • Bruk mus på desktop.
  • Bruk finger på en faktisk telefon.
  • Prøv tastatur der løsningen har kontroller som skal kunne nås.
  • Avbryt bevegelser halvveis.
  • Gjenta samme handling raskt.
  • Gå frem og tilbake mellom tilstander.
  • Test med tregere lasting eller manglende innhold når det er relevant.
  • Kontroller feil, tomme tilstander og bekreftelser.
  • Sjekk at det finnes et alternativ til dra-bevegelser eller kompliserte gester når funksjonen krever det.
  • Se om produktet fortsatt er forståelig når bevegelse reduseres.

Dette er intern kvalitetssikring av interaksjonen, ikke en erstatning for brukertesting. En teknisk fungerende kontroll beviser ikke at brukere forstår den, finner den eller velger riktig handling. Det må undersøkes med faktiske brukere og konkrete oppgaver.

Listen erstatter heller ikke teknisk testing. Men den fanger opp mange feil før en prototype presenteres som mer ferdig enn den faktisk er.

En prototype bør bevise mer enn utseendet

En prototype har høyere verdi når den kan svare på et konkret spørsmål.

Kan denne navigasjonen faktisk brukes med finger? Forstår brukeren hva som er neste steg? Overlever tilstanden en avbrutt overgang? Fungerer kontrollene på tvers av inputmetoder?

Hvis svaret bare er at skjermen ser riktig ut, har prototypen først og fremst testet det visuelle.

Det er nyttig, men det er ikke det samme som å teste produktets atferd.