PP1: Resultaten & conclusies

5) Wie, Wanneer?
Deze testen werden afgenomen bij 9 personen, waaronder 7 triatleten, een loopster en een voetballer (n=9). De leeftijd van deze personen ligt tussen de 23 en de 45 jaar. Deze 9 personen bestonden uit 5 mannen en 4 vrouwen. Slechts 3 personen zijn niet in het bezit van een smartphone. Alle personen gaven aan een basiskennis van het Engels te hebben. Er werd telkens een afspraak gemaakt met elk individu. De triatleten werden steeds in de cafetaria van het zwembad van Mechelen aan deze testen onderworpen. Een test nam ongeveer een uur per persoon in beslag.

6) Resultaten & Mogelijke oplossingen
Een aantal kleinere en grotere problemen zijn aan het licht gekomen bij het analyseren van de opmerkingen die tijdens de testen werden vermeld. Enkel de grotere problemen zullen hier besproken worden. Dit wil niet zeggen dat de kleinere problemen niet zullen worden opgelost. Deze problemen hebben zowel te maken met de inhoud als de usability van het ontwerp. Daarom zal enkel de stem van de triatleten worden opgenomen wanneer het probleem iets te maken heeft met de inhoud van het ontwerp. Voor elk probleem zal een mogelijke oplossing worden besproken die kan gebruikt worden voor een volgende versie van het prototype.

1. Toevoegen en inplannen van een activiteit (n=6)
header-myplanningprogress
Probleem:
6 van de 9 gebruikers maakten gebruik van de ‘Add activity’ knop voor zowel het toevoegen van afgewerkte activiteiten als het inplannen van activiteiten. Het is echter de bedoeling om de ‘Add activity’ knop enkel te gebruiken voor het toevoegen van bestaande activiteiten. Het inplannen van een activiteit kan door het juiste vakje in de planning aan te klikken.

Mogelijke oplossing:
De gebruiker dient eerst activiteiten te plannen en daarna activiteiten die werden afgewerkt toe te voegen. Daarom kunnen geplande en afgewerkte activiteiten aan elkaar gerelateerd worden. Bijvoorbeeld dat gebruikers een activiteit eerst moeten toevoegen aan hun planning, om daarna het resultaat van de activiteit te kunnen aanvullen. Momenteel is er nog geen relatie tussen beide concepten, waardoor de gebruiker twee keer eenzelfde activiteit moet toevoegen. Het is dus beter om een ingeplande activiteit te gebruiken bij het toevoegen van de details van de activiteit wanneer deze werd afgewerkt.

Het is dus overbodig om twee knoppen te voorzien waarmee activiteiten kunnen worden toegevoegd of ingepland. Een mogelijkheid is om alles via de planning te laten verlopen. Daardoor moeten gebruikers op een ingeplande activiteit vanuit de planning klikken om de resultaten ervan toe te voegen. Een bijkomende mogelijkheid is om gebruikers te vragen naar de resultaten van een geplande activiteit indien deze reeds afgelopen is, bijvoorbeeld: “Hallo Tom, ik denk dat je gisteren een zwemtraining hebt afgewerkt. Klik hier om de resultaten aan te vullen!”. Deze aanpassingen brengen bij tot het behalen van de ontwerp criteria rond data captatie en het plannen van activiteiten.

2. Knop om toevoegen van activiteit te bevestigen (n=3)
importfile
Probleem:
Het bevestigen van het toevoegen van een activiteit nadat alle gegevens werden ingevuld, was niet helemaal duidelijk. 3 van de 9 gebruikers wisten niet goed op welke knop er geklikt diende te worden.

Mogelijke oplossing:
Dit probleem heeft te maken met het ontwerp criterium van data captatie. De oorzaak van dit probleem is te vinden bij de benaming van de knop. Deze knop heeft namelijk dezelfde naam als de knop voor het toevoegen van een nieuwe activiteit. Daarom ontstond er verwarring dat indien er op deze knop werd geduwd, er opnieuw een nieuwe activiteit zou moeten worden ingegeven. In andere kaders van het ontwerp werd soms de naam ‘Save’ gegeven aan een knop om ingevulde gegevens te bevestigen. Omdat consistentie één van de ontwerp criteria is, zal in het volgende prototype steeds ‘Save’ gebruikt worden bij dergelijke gevallen. De drie gebruikers gaven aan dat deze benaming beter zou passen bij deze knop.

