Hur vet du när en design misslyckas med ett användbarhetsprov?
En praktisk teknik jag lärde mig från fel jobb ...
För flera år sedan spenderade jag en besvärlig lapp i min karriär som instruktionsdesigner och skapade kurser för online-lärande. Det var en dålig passform och jag gick lyckligt, men en del av jobbet har gjort mig till en bättre UX-designer: lärandemål.
Lärandemål är helt enkelt vad du vill att studenten ska lära sig i slutet av träningen. Om det finns ett test ska testfrågorna baseras på dessa mål - annars, vad är testets punkt?
Samma tillvägagångssätt är till nytta för att bestämma om en design har passerat eller misslyckats med ett användbarhetsprov. Kom bara ihåg: det är den design som testas, inte deltagarna.
Vad behöver provdeltagaren göra eller säga för att du ska känna dig säker på att designen har lyckats? Behöver de spåra tre timmar för ett visst projekt? Generera en faktura till en klient baserat på den spårade tiden? Skicka fakturan? Det är dina testkriterier.
Självklart testar användbarheten om att observera hur användarna fullföljer uppgifter, men vad kommer du att få dem att göra, exakt? Skönheten i dessa kriterier är att de styr dig borta från vaga testmål som "förstå hur tidspårningen fungerar." Hur kommer du att veta att de har förstått det? Du får dem att beskriva det. Och när de har beskrivit det exakt, kan du säga att den här aspekten av designen var framgångsrik.
Succeskriterier hjälper dig två gånger: de klargör huruvida din design är riktigt framgångsrik, och de gör det lättare att dela dessa resultat.
Verbs är magiska
Boken som lärde mig om lärandemål, George Piskurichs Snabba instruktionsdesign , erbjuder en praktisk lista över beteenden för att starta dina framgångskriterier.
Målen för förståelse kan till exempel vara "beskriva" eller "visa". Återigen är "förstå" inte bra - du behöver dem att säga (det vill säga beskriva) eller göra (det vill säga visa) något som bevisar för dig som de har förstått.
Och i en högre grad av svårighet kan en deltagare "förklara" eller "organisera"; på en högre nivå fortfarande, kan de "skapa" eller "utvärdera".
Oavsett vad du väljer att starta dina framgångskriterier är poängen att du kan observera huruvida en användare faktiskt har sagt eller gjort vad som helst som utgör uppdragsframgång.
"I slutet av den här sessionen ..."
Så, när du planerar ditt nästa användbarhetstest, och du arbetar med uppgifter, börja med att fråga "Vad ska en användare kunna göra med (eller säga om) denna design?"
Då kan du skriva något så här:
Vid slutet av sessionen ska deltagaren kunna:
- spåra tre timmar för ett visst projekt
- generera en faktura till en kund baserat på den spårade tiden;
- Beskriv skillnaden mellan spårningstid och loggningstid.
Nu har du tre succeskriterier och baserat på dem har du också en ganska tydlig känsla av vilka uppgifter du behöver ge deltagarna.
Ett tillvägagångssätt: Framgångskriterier är inte helt samma som uppgifter. Uppgifterna har mer sammanhang; De är skrivna för att läsas till deltagaren och kan innehålla en del sammanhang om uppgiften, särskilt om du styr dem för att hitta något i din prototyp. Till exempel:
Succeskriterier: Generera en faktura till en kund baserat på den spårade tiden
Uppgift: "Nu när du har spårat tre timmar på Atlasprojektet, visa mig hur du fakturerar Acme Products för din tid."
Något liknande, självklart, men framgångskriterier är för dig och ditt lag; uppgiften är för deltagaren i samband med användbarhetssessionen.
Och du kommer märka att ett av framgångskriterierna ovan handlar om att beskriva något, snarare än att slutföra en uppgift. Det kan vara en uppföljningsfråga till en uppgift. Dessa är praktiska för att validera om din designs mentala modell är tydlig för användarna. Jag har sett användarna hitta sig igenom en uppgift, men beskriv sedan en mentalmodell för appen som står i strid med hur den utformades. Det är uppgiftssucces för en deltagare, men ännu viktigare är det ett underliggande problem med att matcha den deltagandes mentalmodell.
Så börja med dina framgångskriterier och skriv sedan dina uppgifter och uppföljningsfrågor utifrån dina kriterier.
Intressenter älskar framgångskriterier
Intressenter bryr sig inte nödvändigtvis om din process, men de bryr sig verkligen om resultaten. Och om din presentation av resultaten är vag, kommer de att bli rättfärdigt irriterad.
"Användaren lyckades spåra några timmar, men vi var inte säkra på om hon förstod att spårningstiden inte är densamma som att logga in mot en klient ..." Tja, varför är du inte säker? Är det inte ditt jobb att räkna ut det här? Du slösar bort tiden, och inte ger dem tydliga riktlinjer för hur du fixar UX-problemen - vilket är ditt jobb, eller hur?
Succeskriterier hjälper dig två gånger: de klargör huruvida din design är riktigt framgångsrik, och de gör det lättare att dela dessa resultat.
Vi har haft framgång med att spåra framgångskriterier i ett enkelt bord och färgkodning resultaten. Såhär:
Vi piska upp ett färgkodat resultatresultat (grönt = framgång, rött = misslyckande) på vår wiki. I översta raden listar vi deltagare; I den vänstra kolumnen listar vi våra framgångskriterier. Det är fult, men snabbt och användbart.
Det här är lätt att skanna, visar ganska tydligt var problemen är och begrunder resultaten i de faktiska deltagarnas upplevelser. Vi listar också en bullet-punkts sammanfattning av resultat och en lista över användbarhetsproblem och rekommendationer precis under det. Vi nollar in på de problemen och iterera tills vi tror att de är löst. Din process kan vara lite annorlunda - kanske du är en konsult som överlämnar en rapport till en klient, till exempel - men fördelarna är desamma.