De constructie van vragen bij gebruikerstesten is erg belangrijk om betrouwbare en bruikbare inzichten te verzamelen. Laten we een aantal veelvoorkomende fouten als voorbeeld nemen: we zullen zien hoe we ze kunnen vermijden en onze testprotocollen kunnen verbeteren.
1 – Hoe zou u dit product gebruiken?
Besteed aandacht aan alle vragen die de gebruiker vragen om zichzelf te projecteren op toekomstig gedrag. We moeten de "declarative" altijd met een korreltje zout nemen, zelfs wanneer de gebruiker zijn herinnering aan een echte situatie rapporteert, en het is bijzonder moeilijk om erop te vertrouwen wanneer de gebruiker zich een fictieve situatie moet voorstellen: wat we ons voorstellen te doen is komt niet vaak overeen met wat we daadwerkelijk gaan doen.
“Hoe gebruikt u/heeft u dit product gebruikt?”
In plaats van hem te vragen zich de toekomst voor te stellen, kunnen we de gebruiker in plaats daarvan vragen stellen over het heden of het verleden: "hoe gebruik je vergelijkbare producten of functionaliteiten vandaag?", "Wat zijn je eerdere ervaringen met vergelijkbare producten of functies?"
We kunnen ook zijn spontane gebruik van het product zien tijdens het testscenario. Om dit te doen, zullen we proberen de gebruiker zo min mogelijk te begeleiden, ook als dit betekent dat hij naar bepaalde schermen moet terugkeren om vragen te stellen en elementen te testen die nog niet eerder zijn gezien.
2 – Moeten we deze functionaliteit toevoegen?
Wanneer we een gebruiker vragen of hij wil dat we een extra element toevoegen: informatie, een functie, een pagina, enz. we vragen nog steeds om een projectie in de toekomst. Voor de gebruiker, die vrijwel altijd “ja” zal zeggen, zal het niet concreet genoeg zijn: er zijn weinig redenen om tegen een toevoeging te zijn. Het zal tijdens de analyse moeilijk zijn om het aandeel overtuigde "ja" te berekenen om de aantrekkingskracht van de functionaliteit echt te beoordelen. We kunnen geen conclusies trekken.
Observeren van gedrag
Hier, in plaats van een vraag, observeren we liever het gedrag tijdens de test. De beste manier om de aantrekkingskracht van een kenmerk te beoordelen, is altijd door het gebruik ervan direct te observeren of, als het nog niet bestaat, door het gedrag rond de afwezigheid ervan te observeren: we rapporteren bijvoorbeeld een irriterend element dat door dit kenmerk zou kunnen worden gecorrigeerd.
3 – Begrijp je dit element?
De gebruiker vragen om zijn begrip zelf te evalueren, is riskant: afgezien van de sociale wenselijkheid in de testcontext, is de gebruiker niet altijd een goede beoordelaar van zijn eigen begrip. Ze kunnen een inhoud of een functionaliteit perfect begrijpen en complexiteit voelen, of door een gebrek aan zelfvertrouwen, niet geloven dat ze het begrijpen, en tegelijkertijd kunnen ze de indruk hebben het begrepen te hebben en alles of een deel ervan missen de betekenis.
"Kun je me dit element uitleggen?"
In plaats daarvan wordt de gebruiker gevraagd het item in zijn eigen woorden uit te leggen. Wanneer het antwoord onjuist of onnauwkeurig is, worden er altijd herinneringen toegevoegd om ervoor te zorgen dat ze een misverstand vormen bij de gebruiker in plaats van een moeilijkheid om zichzelf uit te drukken of een element uit te leggen dat in feite wordt begrepen. Op een 2nd tijd kunnen we ook vragen of ze het duidelijk of gemakkelijk te begrijpen vonden, dan hebben we twee dingen geëvalueerd: begrip maar ook de complexiteit die door de gebruiker wordt waargenomen.
4 – Hoe zou dit element verbeterd kunnen worden?
Over het algemeen vermijden we het werven van deelnemers die in digitaal ontwerp werken om geen deskundige beoordeling te krijgen in plaats van een gebruikerstest. Daarom zijn onze gebruikers geen ontwerpers en het is complex en riskant om hen te vragen zichzelf in deze rol te plaatsen.
"Hoe zou dit element in een ideale wereld werken?"
Om te weten hoe we een element kunnen verbeteren, zullen we eerder de moeilijkheden van de gebruiker observeren en hem vragen om ze ons uit te leggen, om in detail uit te leggen wat niet werkt en waarom. Het is aan de ontwerper om de oplossing voor deze moeilijkheden te vinden: het is een baan!
We kunnen deze vraag eigenlijk stellen, niet om het gewenste ontwerp op te nemen zoals het is, maar om het opnieuw te lanceren om nog beter te begrijpen wat het blokkeert. Het is eerder als volgt geformuleerd: “Wat zou je in een ideale wereld met dit element kunnen doen? Hoe zou het werken? ".
5 – Is dit product esthetisch?
Smaken en kleuren zijn erg subjectief en als we gebruikers vragen om de esthetiek van een product, een site, een pagina te beoordelen, krijgen we tegenstrijdige gegevens: de kleur zal de helft van de respondenten tevreden stellen en de andere helft niet. Het voorbeeld van kleur is relevant omdat het vaak dit element is dat een deelnemer die geen ontwerper is het eerst opvalt, en het is ook het element dat zelden kan worden gewijzigd.
“Wat betekent het ontwerp van de site voor jou?”
Esthetiek blijft een belangrijke as om te evalueren, omdat het deelneemt aan de perceptie van bruikbaarheid van de interface. Gebruikers kunnen ons veel vertellen over hun perceptie van het product door hun mening over de esthetiek. We vragen liever “wat roept de vormgeving van de site bij jou op? », « welke woorden komen in je op om de esthetiek van de site te beschrijven? » en herlanceer spontane opmerkingen « U zegt dat er te veel kleuren zijn, kunt u mij uitleggen waarom? Wat zijn de gevolgen van dit "te veel kleuren"? Wat voel je ? ".
Afhaal
Tijdens een gebruikerstest is het vergelijken van gedragingen met verklaringen van deelnemers de beste manier om relevante gegevens te verzamelen.
Wanneer we een wankele vraag in ons protocol ter discussie stellen, moeten we altijd terugkeren naar onze onderzoeksvraag en onszelf afvragen:
- Waarom willen we deze vraag aan de gebruiker stellen?
- Wat proberen we te meten?
- Hoe kunnen we het meten?
Marie EUZEN, UX-ontwerper @UX-Republic
Onze volgende trainingen
DESIGN THINKING: INNOVATIE CREREN # Paris
GLIMLACH Parijs
Kade 163 van Doctor Dervaux 92600 Asnières-sur-Seine
UX-DESIGN: DE BASIS # Paris
GLIMLACH Parijs
Kade 163 van Doctor Dervaux 92600 Asnières-sur-Seine
UX-DESIGN: DE GRONDBEGINSELEN # België
UX-REPUBLIEK België
Broquevillelaan 12 - 1150 Sint-Pieters-Woluwe
UX BEHEREN EN METEN # Paris
GLIMLACH Parijs
Kade 163 van Doctor Dervaux 92600 Asnières-sur-Seine
UX/UI ECO-DESIGN # Parijs
GLIMLACH Parijs
Kade 163 van Doctor Dervaux 92600 Asnières-sur-Seine
TOEGANKELIJK UX/UI DESIGN # België
UX-REPUBLIEK België
Broquevillelaan 12 - 1150 Sint-Pieters-Woluwe
UX WRITING: MENSELIJKE LINKS MAKEN VIA MICROCOPY # Paris
GLIMLACH Parijs
Kade 163 van Doctor Dervaux 92600 Asnières-sur-Seine
GEBRUIKERSONDERZOEK: Leren van gebruikers
UX-REPUBLIEK België
Broquevillelaan 12 - 1150 Sint-Pieters-Woluwe
GEBRUIKERSTESTS # België
UX-REPUBLIEK België
Broquevillelaan 12 - 1150 Sint-Pieters-Woluwe
DESIGN SPRINT: INITIATIE & FACILITATIE # Paris
GLIMLACH Parijs
Kade 163 van Doctor Dervaux 92600 Asnières-sur-Seine