Prototyping is bij de ontwikkeling van software, websites en apps inmiddels volledig ingeburgerd. Het is dé manier om ervoor te zorgen dat gebruikers betrokken worden bij het ontwerp van het product en er alvast mee werken, voordat je aan het bouwen slaat. Dan is het toch vreemd dat organisaties prototyping bij de ontwikkeling van hun dashboards vaak vergeten. Daarmee lopen ze het risico dat het niet aansluit bij de wensen van de gebruikers of dat ze de getoonde data verkeerd interpreteren. Tijd dus voor een nieuwe generatie dashboards!
Eerder vertelde ik hoe je in vijf stappen perfecte dashboards ontwikkelt die gebruikt worden en impact hebben op je organisatie. Daarin benadrukte ik al de noodzaak van prototyping. Met een schets van de indeling van een dashboard lok je feedback uit. Gebruikers praten erover en dat levert input op om snel met een verbeterde schets te komen. Zo kom je razendsnel tot een goede basis. Naar aanleiding van die visie kreeg ik herhaaldelijk het verzoek om meer uitleg te geven over het belang van prototyping bij dashboarding. Bij deze…
Mijn ideeën over het ontwerpen van dashboards ontwikkelde ik toen ik de wereld van business intelligence instapte. Daarvoor lag mijn expertise bij gebruikersonderzoek, usability testing, prototyping en interactie-ontwerp. Dankzij die kennis kijk ik naar een dashboard alsof het een applicatie is die de gebruiker ondersteunt in zijn werk. Het is daarbij belangrijk om rekening te houden met hoeveel de gebruikers begrijpen van de data die je toont. Daar kun je een ruwe inschatting van maken en hopen dat het klopt. Of je zorgt in een vroegtijdig stadium dat gebruikers aanhaken en je van de broodnodige feedback voorzien. Dat is de belangrijkste reden om prototyping bij dashboarding in je proces op te nemen.
Vijf redenen waarom dashboard prototyping essentieel is
Je wil met prototyping dus op tijd ontdekken of er een mismatch is tussen het ontwerp en de doelen van je gebruikers. Tenslotte wil je dat de eindgebruiker het dashboard inzet voor zijn werkzaamheden en nieuwe inzichten opdoet om betere beslissingen te nemen. Maar er zijn ook andere redenen om vroeg in het ontwikkeltraject gebruikers te betrekken. Ik zet er vijf op een rij:
1. Nadenken en nieuwe vragen stellen
Prototyping zet gebruikers aan het denken. Wat vinden ze belangrijk? Hoe kan het dashboard hun werkzaamheden ondersteunen? Ze zien hoe het dashboard eruitziet en komen daardoor vanzelf met vragen over vervolgschermen, verdieping of context die jou weer helpt bij de volgende schets. Deins ook niet terug voor nieuwe vragen. Die input zorgt er uiteindelijk voor dat het definitieve dashboard omarmt wordt door alle gebruikers.
2. Inhoud is (voor nu) niet belangrijk
Prototyping voorkomt dat bij de ontwikkeling van het dashboard de nadruk komt te liggen op de inhoud. Bij een prototype met echte data zijn gebruikers geneigd feedback te geven op dat ene cijfertje, terwijl dat niet is waar het in deze fase om gaat. Daarom laten we de inhoud weg bij prototyping en focussen ons op functionaliteit en bruikbaarheid.
3. Geen grafische vormgeving
Bij een prototype gaat het niet om de juiste kleur of het perfecte ontwerp. Prototypes moeten de discussie aanwakkeren over de structuur en opbouw van het dashboard. Dat neemt niet weg dat een prototype visueel is en dat het de gebruikers mag prikkelen.
4. Snelle iteratie
Een prototype kan snel ontwikkeld en aangepast worden. Voldoet het niet aan de eisen, dan gooien we het weg en starten we opnieuw. Door deze flexibiliteit ontstaat er een proces waarin feedback snel verwerkt wordt. Met iedere nieuwe schets kom je een stap dichter bij het definitieve ontwerp. Met prototyping gebruik je dus de kracht van herhaling in combinatie met snelle schetsen.
5. Verandering van werkwijze in gang zetten
Dashboards veranderen de manier van werken van gebruikers. Dat proces mag je niet onderschatten. Gebruikers hebben tijd nodig om te wennen aan die nieuwe werkwijze. Voor eindgebruikers valt het bovendien niet mee om zich voor te stellen welke interactie mogelijk is op een dashboard of hoe je informatie handig weergeeft. Door gebruikers vroeg te betrekken bij de ontwikkeling van het dashboard, zet je de knop op tijd bij ze om. Je zorgt ervoor dat gebruikers bij de definitieve oplevering van het dashboard direct waarde kunnen halen uit de nieuwe tool.
Hoe ga je van start met dashboard prototyping?
Heb ik je al overtuigd dat prototyping bittere noodzaak is bij het ontwikkelen van dashboards? Mooi, dan leg ik je graag uit hoe je dat het beste aanpakt. Maar voordat je daarmee begint, is het noodzakelijk dat de voorbereiding als een huis staat. Door gebruikers al voor het prototyping-proces in kaart te brengen, kun je in grote lijnen al de richting bepalen. Denk daarom aan de volgende zaken voordat je van start gaat:
- Je hebt de gebruikers duidelijk in kaart gebracht aan de hand van persona’s.
- Je hebt in use cases beschreven wat je gebruikers willen en waarom.
- Je hebt deze use cases vertaald naar een datavraag en hebt de bijbehorende meetwaarden en dimensies bepaald.
Verderop leg ik je uit hoe deze voorbereiding je helpt om het dashboard af te stemmen op je gebruikers.
Kies voor paper prototyping
Goed, we kunnen aan de slag met prototyping van het dashboard. Dat kun je natuurlijk met een digitale tool doen, maar mijn voorkeur ligt bij paper prototyping. En daar heb ik een aantal goede redenen voor. Laat ik beginnen met waarom ik niet geloof in digitale tools. Ten eerste bieden ze meestal maar beperkte functionaliteiten. Ontwerpen met tools kan meestal tot een bepaald niveau, maar je kunt prototypes vaak niet precies zo aanpassen als jij dat wilt. Daarom blijf je vaak sleutelen aan het prototype en verlies je uit het oog waar het echt om draait, de usability.
Kies daarom liever voor een papieren prototype. Dit kost namelijk praktisch niets. Je hebt geen dure tools nodig. Een vel papier, flipover of whiteboard voldoet al. Als je het maar snel aan kan passen of weg kan gooien. Dat maakt paper prototyping zo iteratief. Je schets pas je snel aan op basis van de input van gebruikers. Ik schets vaak op papier wat er in mij opkomt. Daarmee loop ik dan makkelijk naar een gebruiker. Ter plekke vraag ik hem om feedback en maak ik een nieuwe variant die beter aansluit op zijn wensen. Door dit proces te herhalen met andere gebruikers heb ik binnen een paar uur een sterk verbeterde versie. Bovendien betrek ik de gebruiker heel nadrukkelijk in dit proces.
Bijkomend voordeel is dat de data nog even buiten beschouwing blijft. Dat voorkomt dat je verstrikt raakt in vragen over de inhoud. En je hoeft ook nog niet na te denken over details. Kleuren, logo’s en andere grafische opsmuk komt pas later aan bod.
Wat schets je wel?
- Titels en kopjes van de blokjes waarin je met een visualisatie iets wil vertellen
- Navigatie en workflow
- Categorieën (dimensies)
- Functionaliteit
Toch kan de gebruiker behoefte hebben aan een globale indruk hoe het dashboard eruit komt te zien. Ik gebruik daarvoor na de paper prototyping-fase vaak een digitale tool en klik hierin dan een prototype in elkaar. Dat stuur ik dan naar het management ter inspiratie.
Tools die je daarvoor kunt gebruiken zijn Balsamiq, Geckoboard en Klipfolio. Met Balsamiq kan je gebruiker door het dashboard klikken om de navigatie te testen. Voordeel is dat het gemakkelijker te verspreiden is en de perceptie geeft van dat er al heel wat staat. De andere tools zien er al snel gelikt uit omdat veelgebruikte visualisaties en navigatievormen er al in voorgeprogrammeerd zitten. Echter werk je in Geckoboard en Klipfolio wel op basis van echte data of dummy data.
De opbouw van je prototype
Ik studeerde ooit af op beslissingsondersteunende systemen. Voor mijn scriptie deed ik onderzoek naar de werking van besluitvorming in de hersenen en binnen organisaties. Die kennis gebruik ik nog steeds bij het bepalen van de structuur en opbouw van dashboards. Als houvast gebruik ik altijd drie lagen waaruit een dashboard is opgebouwd:
1. Monitoring
2. Investigation
3. Details
Deze drietrapsraket kun je toepassen op ieder dashboard. Het verschil zit hem vooral in de inhoud voor een specifieke gebruiker. Hiervoor gebruik je de persona’s, use cases en user stories die in de voorbereiding hebt ontwikkeld. Aan de hand van een voorbeeld illustreer ik hieronder hoe je de opbouw van je dashboard afstemt op je gebruiker.
Maak kennis met Nordin. Hij is pricing & asset analist bij een autoleasebedrijf. Hij wil aan de hand van een dashboard zien of het model voor het voorspellen van de restwaarde van leaseauto’s nog goed werkt. Zo kan hij op tijd bijsturen als het model afwijkt. In het prototyping proces heb ik zijn werkwijze getoetst aan deze use case. Zijn wensen verwerk ik vervolgens in drie lagen van het dashboard.
1. Monitoring
Dit is de ‘bovenste laag’ van het dashboard. Hier ziet de gebruiker in één oogopslag de cijfers die voor hem meest relevant zijn. Loopt alles voorspoedig of zijn er problemen waarop ik bij moet sturen? Nordin wil in deze laag zien of er een afwijking is in de voorspelde restwaarde en de echte restwaarde. Natuurlijk is het zaak om samen met Nordin duidelijk te krijgen wanneer hij vindt dat het model ‘afwijkt’. Het kan zijn dat je dan meteen al op een essentieel punt komt waarbij we de modelbouwers ook betrekken in het proces. In de monitoring-laag kun je dan inbouwen dat bij een afwijking boven de 5 procent een signaal wordt afgegeven door middel van een afwijkende kleur, grootte, icoon of zelfs een pushnotificatie of e-mail. Zie monitoring als het dashboard van je auto. Hier zie je ook diverse meters en lampjes. Als een lampje brandt, weet je dat je actie moet ondernemen. Soms is direct duidelijk hoe het probleem op te lossen is. Bijvoorbeeld door te gaan tanken. Maar soms is er meer onderzoeken nodig om uit te zoeken wat er aan de hand is.
2. Investigation
In het laatste geval stap je uit de auto en neem je een kijkje onder de motorkap. Waar komt het door dat het lampje brandt? Investigation geeft meer achtergrond aan de ‘kale cijfers’. Het is de tweede laag in het dashboard waarin je op onderzoek uitgaat. Waarom geeft mijn dashboard aan dat de data afwijkt van de verwachting? Wat is daar de oorzaak van? Nordin wil in deze laag zien wat de afwijking veroorzaakt en hoe hij die kan verklaren. Komt de afwijking alleen voor bij witte auto’s of alleen bij auto’s die verkocht zijn via de export of via een bepaald verkoper?
3. Details
Door te kijken onder de motorkap zie je dat er een probleem is. Maar het ontbreekt je aan de technische kennis om de exacte oorzaak te achterhalen. Je wil nu in detail weten waarom het rode lampje brandt. Daarvoor rijd je naar de garage om het pijnpunt echt boven water te halen. Met de hulp van een monteur ontdek je precies wat er mis is met je auto en kun je het probleem oplossen. Voor Nordin is deze laag essentieel om te ontdekken welke specifieke auto’s zorgen voor uitschieters in de restwaarde. Daarmee kan hij concreet afwijkingen voorleggen in zijn volgende teamoverleg met sales.
Je ziet het, dashboarding draait niet om een tool of data. Het gaat over je gebruikers en hoe zij hun werk slimmer en beter kunnen uitvoeren. Maar gebruikers verschillen meer van elkaar dan je denkt. Daarom kost het tijd om je dashboard goed af te stemmen op hun behoefte. Mijn advies is om die tijd vooral te investeren in prototyping.
Ga jij prototyping inzetten bij het ontwikkelen van je volgende dashboard?