Hvordan ved du, hvornår et design fejler en brugbarhedstest?
En praktisk teknik, jeg lærte af det forkerte job ...
For mange år siden tilbragte jeg en akavet patch i min karriere som instruktionsdesigner, der skabte kurser til online læring. Det var en dårlig pasform, og jeg gik glædeligt, men en del af det job har gjort mig til en bedre UX designer: læringsmål.
Læringsmål er simpelthen det, du vil have den studerende at lære efter uddannelsens afslutning. Hvis der er en test, skal testspørgsmålene baseres på disse mål - ellers hvad er testens punkt?
Den samme fremgangsmåde er praktisk til at finde ud af om et design er bestået eller mislykket en brugervenlighedstest. Bare husk: det er det design, der bliver testet, ikke deltagerne.
Hvad skal testdeltageren gøre eller sige for dig at være sikker på, at designet er lykkedes? Har de brug for at spore tre timer for et bestemt projekt? Generer en faktura til en klient baseret på den sporede tid? Send fakturaen? Det er dine test kriterier.
Selvfølgelig er brugervenlighedstest handler om at observere, hvordan brugerne gennemfører opgaver, men hvad vil du få dem til at gøre, præcis? Skønheden i disse kriterier er, at de styrer dig væk fra vage testmål som "forstår hvordan tidsporing fungerer." Hvordan vil du vide, at de har forstået det? Du får dem til at beskrive det. Og når de har beskrevet det nøjagtigt, kan man sige, at dette aspekt af designet var vellykket.
Succeskriterier hjælper dig to gange: De præciserer, om dit design er rigtig succesfuldt, og de gør det lettere at dele disse resultater.
Verbs er magiske
Bogen, der lærte mig om læringsmål, George Piskurichs Hurtigt undervisningsdesign , tilbyder en praktisk liste over adfærd for at starte dine succeskriterier.
For eksempel kan målene for forståelse være "beskrive" eller "demonstrere". Igen, "forstå" er ikke god - du har brug for dem til at sige (det vil sige beskrive) eller gøre (det vil vise) noget, der viser dig, at de har forstået.
Og så kan en deltager i højere grad af vanskeligheder "forklare" eller "organisere"; på et højere niveau stadig, kan de "skabe" eller "evaluere".
Uanset hvad du vælger at starte dit succeskriterium, er det meningen, at du kan observere, om en bruger faktisk har sagt eller gjort, uanset hvad der udgør opgavesucces.
"I slutningen af denne session ..."
Så når du planlægger din næste brugervenlighedstest, og du arbejder på opgaver, skal du starte med at spørge: "Hvad skal en bruger kunne gøre med (eller sige om) dette design?"
Så kan du skrive noget som dette:
Ved slutningen af sessionen skal deltageren kunne:
- spore tre timers tid til et bestemt projekt
- generere en faktura til en klient baseret på den sporede tid
- beskriv forskellen mellem sporingstid og loggetid.
Nu har du tre succeskriterier og baseret på dem har du også en ret klar følelse af hvilke opgaver du skal give deltagerne.
En advarsel: Succeskriterier er ikke helt de samme som opgaver. Opgaver har mere sammenhæng; de er skrevet til at blive læst til deltageren, og kan indeholde nogle kontekst om opgaven, især hvis du styrer dem for at finde noget i din prototype. For eksempel:
Succeskriterier: Generer en faktura til en kunde baseret på den sporede tid
Opgave: "Nu hvor du har sporet tre timer på Atlas-projektet, vis mig, hvordan du fakturerer Acme Products for din tid."
Temmelig lignende, selvfølgelig, men succes kriterier er for dig og dit team; opgaven er for deltageren i forbindelse med brugbarhedssessionen.
Og du vil bemærke, at et af succeskriterierne ovenfor handler om at beskrive noget, snarere end at udføre en opgave. Det kan være et opfølgende spørgsmål til en opgave. Disse er nyttige til at validere, om dit designs mentale model er klart for brugerne. Jeg har set brugere finde vej gennem en opgave, men beskriv mig så en mental model af appen, som er i modsætning til hvordan den blev designet. Det er opgavesucces for en deltager, men vigtigere er der et underliggende problem med at matche den deltagendes mentale model.
Så start med dine succeskriterier, skriv derefter dine opgaver og opfølgningsspørgsmål baseret på dine kriterier.
Interessenter elsker succeskriterier
Interessenter bekymrer sig ikke nødvendigvis om din proces, men de bryr sig virkelig om resultaterne. Og hvis din præsentation af resultaterne er vag, bliver de retfærdigt irriteret.
"Brugeren klarte at spore et par timer, men vi var ikke sikre på, om hun forstod at sporingstiden ikke er den samme som at logge den mod en klient ..." Nå, hvorfor er du ikke sikker? Er det ikke dit job at finde ud af det? Du spilder deres tid, og ikke giver dem klare retninger om, hvordan du løser UX-problemerne - hvilket også er dit job, ikke?
Succeskriterier hjælper dig to gange: De præciserer, om dit design er rigtig succesfuldt, og de gør det lettere at dele disse resultater.
Vi har haft succes til at spore succeskriterier i et simpelt bord og farvekodning af resultaterne. Ligesom:
Vi pisker op i en farvekodet tabel med resultater (grøn = succes, rød = fiasko) på vores wiki. I øverste række viser vi deltagere; I venstre kolonne opregner vi vores succeskriterier. Det er grimt, men hurtigt og nyttigt.
Dette er let at scanne, viser ret klart, hvor problemerne er, og begrunder resultaterne i de faktiske deltagers oplevelser. Vi giver også en oversigt over resultater og en liste over brugervenlighedsproblemer og anbefalinger lige under det. Vi nuler på disse problemer og gentager, indtil vi tror, de er løst. Din proces kan være lidt anderledes - måske er du konsulent, der overleverer en rapport til en klient, for eksempel - men fordelene er de samme.