Opstellen van ontwerpcriteria

Ik heb ondertussen mijn nieuwe papieren prototype afgewerkt en maak alles klaar om eindelijk gericht te kunnen gaan testen met de toekomstige gebruikers van mijn applicatie. Om gericht te kunnen testen, kan het heel nuttig zijn om op voorhand een aantal criteria op te stellen die belangrijk zijn voor de applicatie. Aan de hand van deze criteria kan ik dan gepaste testen uitvoeren om na te gaan of aan deze criteria wordt voldaan. Op die manier kunnen problemen in het papieren prototype naar voor komen die niet aan bepaalde criteria voldoen. Het is dan de bedoeling om deze problemen aan te pakken in een tweede papieren prototype. Hieronder volgt een bespreking van de ontwerpcriteria die ik zal hanteren.

1) Data captatie
Deze thesis handelt over Quantified Self, waardoor het verzamelen van data een heel belangrijk aspect is. Het loggen van data moet gemakkelijk zijn, zodat gebruikers gemotiveerd blijven om hun activiteiten toe te voegen. De applicatie zal de data tijdens de activiteit echter niet automatisch kunnen opslaan, vermits ik een dashboard zal ontwerpen voor de computer en deze niet handig zijn om mee te nemen tijdens het sporten. Maar op welke manier kunnen gebruikers toch blijven gemotiveerd worden om hun activiteiten op te slaan?

Een mogelijke uitbreiding zou kunnen zijn om een bijhorende mobiele applicatie te ontwikkelen. Deze applicatie zou dan in contact staan met een server waarvan het dashboard de informatie ophaalt. Na het vergelijken van verschillende mobiele applicaties werd echter duidelijk dat er reeds heel veel goede applicaties bestaan die informatie tijdens de training opslaan (bv. RunKeeper, Polar Beat, Strava Ride, etc.). Dit is één van de redenen waarom ik ervoor kies om niet in concurrentie te treden met dergelijke applicaties en mij te concentreren op een dashboard die deze resultaten in een zinvolle manier probeert weer te geven.

Triatleten maken vaak gebruik van andere toestellen, zoals een GPS of een sporthorloge, om data over hun activiteiten op te slaan. Dit is een aspect waar mijn dashboard wel een vorm van automatische logging kan aanbieden. Dergelijke toestellen genereren namelijk een bestand met alle opgeslagen informatie over de activiteit. Aanbieden van automatische logging, bijvoorbeeld door de mogelijkheid te geven dit bestand in te laden in het dashboard, verlaagt de inspanning die nodig is om een activiteit na de training op te slaan in het dashboard. Indien gebruikers echter niet beschikken over dergelijke toestellen, dan kunnen zij hun activiteit ook manueel toevoegen. Het manueel opslaan van een activiteit zal echter een grotere inspanning vragen. Deze inspanning kan verlaagd worden door enkel de belangrijkste informatie op te vragen en ook door automatisch waarden aan te vullen die berekend kunnen worden op basis van eerder ingevulde waarden.

Omdat dit een belangrijk element is van het dashboard, moet deze functionaliteit vanuit elke positie in het dashboard beschikbaar zijn. Op die manier kunnen gebruikers steeds een nieuwe activiteit toevoegen. Waar gebruikers een activiteit kunnen toevoegen moet dus vrijwel onmiddellijk terug te vinden zijn. Ook het toevoegen van dagelijkse persoonlijke eigenschappen (zoals ochtendpols, aantal uren slaap, etc.) moet gemakkelijk en duidelijk zijn. De effectiviteit hiervan kan getest worden door testgebruikers specifieke gerelateerde opdrachten te laten uitvoeren. Een goede plaats om de belangrijkste informatie te tonen is een plaats waar de aandacht van de gebruiker op valt. Deze aandacht valt meestal in de linkerbovenhoek en in het midden [1]. Dit is ook te zien in onderstaande afbeelding. Het is daarom een goede keuze om het toevoegen van een activiteit in dergelijke zones te plaatsen.

Screen Shot 2013-12-03 at 10.17.36

2) Simpliciteit en Consistentie
Omdat een dashboard heel veel informatie probeert weer te geven, dient het een simplistisch ontwerp te hebben. Een dergelijk ontwerp geeft de informatie op een heel simpele en duidelijke manier weer, zodat gebruikers niet overweldigd worden door de informatie die ze te zien krijgen. Dit is een grote uitdaging [1].

