Dashboard-design voor het MKB: 5 valkuilen
Een dashboard dat niemand opent is een dure grafiekenmuur. Vijf valkuilen die we elke maand bij nieuwe klanten zien, en hoe je het anders aanpakt.
"We willen een dashboard." Het is de meest gestelde wens in een eerste gesprek. Wat klanten meestal bedoelen: ergens een overzicht van wat er gebeurt in hun bedrijf, zodat ze niet langer op vrijdag een uur in spreadsheets aan het scrollen zijn.
De realiteit: 80% van de dashboards die wij overnemen of vervangen worden actief gebruikt voor maximaal twee weken na go-live. Daarna verdwijnen ze in een browser-tab die niemand meer opent. Hieronder de vijf valkuilen die dat veroorzaken, en hoe je het beter doet.
Valkuil 1: te veel KPI's bovenaan
Iedereen wil "alle belangrijke cijfers in één oogopslag". Het ironische resultaat: een rij van 12 tegels waarvan je er 2 onthoudt en de rest negeert. De andere 10 worden visuele ruis.
Beter: beperk tot 4 KPI's bovenaan. Liefst 3. De vraag is niet "welke cijfers vinden we belangrijk", maar "welke 3 cijfers moeten vandaag tot een actie leiden als ze afwijken?" Andere data hoort in detail-secties die je openklapt als je verder wilt kijken.
Valkuil 2: cijfers zonder context
"€8.4K omzet vandaag." Goed of slecht? Vergeleken met wat? Als je dat moet uitrekenen door drie tabs te openen, is je dashboard al gefaald.
Elke KPI heeft drie context-elementen nodig om interpreteerbaar te zijn:
- Vergelijking met vorige periode (week, maand, jaar), meestal als delta in groen of rood
- Doelstelling indien relevant ("op pad voor €120K maand-target")
- Trend-line over tijd, een sparkline van 30 dagen zegt vaak meer dan het cijfer zelf
Een dashboard zonder deze drie is geen dashboard, het is een lijst getallen.
Valkuil 3: real-time waar het niet hoeft
"Het moet real-time updaten." Wij vragen altijd: hoe vaak ga jij dit dashboard openen? Als het antwoord "elke ochtend om 9:00" is, dan hoeft het niet real-time. Een refresh elke 15 minuten is genoeg, of zelfs een nightly batch-update.
Real-time data heeft drie verborgen kosten: (1) hogere API-kosten en serverlast, (2) flikkerende cijfers tijdens scrollen die afleiden, (3) complexer om te bouwen en te beheren. Veel klanten denken dat ze het nodig hebben, gebruiken het zelden, en betalen er onnodig voor.
Wanneer wel real-time: bij ops-dashboards waar je actief naar incidents staart (e-commerce checkouts, betalingsverwerking). Niet bij management-dashboards waar je strategische beslissingen op baseert.
Valkuil 4: mobile als afterthought
De meeste dashboards worden op desktop gebouwd en mobile wordt later "ook even" gedaan. Resultaat: een desktop-grid die in een mobiele browser onleesbaar geperst wordt, of horizontaal-scrollende kaarten die niemand vindt.
De vraag waar het écht over gaat: waar kijkt de eindgebruiker dit dashboard? Voor een founder die 's avonds in bed even checkt hoe het ervoor staat: 90% mobile. Voor de financieel manager die maandelijks rapporteert: 90% desktop. Begin met dat antwoord en bouw vandaaruit.
Concreet: bij een mobile-first dashboard ontwerp je voor 320-414px breedte. Eén kolom, 3 KPI-tegels, top-down scroll, geen sidebar. Op desktop wordt het automatisch een breder grid. De andere kant op werkt zelden.
Valkuil 5: één dashboard voor alle gebruikers
De founder ziet andere cijfers dan de marketing-medewerker, die andere ziet dan de boekhouder. Een dashboard dat probeert iedereen te dienen, dient niemand goed.
Beter: rol-bewuste dashboards. Eén "shell" met dezelfde stijl, maar de inhoud past zich aan de ingelogde rol aan. Founder ziet financieel + bedrijf-breed. Marketing ziet campagne-performance + leads. Operations ziet flow-status + uptime.
Een ander vuistregel: als de eindgebruiker uit één van zes rollen kan komen, ontwerp dan zes lichte varianten ipv één overladen monoliet.
Wat wel werkt: de 80/20 dashboard
Wat we het vaakst bouwen voor MKB-klanten:
- Hero-strip: 3 KPI's met delta-vergelijking
- Eén lijngrafiek: de belangrijkste metric over 30 dagen
- Activiteit-feed rechts: chronologische log van wat er recent is gebeurd in het systeem (klant aangemaakt, factuur betaald, flow voltooid). Geeft "alles loopt"-gevoel zonder dat je rapport-cijfers nodig hebt.
- Tabel onderaan: top-N van iets relevants (top klanten, achterstallige facturen, openstaande tickets)
- Detail-pages voor wie verder wil graven
Dat is het. Vier elementen op de homepage. De rest in detail-tabs.
"Een dashboard dat in 5 seconden vertelt of het goed of slecht gaat, wordt elke dag gebruikt. Een dashboard dat 5 minuten studie vraagt, wordt 5 keer geopend en daarna niet meer."
Test-vraag voor je eigen dashboard
Open je huidige dashboard. Stel jezelf binnen 10 seconden de vraag: moet ik vandaag iets doen? Lukt het je om dat in 10 seconden te beantwoorden? Zo ja: het is een goed dashboard. Zo nee: te veel data, te weinig signaal. Je dashboard is een mooie data-archiv, geen beslisinstrument.
Bij elke nieuwe metric die we toevoegen aan een klant-dashboard stellen we onszelf één vraag: welk gedrag gaat hier door veranderen? Als we geen goed antwoord hebben, voegt de metric niets toe.
Sparring over jouw automatisering?
30-min intake-gesprek, gratis. We kijken samen waar AI of automatisering het meeste tijd en geld bespaart in jouw bedrijf.
Plan een gratis gesprek →Veelgestelde vragen
Welke tools gebruiken jullie voor dashboards?
We bouwen klant-dashboards op Lovable + Supabase + Vercel. Niet op Tableau of Power BI, die zijn te zwaar en duur voor MKB. Een eigen webapp geeft snelheid en branding-vrijheid die enterprise-tools niet bieden.
Kan ik mijn bestaande dashboard verbeteren ipv vervangen?
Vaak wel. Begin met een gebruikers-test: vraag 3 mensen om te demonstreren hoe ze dashboard gebruiken. Je ziet binnen 15 minuten waar de pijnpunten zitten. Soms is het een design-fix, soms moet er meer.
Hoe lang duurt het bouwen van een MKB-dashboard?
Een eerste werkende versie: 1-2 weken. Plus 2-4 weken iteratie op basis van echte gebruik. Eindstand: ~30-50 uur werk, €3.000-5.000 setup.
Werken jullie met data uit alle tools?
Bijna alles dat een API of webhook heeft kunnen we koppelen. Tools die alleen via screen-scraping werken (oude legacy-systemen) zijn lastiger en duurder.