3. Weergave planning: geplande afstand vs afgelegde afstand (n=6)
planning
Probleem:
6 van de 9 gebruikers gaven de opmerking dat de planning enkel de geplande afstanden toont, terwijl ze de afstand die effectief werd afgelegd ook willen zien.

Mogelijke oplossing:
De afstanden die effectief werden afgelegd kunnen ook in de planning worden getoond. Hiervoor kan gewerkt worden met kleuren. Door de effectieve afstand toe te voegen kan de triatleet makkelijk nagaan of hij/zij voldoet aan de vooropgestelde planning. Misschien wordt er meestal een grotere afstand afgewerkt dan gepland, waaruit de triatleet kan leren om volgende keer een grotere afstand in te plannen.

4. Weergave planning: trainingscategorieën (n=3)
Probleem:
Gebruikers kunnen op de planning enkel de geplande afstanden bekijken. Om een overzicht te krijgen van de weekplanning, is het ook belangrijk te kunnen inschatten hoe zwaar de planning is. Worden de geplande afstanden tegen een strak tempo afgelegd? Als een triatleet drie trainingen op één dag voorziet, zijn deze trainingen dan allemaal even intensief? Deze opmerking werd gegeven door 3 van de 9 gebruikers.

Mogelijke oplossing:
Om een beeld te krijgen van de intensiteit van de planning kan de trainingscategorie worden weergegeven per geplande activiteit. Hierbij kan gewerkt worden met kleuren, waarbij elke kleur een andere categorie aanduidt. Op die manier krijgen gebruikers een overzicht van de geplande afstanden en de intensiteit waarmee deze afstanden dienen afgelegd te worden.

5. Inplannen van activiteiten op basis van tijd (n=3)
Probleem:
In de huidige versie van het ontwerp is het enkel mogelijk om activiteiten in te plannen op basis van afstand. 3 van de 9 gebruikers gaven als kritiek dat een afstand inplannen echter niet altijd de meest aangewezen manier is om een activiteit in te plannen. Zo worden planningen ook vaak gemaakt op basis van tijd, bijvoorbeeld drie uur fietsen i.p.v. 80 km fietsen.

Mogelijke oplossing:
In het volgende ontwerp kunnen beide opties aangeboden worden. De enige moeilijkheid dat plannen in twee eenheden met zich meebrengt, is het berekenen van de vooruitgang van de uitvoering van de planning. Deze vooruitgang dient dan berekend te worden op basis van de tijd indien er een activiteit werd ingepland in tijd en op basis van afstand indien er een activiteit werd ingepland in afstand. Het toevoegen van deze functionaliteit is echter van belang voor het ontwerp criterium van plannen van activiteiten. Dit is een belangrijk onderdeel van de applicatie.

6. Navigeren doorheen de planning (n=3)
Probleem:
3 van de 9 gebruikers gaven aan dat er geen mogelijkheid is om terug te keren naar de planning van voorgaande weken. Het is mogelijk dat triatleten een training van drie weken geleden opnieuw willen uitvoeren. Het kan dan erg handig zijn om de details van die training opnieuw te bekijken, alsook het resultaat van de training.

Mogelijke oplossing:
Navigatie doorheen de planning kan worden toegevoegd door het gebruik van navigatiepijltjes. Deze navigatietechniek werd eerder al gebruikt bij het navigeren doorheen de persoonlijke eigenschappen van de triatleet (My personal things). Tijdens de testen bleek de gebruiker geen enkel probleem te hebben met deze navigatietechniek. Het is daarom aangewezen om ook deze techniek te gebruiken voor het navigeren doorheen de planning. Dit sluit ook aan bij één van de vooropgestelde ontwerpcriteria: consistentie. Op die manier wordt namelijk steeds dezelfde weergave gebruikt voor het navigeren doorheen te tijd.

Een ander concept van het selecteren van een tijdsperiode zijn de sliders. Men zou kunnen zeggen dat er geen consistent gebruik is tussen sliders en de navigatiepijltjes. Deze twee aanpakken worden echter gebruikt voor twee aparte concepten. De navigatiepijltjes worden enkel gebruikt voor het navigeren doorheen de tijd. De tijdsperiode die de gebruiker hiermee kan selecteren, staat altijd vast (bv. een dag of een week). De sliders worden echter gebruikt om een specifieke periode te selecteren waarbinnen een cijfer dient berekend te worden. De tijdsperiode staat hier duidelijk niet vast. Voor deze twee aparte concepten worden dus twee verschillende technieken gebruikt, wat voldoet aan het ontwerpcriterium van consistentie.
navigatie