Een aanpak zou kunnen zijn om slechts heel weinig informatie weer te geven. Er kan meer informatie getoond worden door op bepaalde icoontjes te klikken. Dit heeft als voordeel dat het initiële dashboard er heel simpel zal uitzien. Het aantal clicks die nodig zijn om de gewenste details te vinden zal echter hoog liggen, vermits niet altijd duidelijk zal zijn waar die details kunnen worden teruggevonden. Een andere aanpak is om alles te tonen op één scherm. Op die manier worden alle details meteen getoond, waardoor heel veel informatie onmiddellijk beschikbaar wordt. Het voordeel is dat het aantal clicks die nodig zijn om meer details te tonen zal verlagen, maar het dashboard zal er veel minder simplistisch uitzien. Het is de bedoeling om een evenwicht te vinden tussen beide aanpakken, zodat de voordelen kunnen worden gecombineerd.

S. Few [1] geeft aan dat enkel de informatie die noodzakelijk is om op een bepaalde vraag te antwoorden, mag worden weergegeven op het dashboard. Het is geen goed idee om alle concepten waar aan gedacht kan worden meteen op het dashboard af te beelden. In een dashboard is het belangrijkste element inzicht. Dit moet worden bereikt het enkel tonen van de informatie die hiertoe nodig is.

Het interactief maken van het dashboard kan helpen voor het weergeven van meer getailleerde informatie, wat de simpliciteit van het dashboard ten goede komt. Ook het correct gebruiken van kleuren speelt een belangrijke rol [1]. Door steeds te werken met dezelfde kleuren zal het dashboard een rustigere indruk krijgen. Vaak is het gebruik van minder opvallende kleuren een goede manier om rust te brengen. Informatie waarop de nadruk gelegd dient te worden, kan een hevigere kleur aan toegekend worden. Het gebruik van icoontjes brengt ook bij tot simpliciteit [1]. Een icoontje heeft vaak minder plaats nodig dan wanneer het equivalent er van in tekst zou worden weergegeven. Dit bespaart ruimte die anders onnodig verloren zou gaan. Om na te gaan of het ontwerp simplistisch is, kunnen een aantal taken worden uitgevoerd door testgebruikers. Indien deze taken vlot verlopen, geeft dit een indicatie van simpliciteit.

Consistentie kan ook bijdragen tot simpliciteit. Door het consistent gebruiken van kleuren en vormen wordt het ontwerp meer simplistisch. Ook het consistent herhalen van bepaalde gebruikte concepten in het dashboard is heel belangrijk. Op die manier raken gebruikers meer vertrouwd met deze concepten en krijgt het dashboard een duidelijkere structuur.

Het testen van consistentie en simpliciteit kan worden gedaan aan de hand van een SUS questionnaire. Om de informatie die wordt weergegeven te beperken tot het meest essentiële, kan er bijvoorbeeld de volgende vraag worden gesteld: Als u één van de concepten uit het dashboard zou moeten verwijderen, voor welk concept kiest u dan?” Indien blijkt dat hier vaak het zelfde concept wordt aangehaald, dan kan er misschien worden overwogen om dat concept ook effectief uit het initiële dashboard te verwijderen.

3) Interactiviteit en Aanpasbaarheid
Eén van de dingen die een simplistisch ontwerp kan uitbreiden met aanvullende details is interactiviteit. Hierbij kan de gebruiker meer details van een bepaald aspect verkrijgen door bijvoorbeeld met de muis over een bepaalde knop te glijden. Hierdoor wordt er plaats bespaard in het dashboard, waardoor het aantal weergegeven informatie op het initiële dashboard kleiner wordt. Dergelijke vormen van interactiviteit kunnen worden getest door specifieke opdrachten te formuleren waarbij testgebruikers op zoek moeten gaan naar meer details over een bepaald concept. Deze details zijn dan meestal beschikbaar door te interageren met een bepaald icoontje.

Het ontwerp van een dashboard is niet voor iedereen optimaal. Zo vinden gebruikers andere concepten belangrijker om eerst weer te geven, of willen ze bepaalde resultaten over een andere tijdsperiode zien. Om aan deze eis te voldoen, kan er de mogelijkheid worden gegeven om aanpassingen aan te brengen op het dashboard. Een mogelijke manier om te testen welke concepten de gebruikers wensen te kunnen manipuleren, is door het hen rechtstreeks te vragen. Een voorbeeld hiervan zou kunnen zijn: “Vindt u de plaatsing van de informatie goed? Vindt u het belangrijk dat u zelf kan kiezen waar welke informatie wordt weergegeven?”. Op deze laatste vraag zou S. Few [1] negatief antwoorden. Daarin wordt beweerd dat de plaats waar informatie wordt weergegeven statisch moet zijn. De reden hiervoor is dat de ontwikkelaar zelf kan beslissen welke informatie belangrijk is en aan de hand daarvan de plaats kan kiezen waar de informatie zal geplaatst worden.

