Bij elke nieuwe webapp komt dezelfde vraag.

"Welk scherm bouwen we eerst?"

Klanten kiezen meestal de hero. Het dashboard. De landingspagina. Het deel dat je in de pitch laat zien.

Ik begin ergens anders. Bij het scherm waar je liever niet over praat.

Het scherm dat niemand aanzet

Elke app heeft één scherm dat alles draagt en dat niemand wil bouwen.

Voor een intake-app is het het dossier-overzicht dat een medewerker de hele dag open houdt.

Voor een boekhoud-tool is het de transactie-lijst, niet de maandrapportage.

Voor een CRM is het het klant-detailscherm, niet het dashboard met taartgrafieken.

Dat is het lelijke scherm. Veel data, weinig drama. En precies daar gebeurt 80% van het gebruik.

Waarom niemand daar begint

Omdat het niet fotogeniek is.

Een demo-screenshot van het detailscherm haalt geen pitchdeck. Het lijkt op Excel. Het is niet trots-op-te-zetten.

Dus bouwen mensen de hero, het dashboard, de grafieken. Het deel dat wel mooi staat op LinkedIn.

En dan, in week acht, komen we bij het detailscherm. De tijd is op. Het wordt een snelle oplossing. En daar, vanaf dag één in productie, zit de frustratie van de gebruiker.

Wat gebeurt als je wel hier begint

Je leert hoe je data echt in elkaar zit.

Een klant-dossier is geen "naam, mail, telefoon". Het is:

Vijf statussen per klus
Drie types bijlage die los staan
Twee medewerkers die er tegelijk aan werken
Een factuur die niet bij het dossier hoort maar er ook niet los van kan

Zodra je dat scherm bouwt, weet je welke velden je database nodig heeft. Welke relaties er zijn. Waar de uitzonderingen zitten.

De rest van de app leunt hierop. Het dashboard is een rapportage van dit scherm. De intake is een invoer voor dit scherm. De grafiek is een optelling van deze data.

Begin je bij het dashboard, dan heb je over twee weken data die de samenvatting niet kan maken. Moet je terug.

Een concreet voorbeeld

Autoschadebedrijf, maatwerk webapp.

De eerste demo had kunnen zijn: een hero met vestigings-statistieken. Taartgrafiek met schadetypes. Mooie KPI-blokken op een rij.

In plaats daarvan bouwde ik eerst het dossier-scherm. Een lange pagina met alles over één klus. Status, foto's, notities, planning, factuur-link.

Geen grafiek. Geen samenvatting. Alleen de informatie die een medewerker tien keer per dag raadpleegt.

Bij de eerste oplevering zei de eigenaar: "dit is alles wat we nodig hebben."

Ja. Omdat daar het werk gebeurt.

Hoe herken je jouw lelijke scherm

Drie vragen.

Wat kijken de medewerkers het vaakst? Niet het meest bezochte scherm in statistieken, maar het scherm waar iemand letterlijk zijn dag in doorbrengt.

Waar gaat het nu het vaakst mis? Dat detail-werk dat verspreid zit over drie tools. Overzetten, bijwerken, terugzoeken. Daar zit de pijn.

Waar zit de meeste data? Het scherm met de meeste velden is vaak het belangrijkste. Niet het mooiste, maar het belangrijkste.

Antwoord op deze drie vragen geeft je meestal hetzelfde scherm terug.

Wat dit betekent voor de planning

De eerste versie is niet minder klaar. Hij is anders geprioriteerd.

Week één tot drie: het detailscherm inclusief database-model.

Week vier tot zes: de invoer en wijziging rondom dat scherm.

Week zeven tot acht: overzicht, filters, rapportage. Het "presentabele" deel.

Als er iets moet schuiven, schuift het rapportage-deel. Dat zijn versnaperingen, niet de maaltijd.

Wanneer je wel met het dashboard begint

Er is één geval.

Is de webapp bedoeld om data te tonen uit externe systemen (Google Analytics, Shopify, Stripe), en wordt er niks ingevoerd? Dan is het dashboard inderdaad het hoofdgerecht.

Maar zo'n app is zeldzaam. De meeste maatwerk-apps bestaan omdat er data bewerkt, aangevuld of gekoppeld moet worden. En dan zit de kern in het detail.

Tot slot

Mooie schermen bouwen zichzelf. Onmisbare schermen moet je eerst bouwen.

Begin bij het werk. De samenvatting komt later.

Benieuwd waar jouw "lelijke scherm" zit? Plan een gesprek →

Zie ook: Wanneer een eigen webapp goedkoper is dan drie SaaS-tools en Wanneer Notion of Airtable genoeg is, en wanneer niet. Of bekijk direct de webapps-aanpak.