Hoe weet u wanneer een ontwerp niet voldoet aan een gebruikerstest?
Een handige techniek die ik heb geleerd van de verkeerde baan ...
Jaren geleden heb ik een lastig klusje van mijn carrière doorgebracht als een educatieve ontwerper en cursussen ontwikkeld voor online leren. Het was een slechte match en ik ben tevreden verder gegaan, maar een deel van die baan heeft me een betere UX-ontwerper gemaakt: leerdoelen.
Leerdoelen zijn gewoon wat je wilt dat de student leert aan het einde van de training. Als er een test is, moeten de testvragen gebaseerd zijn op die doelstellingen - anders, wat is het nut van de test?
Dezelfde aanpak is handig om uit te zoeken of een ontwerp is geslaagd voor een bruikbaarheidstest. Onthoud gewoon: het is het ontwerp dat wordt getest, niet de deelnemers.
Wat moet de testmedewerker doen of doen om er zeker van te zijn dat het ontwerp geslaagd is? Moeten ze drie uur tijd bijhouden voor een bepaald project? Genereer een factuur naar een klant op basis van die gevolgde tijd? Verstuur de factuur? Dat zijn uw testcriteria.
Natuurlijk gaat usability testing over het observeren van hoe gebruikers taken uitvoeren, maar wat ga je ze laten doen, precies? Het mooie van deze criteria is dat ze je afleiden van vage testdoelen zoals 'begrijp hoe tijdregistratie werkt'. Hoe weet je dat ze het begrepen hebben? Je laat ze het beschrijven. En als ze het eenmaal nauwkeurig hebben beschreven, kun je zeggen dat dat aspect van het ontwerp succesvol was.
Succescriteria helpen u twee keer over: zij verduidelijken of uw ontwerp echt succesvol is en maken het gemakkelijker om die resultaten te delen.
Werkwoorden zijn magisch
Het boek dat me leerde over leerdoelen, van George Piskurich Snel instructief ontwerp , biedt een handige lijst met gedragingen om uw succescriteria te starten.
De doelstellingen voor begrip kunnen bijvoorbeeld 'beschrijven' of 'demonstreren'. Nogmaals, "begrijpen" is niet goed - je hebt ze nodig om te zeggen (dat is, beschrijven) of doen (dat wil zeggen, aantonen) iets dat je bewijst dat ze het begrepen hebben.
En dan, in een hogere moeilijkheidsgraad, kan een deelnemer "uitleggen" of "organiseren"; op een nog hoger niveau kunnen ze "creëren" of "evalueren".
Welk werkwoord u ook kiest om aan uw succescriteria te beginnen, het gaat erom dat u kunt observeren of een gebruiker werkelijk alles gezegd of gedaan heeft wat taaksucces is.
"Tegen het einde van deze sessie ..."
Dus, wanneer u uw volgende gebruikerstest plant en u werkt aan taken, begin dan met de vraag: "Wat moet een gebruiker kunnen doen met (of iets zeggen over) dit ontwerp?"
Dan zou je zoiets als dit kunnen schrijven:
Aan het einde van de sessie moet de deelnemer in staat zijn om:
- bijhouden van drie uur tijd voor een bepaald project;
- een factuur naar een klant genereren op basis van die gevolgde tijd;
- beschrijf het verschil tussen trackingtijd en loggingstijd.
U hebt nu drie succescriteria en op basis hiervan heeft u ook een vrij duidelijk idee van de taken die u de deelnemers moet geven.
Een waarschuwing: succescriteria zijn niet helemaal hetzelfde als taken. Taken hebben meer context; ze zijn geschreven om voor de deelnemer te worden gelezen en kunnen een context bevatten over de taak, vooral als je ze stuurt om iets in je prototype te vinden. Bijvoorbeeld:
Succescriteria: genereer een factuur naar een klant op basis van die gevolgde tijd
Taak: "Nu u drie uur op het Atlas-project hebt getrackt, laat me zien hoe u Acme Products voor uw tijd zou factureren."
Vrij gelijkaardig, uiteraard, maar succescriteria zijn voor jou en je team; de taak is voor de deelnemer in de context van de usability-sessie.
En je zult zien dat een van de succescriteria hierboven gaat over het beschrijven van iets, in plaats van het voltooien van een taak. Het kan een vervolgvraag zijn voor een taak. Deze zijn handig om te valideren of het mentale model van uw ontwerp duidelijk is voor gebruikers. Ik heb gebruikers een weg zien vinden door een taak, maar beschrijf vervolgens een mentaal model van de app dat in strijd is met hoe het is ontworpen. Dat is taaksucces voor één deelnemer, maar wat nog belangrijker is, is dat er een onderliggend probleem is met het mentale model van die deelnemer.
Dus begin met uw succescriteria en schrijf vervolgens uw taken en vervolgvragen op basis van uw criteria.
Stakeholders houden van succescriteria
Belanghebbenden geven niet noodzakelijkerwijs om uw proces, maar zij geven echt om de resultaten. En als uw presentatie van de resultaten vaag is, zullen zij terecht geïrriteerd zijn.
"De gebruiker slaagde erin een paar uur te volgen, maar we wisten niet zeker of ze begreep dat de trackingtijd niet hetzelfde is als het loggen tegen een klant ..." Wel, waarom weet je het niet zeker? Is het niet jouw taak om dit uit te zoeken? Je verspilt hun tijd en geeft ze geen duidelijke aanwijzingen over hoe je de UX-problemen kunt oplossen - wat ook jouw taak is, toch?
Succescriteria helpen u twee keer over: zij verduidelijken of uw ontwerp echt succesvol is en maken het gemakkelijker om die resultaten te delen.
We hebben succes gehad met het bijhouden van succescriteria in een eenvoudige tabel en hebben de resultaten in kleur gecodeerd. Zoals zo:
We maken een kleurgecodeerde tabel met resultaten (groen = succes, rood = mislukking) op onze wiki. In de bovenste rij geven we deelnemers een lijst; in de linkerkolom geven we onze succescriteria op. Het is lelijk, maar snel en nuttig.
Dit is gemakkelijk te scannen, toont vrij duidelijk waar de problemen liggen en grondt de resultaten in de ervaringen van echte deelnemers. We geven ook een samenvatting van de resultaten en een lijst met bruikbaarheidsproblemen en aanbevelingen net eronder. We nemen die problemen op nul en herhalen totdat we denken dat ze zijn opgelost. Uw proces kan een beetje anders zijn - misschien bent u een consultant die bijvoorbeeld een rapport aan een klant overhandigt - maar de voordelen zijn hetzelfde.