Data is een fantastische grondstof waar je veel waardevolle producten van kunt maken. De mogelijkheden van (big) data zijn eindeloos. Maar die potentiële waarde verblindt ontwikkelaars vaak. Data in een dashboard stoppen, betekent niet automatisch dat je waarde toevoegt in je organisatie. Misschien heb je een visualisatie of dashboard gemaakt die je zelf prachtig vindt, maar wordt de informatie door gebruikers volledig verkeerd geïnterpreteerd en gebruikt. Wat in het ergste geval leidt tot foute beslissingen. Of iedereen lijkt enthousiast, maar uiteindelijk wordt het dashboard nooit gebruikt. En het kan zo anders!
Human centered BI
Ik ben als ervaren usability expert de wereld van business intelligence ingerold. En ik verbaas me vaak over de ‘data centered’ of ‘tool centered’ benadering van dashboards en andere informatieproducten: er wordt gebouwd wat de data en/of tools te bieden hebben. Als BI-consultant heb ik echter maar één doel: eindgebruikers blij maken. Hoe cool is het als een gebruiker jouw dashboard omarmt, inpast in zijn werkzaamheden en met de verkregen inzichten betere beslissingen neemt of efficiënter werkt? Human centered BI noem ik dat.
Dashboard
Eerder liet ik zien hoe je data steeds verder verrijkt om tot respectievelijk informatie, kennis en wijsheid te komen. Om van verslaglegging van het verleden te komen tot een BI-product waarmee je beslissingen kunt nemen voor de toekomst. Dat is maar één van de aspecten van goed informatieontwerp. Een van de belangrijkste andere aspecten van je ontwerp is uiteraard de gebruiker zelf! Graag leg ik je uit hoe je gebruikers centraal stelt bij het ontwerpen van je informatieproducten.
Vraag niet “wat wil je hebben?”
Vraag nooit aan de gebruikers waar je voor werkt hoe hun dashboard eruit moet zien. Het is jouw taak als ontwerper om de werkzaamheden en de behoeften van je gebruiker te begrijpen en hem of haar vervolgens te verrassen met een informatieproduct dat daar naadloos bij aansluit. Jouw werk is het ontwerpen van een dashboard dat een gebruiker zelf nooit had kunnen bedenken. Informatieontwerp is namelijk een vak. Als ontwerper bedenk je hoe je jouw eindgebruiker het beste kunt ondersteunen in zijn werk en de beslissingen die hij moet nemen. Henry Ford zei het ooit heel treffend: “if I had asked people what they wanted, they would have said: faster horses.”
Hoge verwachtingen niet waargemaakt
Het klinkt tot nu toe misschien logisch, maar toch kom ik dagelijks bij bedrijven rapporten, lijstjes en dashboards tegen die niet aansluiten bij de wereld van hun gebruikers:
- Opvallend vaak is geheel onduidelijk voor wie het informatieproduct bedoeld was en waar het eigenlijk voor gebruikt wordt.
- Als ik met gebruikers door hun informatieproduct heen loop, blijkt vaak dat informatie verkeerd geïnterpreteerd wordt.
- Veel informatieproducten worden wel trouw geleverd, maar vervolgens niet gebruikt.
- Regelmatig hebben gebruikers trucjes bedacht om het informatieproduct toch te kunnen gebruiken; ze kennen precies de haken en ogen van de informatie en hebben zelf spreadsheets of werkinstructies gemaakt om hiermee om te gaan.
Dat onderbouwt mijn stelling dat veel producten nog steeds worden ontwikkeld vanuit de beschikbare data en tools. Op zich wel verklaarbaar, want veel bedrijven voelen urgentie om waarde uit hun data te halen en zetten er druk achter om de ‘schat aan informatie’ te ontsluiten via een – meestal kostbare – visualisatietool. De hoge verwachtingen worden meestal niet waargemaakt en de teleurstelling is dan groot. Alle reden om ook voor dashboards en andere informatieproducten een gedegen user centered ontwerp te maken. Als ervaren usability expert grijp ik daarbij automatisch terug op mijn ervaring met gebruikersanalyse, informatieontwerp, prototyping en user testing. Waarbij ik altijd in dezelfde vijf stappen te werk ga om informatieproducten van echte waarde te ontwerpen.
Gebruikersanalyse in 5 stappen
In een gebruikersanalyse breng je in kaart wie je gebruikers zijn, wat hun behoefte is en hoe je ze daar het beste mee kunt helpen. De uitkomst van de analyse leg je meestal vast in persona’s, user stories en informatieontwerpen. Hieruit leid je de requirements af die je gebruikt voor de keuze van je visualisatie of dashboard tool en de beslissingen over de benodigde data.
Stap 1: Wie zijn je gebruikers?
Een goed begin van een gebruikersonderzoek is het in kaart brengen van de functie van je gebruiker en het globale doel van het informatieproduct. Gaat dit om mensen uit het managementteam, om de operationeel manager van de klantenservice of om een storingsmonteur? Wat is belangrijk voor hun functie en wat willen ze bereiken? Daarbij is ook demografische informatie interessant. Gaat het om een vrouw of man, van welke generatie is je eindgebruiker en wat voor achtergrond/opleiding heeft hij? Wat is zijn ervaring met IT en BI? Wat is zijn kennisniveau van bijvoorbeeld statistiek?
Gebruikersonderzoek kun je op verschillende manieren doen. Elke methode heeft zijn eigen doel, resultaat en kosten. Denk aan persoonlijke gesprekken, bijeenkomsten, surveys en observaties. Het resultaat van je gebruikersonderzoek leg je vast in persona’s of user profielen. Een persona beschrijft een gebruikerstype en kan dus meerdere eindgebruikers vertegenwoordigen. Het is lang niet altijd zo dat mensen met dezelfde functie dezelfde wensen hebben.
Stap 2: Wat willen je gebruikers?
Als je een goed beeld hebt van je gebruikers is het tijd om specifieker te worden. Wat voor taken voert de gebruiker uit? Waar wordt hij op afgerekend? Welke doelen wil hij behalen? Welke KPI’s zijn er voor zijn functie vastgesteld? Wat is zijn informatiebehoefte? Om tot heldere antwoorden te komen helpt het om herhaaldelijk door te vragen waarom iemand iets wil weten. En, niet onbelangrijk, vraag naar de verwachtingen die hij heeft van het eindproduct. Waar zit momenteel het ‘probleem’ dat het product gaat oplossen? Wat is de huidige situatie en hoe verwachten ze dat die situatie zal zijn met het nieuwe product? Hebben ze daar vertrouwen in of zijn ze sceptisch? Hoe past het gebruik van het product straks in hun werkzaamheden? Maar ook…wat hebben ze eerder zelf al in Excel bij elkaar verzameld en hoe gebruiken ze dat nu?
Al deze informatie leg je vast in user stories. Een beschrijving in één zin wat een gebruiker wil en waarom hij dat wil. Om het probleem of proces in kaart te brengen kun je een scenario uitschrijven of dit visueel zichtbaar maken in een user flow.
Voorbeeld:
Als manager klantenservice wil ik weten wat onze conversie is, zodat ik op tijd kan bijsturen als we onze doelen niet gaan halen.
Als manager klantenservice wil ik de prestaties van mijn teamleden kunnen vergelijken, zodat ik kan onderzoeken hoe ik mijn team beter kan maken.
Als klantenservicemedewerker wil ik kunnen zien welke beoordeling de klanten de gesprekken geven met mij, zodat ik daarvan kan leren.
Stap 3: Hoe kun je ze daar het beste mee helpen?
Het is nu jouw beurt om aan de slag te gaan. Per user story bepaal je de benodigde meetwaarden (bijvoorbeeld aantal clicks, omzet, artikelvoorraad, aantal bestede uren) en dimensies (bijvoorbeeld afdeling, jaar, categorie, werknemer). Je kunt per user story de benodigde visualisaties ontwerpen en deze alvast schetsen. Naast een ontwerp per user story is het belangrijk om een globaal informatieontwerp te maken. Welke informatie hoort bij elkaar en wat kan op een aparte pagina komen? Hoe zorg je ervoor dat je gebruikers de juiste context houden als ze door de pagina’s van je dashboard heen gaan? Kortom, hoe zorg je voor een goede usability van je informatieproduct en een goede user experience voor iedere gebruiker?
Meestal start ik zelf met paper prototyping. Ik schets de indeling van het dashboard en bespreek die met gebruikers. Ik laat ze erover praten en kom zo al snel met een verbeterde schets en na de volgende gebruiker is die weer een stuk verbeterd. Zo kom je razendsnel tot een goede basis. Die basis kun je bijvoorbeeld in een prototyping tool als Balsamiq schetsen en weer voorleggen aan je gebruikers. Met zo’n tool kunnen gebruikers alvast door de structuur en het informatieontwerp heen klikken. Door ze hierover te laten praten kom je er snel achter of het ‘klikt’ of niet. Let op, hier heb ik het nog lang niet over kleurgebruik en pixel perfect ontwerp. Prototypes hoeven niet mooi te zijn, ze moeten zorgen voor discussie over de inhoud en structuur (wat niet wegneemt dat voor veel gebruikers het grafische aspect enorm belangrijk is).
Tip: probeer in deze fase je klant te verrassen. Hou bijvoorbeeld de DIKW-pyramide in gedachten. Wat mij betreft is alles toegestaan in deze fase! Laat je klant zien wat er allemaal mogelijk is en streef naar de optimale oplossing. Later verdelen we dat nog wel in must haves en nice to haves.
Stap 4: Welke data en tooling is er nodig?
Nu je weet wat voor informatieproduct je gebruikers nodig hebben, kun je de technische, functionele en niet-functionele requirements deduceren. Heeft een klant aangegeven dat hij maandcijfers op een groot scherm wil tonen bij een externe klant? Dan vraagt dat om een slimme exportmogelijkheid of een licentievorm waarbij het dashboard extern toegankelijk is. Gebruikt je klant het informatieproduct de hele dag door om zijn werkvoorraad te managen? Dan is het belangrijk om de data snel te kunnen verversen. Wil de CFO het informatieproduct gebruiken voor zijn informatieverstrekking in het kader van Basel III? Dan stelt dat eisen aan de kwaliteit en herleidbaarheid van de informatie en is er speciale aandacht voor data governance nodig. Wil de conversiespecialist analyse van Google analytics data zien in zijn dashboard? Dan is dat een requirement voor de tooling die je gaat kiezen. Wil jouw gebruiker onderweg checken of zijn team op schema ligt met de KPI’s voor die maand? Dan zal je informatieproduct beschikbaar moeten zijn op mobiele devices. Vindt een gebruiker het super belangrijk dat de inzichten op zijn dashboard een visueel wow-effect hebben? Dan wil je grafische eisen stellen aan de te kiezen tooling.
De requirements leg je vast in een functioneel ontwerp. Ik maak hierin ook vaak een overzicht van alle stukjes data die nodig zijn en wat hiervan de definitie of berekening is. Samen met de BI- of IT-afdeling zul je moeten checken of die data al in de geschikte vorm aanwezig is, bijvoorbeeld in een datawarehouse.
Bij het kiezen van geschikte tooling komt uiteraard nog veel meer kijken. Naast je eindgebruikers heb je nog meer stakeholders om mee te nemen in deze beslissing. IT zal wensen hebben, er zal een bepaald budget zijn, misschien wordt er al bepaalde tooling gebruikt etc.
Stap 5: En wat als het niet past?
Er is altijd wel iets dat niet past. Een tool die aan alle eisen voldoet, maar geen real-time data kan verwerken. Software die visueel heel sterk is, maar bepaalde analyses niet kan maken. Er is altijd wel iets dat niet helemaal perfect aansluit. En soms sluit het zelfs voor geen meter aan…
En hier komt mijn cruciale punt! Doordat je een echt goede analyse hebt uitgevoerd, kun je nu een geïnformeerde beslissing nemen. Ok, dit zit er niet in. Waar hadden we dat ook weer precies voor nodig en wat gaat dat opleveren? Misschien is daar een alternatief voor te verzinnen? Je geeft op deze manier de budgethouder onderbouwde argumenten om een beslissing te nemen. Je kunt met maatwerk alles bouwen wat de gebruikers willen, maar dan kost het dit. Je kunt ook deze standaardtool kiezen, maar dan zit dit en dit er niet in en dat gaat ten koste van deze resultaten. Hiermee voorkom je ook dat je tooling aanschaft waarmee belangrijke gebruikerswensen in een later stadium niet realiseerbaar blijken te zijn. Dit is precies hoe je voorkomt dat het bouwen van dashboards en datavisualisaties het domein van techneuten wordt. Met prachtige data-ontsluiting, adembenemende ETL processen… en een dashboard dat nooit gebruikt wordt.
Usability rules
Het is een zin die we maar al te makkelijk in de mond nemen: “de juiste informatie bij de juiste persoon op het juiste moment op de juiste plek.” Maar ben jij er echt zeker van dat de dashboards die jij bouwt:
- Die informatie leveren die past bij de taken en doelen van je gebruiker?
- Aan een persoon gericht zijn die de informatie begrijpt en er actie op kan ondernemen?
- Op het juiste moment beschikbaar zijn, dus zodra de gebruiker een besluit moet nemen of de data nodig heeft in zijn werkzaamheden?
- Op de juiste plek toegankelijk zijn, daar waar de gebruiker de informatie nodig heeft: op zijn mobiel, als onderdeel van een ander systeem of bij een klant?
Kijk je alleen welke data er is en wat de beschikbare tooling met die data kan? Of heb je vooraf heel goed over deze vragen nagedacht zodat je dashboard echt gebruikt gaat worden? Ik hoop dat mijn aanpak je helpt meer usability aan je informatieproducten toe te voegen!
Want wat zou het jou opleveren als je gebruikers hun dashboards écht gaan gebruiken?