7. Terugkeren naar hoofdscherm vanuit een subscherm (n=6)
personalthings
Probleem:
Naast de titel van een scherm worden soms enkele knopjes weergegeven die gebruikt kunnen worden om te interageren met het scherm (bijvoorbeeld een grafiek opvragen van de weergegeven informatie). Voor 6 van de 9 gebruikers was het niet duidelijk hoe er kon worden teruggekeerd naar de initiële weergave. Dit kan worden verwezenlijkt door op het vakje naast de grafiek te klikken.

Mogelijke oplossing:
De knopjes die gebruikt kunnen worden voor een andere weergave op te vragen, fungeren eigenlijk als tabbladen. Wanneer en tabblad actief is, dan zou dit worden aangegeven met een kleur. Dit is echter moeilijk te realiseren met een papieren versie van de applicatie. Daarom is het niet zeker dat dit probleem zich ook zou voordoen bij een digitale versie. Langs de andere kant bevat het linkse vakje geen symbool dat zou kunnen wijzen op de weergave van het initiële scherm. Hiervoor werd bij het maken van het prototype geen gepast symbool gevonden. In dit geval kan het knopje echter een kleine weergave tonen van wat er in de kader wordt weergegeven, namelijk vier kleine icoontjes. Dit heeft als nadeel dat voor elke kader het knopje om terug te gaan naar het initiële scherm er anders uitziet, waardoor de consistentie verloren gaat (cfr. ontwerp criteria).

Een andere oplossing is om te werken met één symbool. Wanneer het initiële scherm wordt getoond, zou enkel het symbool van de grafiek worden getoond. Indien de gebruiker klikt op het symbool van de grafiek, zou het veranderen in een symbool waarop een links-georiënteerde pijl wordt getoond. Deze pijl drukt dan uit om terug te gaan naar de vorige weergave. Een moeilijkheid met deze techniek komt tot uiting wanneer er meer dan één interactiesymbool is. Dit kan echter worden opgelost door alle interactiesymbolen (behalve de pijl) te verbergen wanneer een bepaald subscherm actief is.

8. Vergelijken met de gemiddelde triatleet van de applicatie (n=5; enkel van toepassing op 7 triatleten)
intensity
Probleem:
6 van de 7 ondervraagde triatleten gaven aan dat de vergelijking met andere triatleten wel interessant kan zijn. 5 van deze triatleten gaven echter aan dat de huidige vergelijking (namelijk met het gemiddelde van alle gebruikers in de applicatie) verfijnd dient te worden. Deze personen wilden zich meten met vergelijkbare triatleten en niet met alle triatleten uit de applicatie.

Mogelijke oplossing:
Triatleten worden tijdens wedstrijden onderverdeeld in categorieën. Dit wordt gedaan op basis van geslacht en leeftijd. Het is bijvoorbeeld voor een vrouw nuttiger om zich te vergelijken met andere vrouwen, en niet met mannen. Ook voor 40-plussers is het meer aangewezen om zich te vergelijken binnen de categorie van triatleten die ouder zijn dan 40 jaar. Opdelen van gebruikers in dergelijke categorieën is reeds mogelijk omdat in de profielpagina de geboortedatum en het geslacht wordt opgevraagd. Verder is er ook de mogelijkheid om de gebruikers in te delen in categorieën die gebaseerd zijn op niveau. Dit kan door de tijden te interpreteren die gebruikers toevoegen in een activiteit. Op die manier kunnen gebruikers zich niet alleen vergelijken binnen de leeftijdscategorie, maar ook binnen de categorie van niveau.

9. Schatten van toename in conditie (n=6; enkel van toepassing op 7 triatleten)
fitness
Probleem:
Verschillende triatleten (6 van de 7) uitten de kritiek dat het concept van het vergelijken van gemiddelde snelheden niet de juiste manier is om de vooruitgang in conditie te schatten. Dit komt omdat triatleten niet altijd met dezelfde intensiteit trainen in elke week. Een trainingsschema dat toeleeft naar een bepaalde wedstrijd bestaat vaak uit opbouwweken en rustweken. In de opbouwweken wordt er intensief getraind, waardoor er zeker een week nodig is waarin de atleet minder hard traint. De rustweken hebben als doel om overbelasting tegen te gaan. Door het bestaan van rustweken zal deze kader eerder weergeven dat de conditie in dergelijke weken achteruit gaat, wat niet correct is. Het is dus beter om op een ander concept te baseren dan het verloop van de gemiddelde snelheden.

