Fragment
Uit hoofdstuk 4: Structuur van dashboards
Als je de dashboards op een goede manier wil vorm geven, het systeem (de verschillende verbonden dashboards) op een goede manier wil structureren, moet je de verwachtingen van de gebruiker ten opzichte van de structuur te weten komen.
Waarom dashboards?
Management (en nu bijna iedereen) verwachten dat de grote hoeveelheid informatie die hen dagelijks bereikt, op een goede manier binnenkomt. Zij willen die kunnen gebruiken, correct interpreteren, er acties mee ondersteunen en verantwoorden. Met andere woorden, zij hebben een doel voor ogen.
Je kan op de gebruiker afstappen en vragen “Wat wil je zien, welke informatie, welke vorm?” en je zal ongetwijfeld een antwoord krijgen waarmee je direct aan de slag kan. Je bouwt enkele dagen, weken aan het systeem en stapt fier als een gieter met het resultaat op de gebruiker af. Grote kans dat die persoon zal reageren als “Dat is niet wat ik verwachtte, daar kan ik niet veel mee doen.”. De grond zakt onder je voeten weg, de gebruiker weet duidelijk niet wat hij wil. Deze conclusie is fout.
De gebruiker weet het wel maar jij hebt het niet gevraagd. Je hebt gevraagd wat hij wil en de gebruiker is mentaal aan de slag gegaan om een oplossing te bedenken. Dat gaf hij als antwoord. Hier ontstaan twee problemen:
1. De gebruiker heeft een oplossing aangebracht maar niet verteld wat het probleem is. Zijn verwachting is dat wat hij jou voorstelde de beste manier is om aan zijn verwachtingen te voldoen. Maar dat is niet noodzakelijk zo, jij weet wat er mogelijk is en de gebruiker weet dat niet. De gebruiker kent zijn verwachtingspatroon maar jij hebt er geen idee van – ook al denk je van wel;
2. Jij maakt een systeem volgens de wensen die de gebruiker je vertelde en verwacht dat hij dat zal zien als een goede tool om het probleem mee op te lossen. Dat blijkt achteraf niet te kloppen want waarschijnlijk was de oplossing die de gebruiker – met de beste bedoelingen – aanbracht, niet de meest geschikte.
Met andere woorden, je hebt beiden een verwachtingspatroon (oplossing voor probleem, oplossing die gevraagd is) maar deze kloppen onderling niet. Wat jij gemaakt hebt zal zeer waarschijnlijk het niet probleem niet oplossen.
Wat je had moeten maken is een oplossing voor een onuitgesproken probleem. Wat jij moet bereiken is dat de gebruiker je het probleem vertelt en wat hij wil bereiken met de oplossing, niet hoe de oplossing er moet uitzien. Jij, als ontwerper van het(de) dashboard(s), moet nu een technologisch geavanceerde, bruikbare oplossing bedenken die voldoet aan de noden. Als deze oplossing overeenkomt met het verwachtingspatroon van de gebruiker, dan is het “match made in heaven”.
Dan heb je een grote kans op een goede User Experience.
×