Hvordan vet du når et design feiler en brukbarhetstest?
En praktisk teknikk jeg lærte fra feil jobb ...
For mange år siden tilbrakte jeg en plagsom patch av karrieren min som instruktør designer, og skapte kurs for nettbasert læring. Det var en dårlig passform, og jeg flyttet lykkelig, men en del av jobben har gjort meg til en bedre UX-designer: læringsmål.
Læringsmål er rett og slett det du vil at studenten skal lære ved slutten av treningen. Hvis det er en test, bør testspørsmålene være basert på disse målene - ellers, hva er poenget med testen?
Den samme tilnærmingen kommer til nytte for å finne ut om et design har passert eller mislyktes en brukervennlighetstest. Bare husk: det er designet som blir testet, ikke deltakerne.
Hva må testdeltakeren gjøre eller si for deg å være trygg på at designet har lykkes? Trenger de å spore tre timer for et bestemt prosjekt? Generer en faktura til en klient basert på den spore tiden? Send fakturaen? Det er testkriteriene dine.
Selvfølgelig test av brukervennlighet handler om hvordan brukerne fullfører oppgaver, men hva vil du få dem til å gjøre, akkurat? Skjønnheten i disse kriteriene er at de styrer deg bort fra vage testmål som "forstå hvordan tidsporing fungerer." Hvordan vil du vite at de har forstått det? Du får dem til å beskrive det. Og når de har beskrevet det nøyaktig, kan du si at aspektet av designet var vellykket.
Suksesskriterier hjelper deg to ganger: de avklarer om designet ditt er veldig vellykket, og de gjør det lettere å dele resultatene.
Verbs er magiske
Boken som lærte meg om læringsmål, George Piskurichs Raskt Instruksjonsdesign , tilbyr en praktisk liste over atferd for å starte suksesskriteriene dine.
For eksempel kan målene for forståelse være "beskrive" eller "demonstrere". Igjen, "forstå" er ikke bra - du trenger dem til å si (det er å beskrive) eller gjøre (det er, demonstrere) noe som viser deg som de har forstått.
Og så, i en høyere grad av vanskelighet, kan en deltaker "forklare" eller "organisere"; på et høyere nivå fortsatt, kan de "lage" eller "evaluere".
Uansett verb du velger å starte suksesskriteriene, er poenget at du kan observere hvorvidt en bruker faktisk har sagt eller gjort hva som helst som utgjør oppgavssuksess.
"Ved slutten av denne økten ..."
Så når du planlegger din neste brukervennlighetstest, og du jobber med oppgaver, start med å spørre, "Hva skal en bruker kunne gjøre med (eller si om) denne designen?"
Deretter kan du skrive noe slikt:
Ved slutten av sesjonen skal deltakeren kunne:
- spore tre timer for et bestemt prosjekt;
- generere en faktura til en klient basert på den spore tiden;
- Beskriv forskjellen mellom sporingstid og loggingstid.
Nå har du tre suksesskriterier, og på bakgrunn av disse har du også en ganske klar følelse av hvilke oppgaver du trenger for å gi deltakerne.
En advarsel: Suksesskriteriene er ikke helt de samme som oppgaver. Oppgaver har mer sammenheng; de er skrevet for å bli lest til deltaker, og kan inkludere litt kontekst om oppgaven, spesielt hvis du styrer dem for å finne noe i prototypen din. For eksempel:
Suksesskriterier: Generer en faktura til en klient basert på den spore tiden
Oppgave: "Nå som du har sporet tre timer på Atlas-prosjektet, vis meg hvordan du fakturerer Acme Products for din tid."
Ganske liknende, selvfølgelig, men suksesskriterier er for deg og ditt lag; oppgaven er for deltaker i sammenheng med brukbarhetsøkten.
Og du vil legge merke til at en av suksesskriteriene ovenfor handler om å beskrive noe, heller enn å fullføre en oppgave. Det kan være et oppfølgingsspørsmål til en oppgave. Disse er nyttige for å validere om designens mentale modell er tydelig for brukerne. Jeg har sett brukere finne seg gjennom en oppgave, men beskriv meg en mental modell av appen som er i strid med hvordan den ble designet. Det er oppgavssuksess for en deltaker, men enda viktigere er det et underliggende problem med å matche den deltakerens mentale modell.
Så, start med suksesskriteriene dine, skriv deretter opp dine oppgaver og oppfølgingsspørsmål basert på dine kriterier.
Interessenter elsker suksesskriterier
Interessenter bryr seg ikke nødvendigvis om prosessen, men de bryr seg virkelig om resultatene. Og hvis presentasjonen av resultatene er uklar, blir de rettferdig irritert.
"Brukeren klarte å spore noen timer, men vi var ikke sikre på om hun forsto at sporingstiden ikke er den samme som å logge den mot en klient ..." Vel, hvorfor er du ikke sikker? Er det ikke din jobb å finne ut av det? Du kaster bort tiden deres, og ikke gir dem klare retninger på hvordan du fikser UX-problemene - det er også din jobb, ikke sant?
Suksesskriterier hjelper deg to ganger: de avklarer om designet ditt er veldig vellykket, og de gjør det lettere å dele resultatene.
Vi har hatt suksess sporing suksess kriterier i et enkelt bord, og fargekoding resultatene. Som så:
Vi pisker opp en fargekodet tabell med resultater (grønn = suksess, rød = feil) på vår wiki. I øverste rad viser vi deltakere; I venstre kolonne lister vi våre suksesskriterier. Det er styggt, men raskt og nyttig.
Dette er enkelt å skanne, viser ganske klart hvor problemene er, og begrunner resultatene i de faktiske deltakernees erfaringer. Vi opplister også en punktoppsummering av resultater og en liste over bruksproblemer og anbefalinger like under det. Vi vil nullle på disse problemene og gjenta til vi tror de er løst. Prosessen din kan være litt annerledes - kanskje du er en konsulent som overleverer en rapport til en klient, for eksempel - men fordelene er de samme.