Mogelijke oplossing:
Een mogelijkheid om de toename in conditie te schatten is de running index (ook gebruikt in de Polar Beat applicatie), waarbij atleten wekelijks of maandelijks voor elke sport een test afnemen. Deze mogelijkheid werd voorgesteld door drie triatleten (n=3). Een voorbeeld is om 10 km te lopen in een zo kort mogelijke tijd. Door de tijden van deze testen met elkaar te vergelijken, krijgt de atleet een beter zicht op het al dan niet boeken van vooruitgang. Omdat dit concept beter het doel van deze kader invult, zal dit concept de huidige invulling vervangen. Daardoor zal ook het ontwerp criterium van het bekijken van de evolutie (bijvoorbeeld in conditie) beter worden uitgewerkt.

10. Link tussen ‘My activities’ en planning (n=3)
activities
Probleem:
3 gebruikers hadden verwacht dat wanneer een activiteit uit de planning werd geselecteerd, de details van deze activiteit zouden verschijnen in de kader ‘My activities’.

Mogelijke oplossing:
Omdat alle activiteiten bereikbaar zijn vanuit de planning, is deze opmerking zeer terecht. Deze kader wordt dan sterk gerelateerd aan de interactie met de planning, waardoor deze kader voortaan naast de planning zal komen te staan. Door deze aanpassing heeft de gebruiker een heel snel zicht op alle details van de geselecteerde activiteit in de planning.

11. Geen motivatie door doelen en badges (n=5; enkel van toepassing op 7 triatleten)
goals
Probleem:
Slechts 2 van de 7 triatleten gaven aan dat het vooropstellen van doelen en het behalen van badges hen zou interesseren en misschien zelfs motiveren. De andere atleten gaven te kennen dat dergelijke elementen geen aandacht zouden krijgen.

Mogelijke oplossing:
Omdat triatleten behoren tot het uiteindelijke doelpubliek, telt enkel hun mening als het over de inhoud van de applicatie gaat. Daarom zal het concept van doelen en badges herbekeken moeten worden. Een andere mogelijkheid is om het concept weg te laten uit het dashboard. Het kan echter wel dat doelen en badges wel motiverend ondervonden worden wanneer de triatleten dit voor een bepaalde tijdsperiode gebruiken. Dit concept is namelijk nog niet erg bekend bij triatleten, waardoor de kans op het geven van een negatief antwoord op de vraag groter is.

Doelen en badges is echter wel een ontwerp criterium dat bij het ontwerpen van dit dashboard werd vooropgesteld. Daarom kan er voor gekozen worden om dit concept achter de hand te houden. Wanneer in de digitale versie van de applicatie weinig activiteiten worden ingegeven, kan dit concept eventueel gebruikt worden om triatleten te motiveren om de activiteiten te blijven ingeven.

12. Het vergelijken van wedstrijden (n=5; enkel van toepassing op 7 triatleten)
Probleem:
Verschillende wedstrijden met elkaar vergelijken is volgens 5 van de 7 triatleten moeilijk en niet altijd correct. In elke wedstrijd spelen er andere omstandigheden, waardoor de vergelijking niet altijd kan. Het toevoegen van de weersomstandigheden is niet voldoende omdat sommige parcours volledig vlak zijn en andere parcours hellingen bevatten. Daarnaast is de effectieve afstand die moet worden afgelegd in een wedstrijd niet altijd hetzelfde, ookal hebben de wedstrijden hetzelfde formaat. Het is vaak zo dat er 200 meter meer gezwommen moet worden dan in een andere wedstrijd. Deze afwijking in afstand geldt ook voor de andere disciplines.

