Bruikbaarheid is niet iets dat je zomaar in één fase van het ontwerp kunt bereiden, maar dat gedurende het hele proces moet worden ontwikkeld en verfijnd. Als u het beste eindproduct wilt, moet u anticiperen op echte gebruikersscenario's uit de prototypefase. Gebruikerstests moeten de laatste plaats zijn om na te denken over bruikbaarheid.
Waarom zou u zich zo vroeg in het proces zorgen maken over het testen van bruikbaarheid wanneer prototypering al een to do-lijst heeft die groot genoeg is? Want tenzij je prototype bruikbaar is, zullen al je testen je vertellen dat mensen niet van vreselijke producten houden.
tenzij je prototype bruikbaar is, zullen al je testen je vertellen dat mensen niet van vreselijke producten houden
Het is bijna vanzelfsprekend, maar je ontwerpt het product dat gebruikt moet worden door echte mensen. Om het voor te bereiden op echte mensen, zou het op echte mensen moeten worden getest. Prototypes zijn gebouwd voor experimenten, dus het is alleen zinvol om ze op echte gebruikers te testen.
Laten we, met dat in gedachten, eens kijken hoe we bruikbaarheid in gedachten kunnen houden bij het bouwen van het prototype, het testen van bruikbaarheid voordat je een prototype hebt en tips voor testen met prototypen ...
Usability-tests vóór het prototype
Gebruikerstests hoeven niet te beginnen met prototyping - sterker nog, als u over de middelen beschikt om eerder te beginnen, zou u dat moeten doen. Hoewel ze overwegend conceptueel zijn, kunnen deze tests de beste manier bepalen om de navigatie- en informatiearchitectuur van uw prototype te structureren. De meest voorkomende pre-prototypingstests zijn onder andere:
- Kaartsortering: eenvoudig en standvastig, deze test laat zien hoe gebruikers de informatie-architectuur van uw product verkiezen. Alle elementen van uw product worden op kaarten geschreven en de testpersonen worden gevraagd om ze te organiseren in vooraf gedefinieerde categorieën ("gesloten") of onder degenen die ze bedacht hebben ("open"). Zie Donna Spencer's voor meer informatie Kaartsortering: een definitieve gids.
- Tree Testing: de "zustertest" voor kaartsortering, tree testing evalueert de effectiviteit van bestaande informatie-architecturen. Gebruikers krijgen een eenvoudige, uitgeklede kaart van de site / app / etc. en gevraagd om door te klikken om bepaalde taken uit te voeren. De test controleert of ze de juiste route kiezen, en zo niet, waardoor ze verloren zijn gegaan. Oprichter van MeasuringU Jeff Sauro verklaart de details.
- Interviews: soms is de beste manier om uw gebruikers te begrijpen, gewoon vragen. Het klinkt eenvoudig genoeg, maar de nuances en strategieën voor gebruikersinterviews zijn eindeloos. Kate Lawrence, UX onderzoeker bij EBSCO Publishing geeft enkele tips over hoe deze specifiek te gebruiken voor usability testen.
Het eerder oplossen van problemen is altijd beter, en deze voorbereidende tests zullen ervoor zorgen dat de conceptuele basis van het prototype in goede vorm is voordat een enkele lijn wordt getekend.
De juiste gebruikers en de juiste taken
Hoewel usability-tests allemaal verschillend zijn, hebben ze allemaal gebruikers nodig, en de meeste hebben taken. Aangezien deze twee elementen prominent zijn in alle usability-testen, zullen we in het kort uitleggen hoe we beide het beste kunnen aanpakken.
- Werven van gebruikers: na al het werk met persona's, zou je nu een goed idee moeten hebben van je doelgebruikers. Het helpt ook om uw gebruikers te segmenteren op basis van gedrag. In feite moet je je niet druk maken over demografische gegevens. De grootste differentiator zal waarschijnlijk zijn of gebruikers hebben eerdere ervaring of kennis hebben van hun domein of branche - niet van geslacht, leeftijd of geografie.
Weten wie te werven is slechts de eerste stap. Het meer betrokken deel is het vinden en rekruteren van hen. Jeff Sauro schetst de 7 beste manieren om zoek de ideale gebruikers voor uw testen. - Schrijftaken: taken bepalen wat de gebruiker tijdens de test feitelijk doet en bepalen daarom welke usability-factoren worden onderzocht. Tingting Zhao, Usability Specialist voor Ubuntu , beschrijft enkele onderscheidingen om in gedachten te houden bij het ontwerpen van een taak. Er zijn 2 belangrijke beslissingen:
een. Direct versus scenario: een directe taak is een taak die strikt instructief is (bijv. "Zoek op de website naar een kiprecept van Tandoori"), terwijl een scenariotaak wordt geleverd met context ("Je host een etentje voor een paar oude vrienden, en je hebt een kiprecept van Tandoori nodig "). Directe taken werken het beste als u technische gegevens test, terwijl scenariotaken in alle andere gevallen beter zijn.
b. Closed versus open-ended: een gesloten taak heeft duidelijk gedefinieerde succescriteria, terwijl een taak met een open einde op meerdere manieren kan worden voltooid. Gesloten taken controleren specifieke functionaliteiten, terwijl open-ended taken beter zijn om te begrijpen hoe de geest van uw gebruikers werkt. Een gesloten taak zou zijn: "Je vriend heeft dit weekend een verjaardag. Vind een leuke locatie voor maximaal 15 personen. "Een openstaande taak zou zijn:" U hoorde uw collega's praten over de iWatch. U wilt leren hoe het werkt. "
Algemeen advies voor het testen van de bruikbaarheid van prototypen
Gezien het "incomplete" karakter van prototypen ... zullen gebruikers vragen hebben ... die een moderator zal moeten beantwoorden
Een van de eerste vragen die usability-testers stellen, is of ze gematigd moeten worden of niet. Terwijl er een zijn veel goede redenen voor niet-gematigde tests, raden we aan om voor prototypetests moderatie te gebruiken. Gezien het "incomplete" karakter van prototypen, is de kans groot dat gebruikers vragen hebben over de gebruikersinterface die een moderator moet beantwoorden.
Een andere veel voorkomende fout bij het testen is om de test te stoppen of te wijzigen als de gebruiker problemen ondervindt. Aangezien het doel van usability testen is om problemen te vinden en op te lossen, kan deze situatie de test daadwerkelijk tot een succes maken. Als de gebruiker bijvoorbeeld afdwaalt op paden die nog niet in het prototype zijn ontwikkeld, kun je hen vragen waarom ze daar naartoe zijn gegaan en wat ze graag hadden willen bereiken. Een paar vervolgvragen over de obstakels kunnen meer waardevolle feedback opleveren dan een gebruiker met een "perfecte run".
Verschillende getrouwheden voor het testen van prototypen
Hoewel sommigen geloven in het vroeg testen met ruwe prototypen en anderen pleiten voor het testen van prototypen van een hogere betrouwbaarheid, zijn we van mening dat de beste aanpak is om elke getrouwheid te testen - en zo vaak mogelijk. Chris Farnum, de Senior Informatie Architect bij Enlighten, legt het voors en tegens van elk type. Zoals we hieronder zullen beschrijven, zijn tests met lagere betrouwbaarheid beter voor het testen van concepten, terwijl tests met hogere betrouwbaarheid geschikter zijn voor het testen van geavanceerde interacties.
de beste aanpak is om bij elke mogelijke betrouwbaarheid te testen
- Lage getrouwheid: bruikbaarheidstests voor lo-fi prototypes, waaronder papieren prototypen, kunnen in de vroege stadia van ontwikkeling werken, maar worden later onpraktisch. Lo-fi prototypen stimuleren ook eerlijkere kritiek, omdat het meteen duidelijk is dat het slechts een werk in uitvoering is.
In de latere stadia, wanneer bruikbaarheidstests geavanceerde functies controleren, stoppen lo-fi prototypen niet meer, omdat je de betrouwbaarheidslimiet hebt bereikt. Dit geldt vooral voor papieren prototypen, omdat je een "menselijke computer" nodig hebt om alle onderdelen te manipuleren, en dat kan heel moeilijk worden als je menu's, interacties, pagina's en elementen toevoegt. - High fidelity: hi-fi prototypetests geven de gebruiker een bijna realistische ervaring van hoe het uiteindelijke product eruit zal zien. Hi-fi-prototypen zijn ideaal voor het testen van complexe interacties en uw oplossingen voor gebruiksproblemen die zijn ontdekt tijdens eerdere testrondes. In tegenstelling tot lo-fi prototypes zijn deze echter duurder om te maken.
- Medium-getrouwheid: kan niet kiezen tussen hoge of lage getrouwheid? Mid-fi prototypen werken het beste wanneer u een balans tussen betrouwbaarheid en kosten nodig hebt. Als u slechts één ronde bruikbaarheidstests wilt uitvoeren, gaat u naar medium-getrouwheid.
Vier inhoudsrichtlijnen voor het testen van elk prototype
Wanneer u begint met het bouwen van het prototype, is het niet alleen acceptabel om kleine details te verdoezelen in plaats van de essentie, het wordt soms aanbevolen. Maar als het tijd is om uw prototype te testen, moet u ervoor zorgen dat u een aantal van deze details hebt ingevuld die mogelijk over het hoofd worden gezien in mindere getrouwheid. In onze ervaring zijn dit de meest nuttige tips voor het voorbereiden van uw prototype voor testen:
- Vermijd lorem ipsum: afleidend, verwarrend en zonder betekenis, lorem ipsum- tekst geeft niet volledig de boodschap van uw product weer.
- Gebruik generieke namen: testen kunnen leuker zijn met domme of bekende namen, maar plezier is niet waar het om gaat. Afleidingen zullen de resultaten vertekenen, dus houd namen generiek en realistisch.
- Geen tijdelijke afbeeldingen of pictogrammen: vakken met X s werken mogelijk tijdens wireframing, maar niet tijdens het testen. Afbeeldingen en pictogrammen spelen een grote rol in UX, dus deze moeten worden geïmplementeerd door tijd te testen, ook al is het maar met tijdelijke schetsen. De uitzondering is als deze afbeeldingen puur decoratief zijn en niet helpen de gebruikersinterface te begrijpen.
- Gebruik realistische gegevens - vul geen gegevens in zoals telefoonnummers of adressen met X s of moppen - deze zijn storend. Realistische en geloofwaardige gegevens zullen uw gebruiker de meest nauwkeurige resultaten opleveren.
Deelnemers aan de test kunnen gefixeerd raken op details waarvan u dacht dat ze te verwaarlozen waren, dus wees voorzichtig met wat u niet zegt. Deze kleine stappen om afleiding en verwarring te verminderen, kunnen een heel eind in de richting van schonere testgegevens gaan.
Uitgelichte afbeelding, gebruiksvriendelijkheid testen via door K2_UX via Flickr.