#38: Iteratie 3.2: Resultaten

Zoals omschreven in blogpost #36, ben ik begonnen met het evalueren van mijn eerste digitale prototype. Na 3 testgebruikers werden er al enkele problemen/opmerkingen duidelijk, waardoor ik besloot deze eerst aan te pakken en dan pas verder te gaan testen. Wat volgt zijn bijgevolg de resultaten van een zeer korte iteratie, die toch een aantal belangrijke wijzigingen als gevolg hadden.

5 Testgebruikers

  • Wie:
    • 2 studenten en 1 doctoraat-student uit Leuven
    • 3 mannen
    • Allemaal smartphone-gebruikers (2 iPhone, 1 Android)
    • Leeftijd: 1 persoon van 18 jaar, 1 van 23 jaar en 1 van 25 jaar
  • Waar:
    • Op de campus
    • In een sporthal
  • Duur:
    • +/- 10 minuten

6 Resultaten

[n = x betekent dat x testgebruikers dit probleem, deze opmerking of dit positief punt aanhaalden]

  • Problemen met de interface:
    • Niet duidelijk wat locatie-notificatie betekent (n=1)
    • Knop om iets toe te voegen niet dadelijk gevonden (n=1)
    • Poging om naar het overzicht van de calorieënbalans te gaan door te klikken op het appeltje op de eerste pagina (n=1)
  • Opmerkingen:
    • Geen mogelijkheid om zelf voeding of activiteiten in te geven via de applicatie zelf (n=2)
    • Badges niet onder profiel verwacht (n=1)
    • Cold-start probleem: applicatie is redelijk leeg bij het eerste gebruik (n=1)
    • Geen mogelijkheid om feedback te geven via de applicatie zelf (n=1)

7 SUS-score

  • Resultaten van SUS-questionnaire: 100, 90, 87.5
  • Gemiddelde: 92.5
  • Interpretatie:
    • Een SUS-score van 68 wordt als gemiddeld beschouwd, dus alle applicaties die meer dan 68 scoren, zitten boven het gemiddelde[1]
    • Een interface van een applicatie met een SUS-score vanaf 90.9 wordt beschouwd als de beste voorstelbare interface voor die applicatie[2]

8 Conclusie

  • De meeste taken kunnen zonder problemen worden uitgevoerd en de interface is duidelijk voor alle testgebruikers.
  • Badges worden niet verwacht om in het profiel te zitten. Het doel van de applicatie is het motiveren van gebruikers en badges zijn een middel om dit te doen. De badges moeten dus prominenter aanwezig zijn

IMG_0045_2

  • Er wordt niet genoeg uitleg gegeven bij wat de notificatie op basis van locatie juist betekent. Wat de dagelijkse notificatie voor gewicht door is wel meteen duidelijk.

notificatie

  • De applicatie is leeg voor nieuwe gebruikers. Dit moet zo veel mogelijk vermeden worden om zo het eerste gebruik eenvoudiger te maken voor nieuwe gebruikers. Het moet bijvoorbeeld duidelijk zijn hoe een nieuw voedingsproduct of een nieuwe activiteit ingegeven moet worden voor iemand die dit nog nooit eerder deed.

foto2

  • Op het moment dat de applicatie online verspreid kan worden, is het moeilijk om nog feedback te krijgen van elke gebruiker als er geen mogelijkheid is om dit via de applicatie zelf te doen
  • Gebruikers willen graag zelf voeding of activiteiten toevoegen als deze niet in de database aanwezig zijn
  • Het is logisch dat het appeltje op de eerste pagina ook een functionaliteit heeft, bijvoorbeeld als knop naar het overzicht van de calorieënbalans

 foto 1

Referenties

[1] Jeff Sauro. Measuring Usability With The System Usability Scale (SUS), http://www.measuringusability.com/sus.php, February 2011.
[2] Aaron Bangor, Philip Kortum, and James Miller. Determining What Individual SUS Scores Mean: Adding an Adjective Rating Scale. Journal of Usability Studies, 4(3):114-123, 2009.

Als je zelf het paper prototype eens bekijkt, vind je dan dat deze opmerkingen van de testgebruikers terecht zijn (d.w.z. deel jij hun mening)? Zijn er eventueel nog andere dingen die je dadelijk opvallen in het paper prototype en die je graag anders zou zien?

Laat mij weten wat jij hierover denkt..