Mogelijke oplossing:
Door de differentiatie in omstandigheden en afstanden in wedstrijden, is het vergelijken van wedstrijden heel moeilijk. Een andere mogelijkheid om toch wedstrijden te vergelijken, is het vergelijken van dezelfde wedstrijd door de jaren heen. Dit is makkelijker omdat het parcours meestal hetzelfde blijft, enkel de weersomstandigheden kunnen van jaar tot jaar variëren. Deze mogelijkheid is enkel van toepassing wanneer de atleet meermaals dezelfde wedstrijd aflegt. Dit is niet altijd even evident.

13. De minst interessante of nuttige kader (enkel van toepassing op 7 triatleten)
Aan de triatleten werd de volgende vraag gesteld: “Als je één van de kaders zou moeten weglaten, voor welke kader zou je dan kiezen?“. De volgende antwoorden werden op deze vraag geformuleerd:
– (n=5): My physical fitness (de huidige invulling)
– (n=1): My races compared/summarised
– (n=1): My training intensity

Conclusie:
4 van de 5 triatleten die kozen voor ‘My physical fitness’ stelden echter een nieuwe invulling voor om de toename in conditie te schatten (zoals eerder besproken). Er werd echter niet gevraagd welke kader ze zouden kiezen indien de nieuwe invulling van ‘My physical fitness’ van kracht zou zijn. Daarom is het moeilijk om uit dit resultaat een conclusie te trekken.

14. De vier belangrijkste kaders (enkel van toepassing op 7 triatleten)
Aan de triatleten werd de volgende vraag gesteld: “Als je slechts vier kaders mag behouden, welke zou je dan kiezen?“. De volgende antwoorden werden op deze vraag geformuleerd:
(n=1): My planning & progress, My personal things, My training intensity, Races in één kader
(n=1): My planning & progress, My personal things, My activities, My races summarised
(n=1): My planning & progress, My personal things, My training intensity, My activities
(n=1): My planning & progress, My goals, My training intensity, My races compared
(n=1): My planning & progress, My training intensity, My activities, Races in één kader
(n=1): My planning & progress, My personal things, My training intensity, My races summarised
(n=1): My planning & progress, My personal things, My physical fitness, My activities

7: My planning & progress
5: My training intensity
5: My personal things
4: My activities
2: Races in één kader
2: My races summarised
1: My races compared
1: My goals
1: My physical fitness

Conclusie:
Eén van de doelen van deze test was om minder informatie op het scherm te tonen. Deze vraag helpt daarbij, namelijk om te weten te komen welke concepten er uit het ontwerp kunnen weggelaten worden. Het is duidelijk dat ‘My planning & progress’ de belangrijkste kader vormt van de applicatie (elke triatleet wil deze graag behouden). Daarnaast zijn er nog drie kaders die de triatleten graag in de applicatie willen zien: ‘My training intensity’ (5/7), ‘My personal things’ (5/7) en ‘My activities’ (4/7). Het vergelijken van wedstrijden komt in mindere mate aan bod, mede door de opmerkingen die hieromtrent al werden geformuleerd. ‘My goals’ (1/7) wordt helemaal niet nuttig bevonden door de triatleten. Ook van ‘My physical fitness’ (1/7) kan hetzelfde gezegd worden, maar ook hier werd deze kader beoordeeld op de huidige invulling. Vermits vier triatleten het idee aangaven om het concept van het vergelijken van testen te gebruiken, is het waarschijnlijk dat deze kader toch een betere score zou krijgen indien de nieuwe invulling van kracht is.

Met de moeilijkheden omtrent het vergelijken van wedstrijden in het achterhoofd en de slechte score die ‘My goals’ krijgt, zal er voor gekozen worden om deze twee concepten voorlopig weg te laten uit de applicatie. Hier kan op een later tijdstip eventueel op worden teruggekomen. Omdat het gebruik van badges nieuw is voor triatleten, is het voor hen ook moeilijk om in te schatten of het een motiverende toets kan geven.

15. Plaatsing van informatie
Aan de triatleten werd de volgende vraag gesteld: “Vind je de plaatsing van de informatie goed? Vind je het belangrijk dat je zelf kan kiezen waar welke informatie wordt weergegeven?“. De volgende antwoorden werden op deze vraag geformuleerd:
– (n=9): Indeling is goed: planning moet zeker bovenaan staan.
– (n=6): Zelf kiezen zou wel nuttig zijn, omdat iedereen andere informatie belangrijk acht.