4) Plannen van activiteiten
Een belangrijk onderdeel van mijn applicatie is het plannen van activiteiten in de toekomst. Meer bepaald het inplannen van de komende week. Op die manier geeft de gebruiker aan wanneer hij/zij welke activiteiten zal uitoefenen tijdens die week. Het is dan de bedoeling om gebruikers te motiveren om deze planning te volbrengen. Dit kan gerealiseerd worden door de vooruitgang in de huidige week te tonen: ben ik nog op schema? Hoeveel heb ik nog te gaan? Het kan ook nuttig zijn om de intensiteit van de huidige week te tonen. Op die manier kunnen gebruikers nagaan of ze een intensieve week beleven en misschien aan een dag rust toe zijn.

Hierbij moet het duidelijk zijn dat de visualisatie van de vooruitgang en de planning van elkaar afhangen. Het is ook enorm belangrijk dat het voor de gebruikers duidelijk is hoe ze activiteiten moeten inplannen. Ook hier kan dit getest worden door specifieke opdrachten te geven. Er kan echter ook gebruik gemaakt worden van het think-aloud principe. Hierbij moeten testgebruikers uitleggen wat ze zien in een bepaald scherm, zodat de ontwerper kan nagaan of de intentie van het scherm correct wordt overgebracht.

5) Evolutie bekijken
Bij het bekijken van de resultaten van de enquête bleek dat triatleten het belangrijk vinden om hun vooruitgang in een bepaald onderdeel te bekijken. Een voorbeeld hiervan is: “Hoe goed was mijn conditie op hetzelfde moment vorig jaar? Ben ik nu beter?”. Daarom wordt dit concept opgenomen in het ontwerp van mijn dashboard. Het is dus van belang om de informatie weer te geven die gerelateerd is aan de conditie van een triatleet. Daarbij moet deze informatie vergeleken kunnen worden over verschillende tijdsperioden. Op die manier kan een eventuele vooruitgang worden geconstateerd. Deze informatie kan gebruikers prikkelen om nog harder te gaan trainen.

Er kan gevraagd worden aan testgebruikers of de informatie die in het dashboard over de conditie wordt getoond, wel degelijk representatief is om een conclusie te trekken over de conditie. Daarbij moet ook duidelijk worden of de gebruikte visualisaties voor de evolutie nuttig zijn en een duidelijke indicatie van de evolutie geven. Hierbij kan voornamelijk het think-aloud principe worden gebruikt, zodat testgebruikers feedback kunnen geven op de huidige representatie.

Een ander aspect is het vergelijken van deze eigenschappen met andere triatleten. Er moet een antwoord gevonden worden op o.a. de volgende vragen: “Ben ik een goede triatleet? Wat zijn cijfers van andere triatleten? Scoren zij beter dan mij?”. Een mogelijke vraag voor de testgebruikers zou kunnen zijn om na te gaan of ze beter scoren dan andere triatleten. Ook de vraag of het hen meer motiveert, of ze er belang aan hechten, kan worden gesteld.

6) Doelen en Badges
Doelen en badges zijn een manier om gebruikers meer te motiveren om bepaalde activiteiten uit te voeren. Zij kunnen ook in mijn dashboard van toepassing zijn. Een doel zou kunnen zijn om een bepaalde afstand af te leggen in een bepaalde discipline, bijvoorbeeld 10 000 km zwemmen. Motiveert dit soort doelen om triatleten meer te laten trainen? Daarnaast kan een voorbeeld van een badge zijn om de hoogte van de Mount Everest te zwemmen. Brengt die ook meer motivatie met zich mee, of wordt het enkel beschouwd als een weetje waar niet veel belang aan wordt gehecht? Het think-aloud principe kan worden toegepast om meer inzicht te krijgen in de emotie van de triatleet omtrent het opstellen van doelen en het behalen van badges.

Referenties
[1] Few, S. (2006). Information dashboard design.

Future work
Het nieuwe papieren prototype is volledig uitgetekend en de ontwerpcriteria werden opgesteld. Het is nu de bedoeling om concrete testen op te zetten die met testgebruikers kunnen worden afgelegd. Hierbij ga ik vooral op zoek naar gebruikers uit mijn doelpubliek, namelijk triatleten. Het lijkt mij echter nuttig om ook andere personen die een sport beoefenen te betrekken. Deze personen kunnen ook nuttige feedback leveren op bepaalde ontwerp-zaken. Maar de focus ligt natuurlijk op triatleten.

Ik probeer momenteel in contact te raken met het universitaire triatlon team. Ik krijg hiervan echter weinig reactie. Een andere mogelijkheid is om opnieuw aan te kloppen bij de plaatselijke triatlonclub in Mechelen. Ik vraag mij echter af of het een goede strategie is om ook de volgende prototypes te testen binnen diezelfde club, of is het beter om telkens nieuwe mensen te zoeken bij elke iteratie?

Advertenties

2 gedachtes over “Opstellen van ontwerpcriteria

  1. Pingback: PP1: Doel en methode | Quantified Self
  2. Pingback: PP2: 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