Conclusie:
Alle ondervraagden waren grotendeels akkoord met de indeling van de informatie in het ontwerp. Iedereen was het er over eens dat de planning helemaal bovenaan moet staan. Afhankelijk van de kaders die een persoon belangrijk acht, zou de indeling kunnen worden aangepast. 6 van de 9 personen gaven dan ook aan dat het dynamisch wisselen van kaders een meerwaarde kan bieden. Door deze resultaten kan er overwogen worden om het dynamisch wisselen van kaders aan te bieden. Dit heeft echter ook te maken met het ontwerp criterium van aanpasbaarheid. Op die manier kan elke gebruiker de beste positie kiezen waar bepaalde informatie moet worden weergegeven. Dit bevordert het vinden van eventuele inzichten waarnaar de gebruiker op zoek is.

16. Algemene opmerkingen van de ondervraagden
Aan de triatleten werd de volgende vraag gesteld: “Zijn er algemene opmerkingen, dingen die ontbreken of die je graag aangepast ziet?“. De volgende opmerkingen werden op deze vraag geformuleerd:
– (n=7): Het is een beetje te druk. Misschien moet er een selectie gemaakt worden van concepten die de applicatie zeker moet bevatten. De overige concepten zouden dan beter worden weggelaten.
-(n=2): Momenteel is het enkel mogelijk om activiteiten voor het zwemmen, fietsen en lopen toe te voegen. Triatleten doen ook andere activiteiten zoals duathlon, mountainbike, stabilisatie oefeningen, fitness, veldloop, …
-(n=3): Een evolutie van de totale tijden per sport per week binnen een bepaalde periode kunnen bekijken. Op die manier is het mogelijk om te zien of een bepaalde sport al dan niet verwaarloosd wordt.

Conclusie:
De eerste opmerking werd ook tijdens de presentatie van mijn thesis gemaakt. Daarom is de opmerking die zeven van de negen ondervraagden maakten ook heel terecht. Eén van de doelen van deze test was dan ook om dit probleem op te lossen. Bij de analyse van de vraag omtrent de vier belangrijkste kaders werd reeds de conclusie gevormd om het concept van wedstrijden met elkaar te vergelijken achter wegen te laten. Ook het vooropstellen van doelen en het verdienen van badges zal worden weggelaten uit het ontwerp. Het achterwege laten van deze concepten heeft als doel om het dashboard te ontlasten van drukte.

De tweede opmerking gaat omtrent het uitbreiden van de mogelijke activiteiten die in de applicatie kunnen worden toegevoegd. Door echter te focussen op de drie basisdisciplines van triatlon, zal mijn applicatie zich onderscheiden van andere bestaande webapplicaties. Deze voorzien namelijk heel veel sporten, waardoor er geen onderscheid wordt gemaakt in de informatie die over deze verschillende sportactiviteiten wordt opgevraagd (zie literatuurstudie). Het is de bedoeling om de informatie die wordt opgevraagd in de drie disciplines gedetailleerd uit te werken. Indien dit succesvol is afgerond, kan er eventueel aan worden gedacht een uitbreiding te maken van het assortiment van sporten dat wordt aangeboden. Eén van de ontwerp criteria is simplisme. Door dergelijke functionaliteit toe te voegen, zal de applicatie ook voor een deel complexer worden.

De derde opmerking gaat eigenlijk over het bekijken van de evolutie in de effectief afgelegde afstanden van de planning, meer bepaald de tijd die hier voor nodig was. Er is dus de mogelijkheid om ook bij de planning een grafiek-knopje toe te voegen die deze evolutie kan tonen binnen een bepaalde periode. Deze periode kan aangeduid worden m.b.v. een slider, zoals reeds andere kaders in het ontwerp van een dergelijke slider gebruik maken. Het hergebruiken van deze slider en het grafiek-knopje sluit aan bij het ontwerp criterium van consistentie.

17. SUS questionnaire
Om de usability van het ontwerp te testen, werd aan het einde van het gesprek een SUS questionnaire [1] ingevuld door de persoon in kwestie. Deze bestaat uit 10 vragen die de effectiviteit, efficiëntie en voldoening van het ontwerp aankaarten. In [1] wordt besproken hoe men tot deze vragenlijst is gekomen, alsook hoe een SUS-score geïnterpreteerd dient te worden. Hiervoor werden meer dan 5000 applicaties geëvalueerd en het resultaat van de SUS-score werd steeds berekend [2]. De geschatte verdeling van de SUS-scores is terug te vinden in onderstaande figuur.

Screen Shot 2013-12-13 at 09.13.26
Deze figuur toont aan dat een SUS-score van 80 of minder behaald werd door 90% van de evaluaties. Daardoor scoort slechts 10% van de evaluaties beter dan 80. Uit deze figuur wordt ook duidelijk dat de SUS-score niet hetzelfde is als een percentage. Het is duidelijk dat een SUS-score van 50 niet door 50% van de testen werd behaald, maar dat slechts 13% van de testen deze score behalen. Een SUS-score van 68 wordt wel behaald door ongeveer 50% van de testen. Daarom kan een SUS-score van 68 bekeken worden als een SUS-score van gemiddeld niveau. Indien de SUS-score hoger is dan 68, dan is dit beter dan gemiddeld, in het andere geval is het slechter dan gemiddeld.

Bangor et al. [2] stellen een schaal voor dat een bepaalde SUS-score omzet naar een rang (bv. slecht, ok, goed, enz.). Dit wordt weergegeven in onderstaande figuur. M.b.v. deze figuur en de vorige figuur kan er een interpretatie van de SUS-score gevormd worden.

Screen Shot 2013-12-13 at 09.27.58
Een boxplot van de SUS-scores van het ontwerp wordt getoond in onderstaande figuur.

susscore

De gemiddelde SUS-score is 83,6 (met de uitschieter van 65 inbegrepen). Deze score zou zich bij de 10% beste evaluaties bevinden die in [1] werden getest. Daarnaast ligt deze score tussen goed (‘good’) en uitstekend (‘excellent’), waarbij deze veel dichter tegen uitstekend ligt. De uitschieter van 65 betreft een persoon die geen smartphone in het bezit had. In het ontwerp komen er een aantal symbolen terug die op een smartphone worden gebruikt. Dit kan één van de oorzaken zijn waarom het systeem een lagere SUS-score kreeg.

Er kan geconcludeerd worden dat dit een bijna uitstekende SUS-score is. Dit geeft een indicatie dat er geen grote usability problemen met het ontwerp zijn.

7) Algemene conclusie
De meeste problemen die werden besproken, hebben te maken met de inhoud van de applicatie. Doorheen de tekst zijn al een aantal oplossingen aangehaald om deze inhoudsproblemen op te lossen. Deze oplossingen zullen verwerkt worden in een tweede papieren prototype. Daarnaast zien we ook dat de gemiddelde SUS-score vrij hoog ligt. Daarom kunnen we er vanuit gaan dat er geen grote problemen zijn met de usability van het design. Dit wil echter niet zeggen dat de usability van het volgende prototype ook hoog zal liggen. Door het aanpassen van de problemen kunnen er nieuwe problemen optreden, waardoor de SUS-score lager kan liggen. Daarom zal het volgende prototype opnieuw getest worden op usability. Omdat er een deel van de inhoud zal worden weggelaten uit het dashboard, is het ook aangeraden om opnieuw te testen op de inhoud van het volgende ontwerp.

Het grootste doel van deze evaluaties, namelijk om minder belangrijke concepten uit het dashboard te identificeren, is bereikt. Met deze informatie zal er getracht worden om het volgende ontwerp te ontdoen van de drukte.

Referenties
[1] Sauro, J. (2011). A practical guide to the System Usability Scale: Background, benchmarks, & best practices. Denver, CO: Measuring Usability LLC.
[2] Bangor, A., Kortum, P. T., & Miller, J. T. (2009). Determining what individual SUS scores mean: Adding an adjective rating scale. Journal of Usability Studies, 4(3), 114-123.

Advertenties

3 gedachtes over “PP1: Resultaten & conclusies

  1. Pingback: PP2: Design | Quantified Self
  2. Pingback: PP2: Resultaten & conclusies | Quantified Self
  3. Pingback: DP1: Doel en methode | Quantified Self

Geef een reactie

Vul je gegevens in of klik op een icoon om in te loggen.

WordPress.com logo

Je reageert onder je WordPress.com account. Log uit / Bijwerken )

Twitter-afbeelding

Je reageert onder je Twitter account. Log uit / Bijwerken )

Facebook foto

Je reageert onder je Facebook account. Log uit / Bijwerken )

Google+ photo

Je reageert onder je Google+ account. Log uit / Bijwerken )

Verbinden met %s